The Clean Architecture in php

class
CustomerController
{
protected
$repository
;
protected
$responseFactory
;
public function
__construct
(
CustomerRepository
$repo
,
ResponseFactory
$factory
) {
$this
->
repository
=
$repo
;
$this
->
responseFactory
=
$factory
;
}
public function
viewAction
() {
$customer
=
$this
->
repository
->
getById
(
1001
);
$response
=
$this
->
responseFactory
->
create
(
$this
->
params
(
'context'
));
$response
->
setData
(
'customer'
,
$customer
);
return
$response
;
}
}

---

Dependency Injection
50
Previously, our dependency was the specific response we were returning. Now, however, it’s this
new
ResponseFactory
class that builds a response for us.
The important thing here is that we are abstracting out the logic that determines how to build
the dependency, and instead depending on that abstraction. We’re also injecting that in so that
if the logic or methodology ever changes, we just have to change the implementation instead of
updating an unknown number of locations that were previously building their own responses.
Handling Many Dependencies
It’s very easy to let dependency injection get out of control:
public function
__construct
(
CustomerRepository
$customerRepository
,
ProductRepository
$productRepository
,
UserRepository
$userRepository
,
TaxService
$taxService
,
InvoiceFactory
$invoiceFactory
,
ResponseFactory
$factory
,
// ...
) {
// ...
}
This is usually indicative of having a class that violates the Single Responsibility Principle and
does too much and contains too much logic. There’s no hard rule about how many dependencies
a class can have. Generally, the fewer the better, however, it’s entirely possible to go too far in
the other direction as well, and end up with a hierarchy of tiny classes that are hard to follow,
refactor and test.
After understanding the concepts of this book, you can start to use the “Feels Bad” policy of
knowing when to refactor a bad situation into good, healthy code.