The Clean Architecture in php

Defining a Contract with Interfaces
In the previous chapter we discussed the principle of inversion of control, and describe how
dependency injection can make refactoring and testing code easier. We started out by discussing
object coupling, and presented dependency injection as a method of limiting coupling. However,
when we reached the end, we realized that we hadn’t entirely removed the coupling, we only
made it weaker by moving it to the constructor from the methods of the class.
class
CustomerController
{
protected
$repository
;
public function
__construct
(CustomerRepository
$repo
) {
$this
->
repository
=
$repo
;
}
public function
viewAction
() {
$customer
=
$this
->
repository
->
getById
(
1001
);
return
$customer
;
}
}
This class is still well coupled to the
CustomerRepository
class. Since the
CustomerRepository
class is responsible for, at least through its dependencies, connecting to and retrieving data from
a database, this means that the
CustomerController
is also coupled to that database.
This can be problematic if we ever decided to switch data sources, such as moving to a NoSQL
variant, or switching to some API service to provide our data. If we do that, we’ll have to then
go modify all the code across our entire code base that uses this
CustomerRepository
to make it
use something else.
Further, if we want to test this
CustomerController
, we still have to give it an instance of
CustomerRepository
. Any mock object we create will need to extend from
CustomerRepository
to pass the type-hint check. That means our simple mock repository will still have to have the
entire database back-end tied to it, even if we are overriding everything it does. That’s pretty
messy.