The Clean Architecture in php

class
AddressController
extends
AbstractController {
protected
$geocoder
;
public function
__construct
(BillsGeocoder
$geocoder
) {
$this
->
geocoder
=
$geocoder
;
}
public function
validateAddressAction
() {
$address
=
$this
->
vars
()
->
fromPost
(
'address'
);
$isValid
=
$this
->
geocoder
->
geocode
(
$address
)
!==
false
;
}
}
We’re using some dependency injection into the controller, which is great. This is a step in the
right direction and solves some problems for us, but it’s still strongly coupling our controller to
whoever Bill is. What if he goes away? What if you figure out
DavesGeocoder
is so much better
because it supports Zip+4, which
BillsGeocoder
didn’t? And what if you just happen to use
this geocoder all over the place and now you have to go update all those references? What if
DavesGeocoder
doesn’t have a
geocode()
method but instead has
validateAddress()
. You’ve
run into a refactoring nightmare.
Setting up the Adapter
Recall back to our discussion on design patterns, specifically the Adapter Pattern. Adapters are
perfectly suited to solve this problem as they allow us to “wrap” the functionality of the third
party code, and by doing so, make it conform to an interface we define, so that we can inject
that adapter to fulfill the interface.
This is exactly what we did when we discussed the Adapter Pattern. We started by defining our
interface:

---

Abstracting with Adapters
58