DEPENDENCY INJECTION

DEPENDENCY INJECTION VS. SERVICE LOCATION DEPENDENCY INJECTION CONTAINERS Examples and Comparison PHP-DI Auryn FRAMEWORK INTEGRATION DEMO POPULAR FRAMEWORKS How they do it

SOLI [Dependency Inversion Principle] $coupling-- $reuse++

SOLI [Dependency Inversion Principle] $coupling-- $reuse++ SL DI

READABILITY ! TESTABILITY ! FLEXIBILITY ! MAINTAINABILITY

DEMO

Dependency Injection & DI Containers Service Locators ?

DEPENDENCY INJECTION

DEPENDENCY INJECTION MyService is now coupled to concrete DatabaseObject

DEPENDENCY INJECTION MyService is now coupled to concrete DatabaseObject MyService is now hard to test

DEPENDENCY INJECTION So, how else can we do it??

DEPENDENCY INJECTION Pass your object in via the constructor instead

DEPENDENCY INJECTION Code is now TESTABLE (eg. with phpunit) Object requirements can be seen from the method signatures only

POLYMORPHISM Dependency Injection Polymorphism Awesomeness

SERVICE LOCATION

SERVICE LOCATION One object to pass around (our "container")

SERVICE LOCATION One object to pass around (our "container") Access to any object, anywhere

SERVICE LOCATION Dependency Injection Here But Service Location Here

SERVICE LOCATION Dependency Injection Here Actual dependencies still hidden from method signature (they're in this "container") MyService now tied to container But Service Location Here

SERVICE LOCATION NOT A FACTORY Factories: build and return objects SLs: equivalent of an associative array Set objects at bootstrap Retrieve objects when requested Objects may be instantiated lazily (only when you ask for them, think via PHP 5's closures)

WHY DI > SL Every object you create: • The public methods are an API to the object's usage • How the methods can be used should be visible from the method signatures alone Pass in your container = a container dependency, hard to test etc Pass in your object = we know exactly what the object needs to run

FRAMEWORKS Well known frameworks that (initially) used the SL pattern

SYMFONY 2 Service Locator Method dependencies unknown from signature

SYMFONY 2 Register dependencies Dependency Injection

SYMFONY 2 Complexity increases for other arguments, dependencies etc Injection in constructor, but may not be used by all methods (waste of resources for controllers)

SILEX The whole app is a service locator... $foo contains: • Logging • Database • Other registered services • Let's go check the docs... (to the developer writing it)

SILEX The whole app is a service locator... $foo contains: • Logging • Database • Other registered services • Let's go check the docs... (to the developer writing it) $foo contains: • No idea... • Let's go check the docs... (to a future developer)

SILEX ServiceControllerServiceProvider Bootstrap: Define dependencies individually

SILEX ServiceControllerServiceProvider Bootstrap: Define dependencies individually Bootstrap: Define controller with the above

SILEX ServiceControllerServiceProvider Bootstrap: Define dependencies individually Bootstrap: Define controller with the above Controller: Typehint for your dependency

SILEX ServiceControllerServiceProvider Bootstrap: Define dependencies individually Bootstrap: Define controller with the above Controller: Typehint for your dependency Great! But still a lot just for one dependency... Still constructor-only injection

SO FAR... Popular frameworks offer both Dependency Injection and Service Location SL = simpler, but couples service to container DI = Testable code, but time consuming to set up and configure Method requirements should be visible from the method signature only Constructor-only injection in your controllers shares objects that may not need to be shared Note: we're not talking about setter injection here Method injection in your controllers provides a clear explanation of the method's needs Controllers don't always adhere to SRP anyway

DEPENDENCY INJECTION Starts most visibly at the Controller Resolution level Look at the controller resolver to see where you can place a DI container

DEPENDENCY INJECTION Starts most visibly at the Controller Resolution level Look at the controller resolver to see where you can place a DI container

DEPENDENCY INJECTION Starts most visibly at the Controller Resolution level Look at the controller resolver to see where you can place a DI container

DEPENDENCY INJECTION Starts most visibly at the Controller Resolution level Look at the controller resolver to see where you can place a DI container Decorate existing class to maintain default functionality

DI CONTAINERS

DI CONTAINERS Composition Root pattern Define your object graph ("wiring") as close to the top layer as possible ie. in your bootstrap In PHP, this could involve: Sequentially manually created objects An array of object mappings as strings A configuration file containing mappings

AURYN INJECTOR A Dependency...

AURYN INJECTOR A Dependency... A service that needs the dependency... (Could be a controller)

AURYN INJECTOR Usage 1. Uses reflection to read the method signature of MyService 2. Sees the typehint for DatabaseObject 3. Uses reflection to read the method signature for DatabaseObject 4. No dependencies here, creates the DatabaseObject and injects it into MyService

AURYN INJECTOR Usage 1. Uses reflection to read the method signature of MyService 2. Sees the typehint for DatabaseObject 3. Uses reflection to read the method signature for DatabaseObject 4. No dependencies here, creates the DatabaseObject and injects it into MyService Do this in your composition root Do this in your controller resolver

Recursive Dependency Instantiation

POLYMORPHISM Typehint for an Interface instead

POLYMORPHISM Runtime Polymorphism via the DiC DatabaseInterface will use "MongoDbInstead" concrete class When "MyService" is resolved: 1. The constructor signature will be read via reflection 2. The DatabaseInterface will be found as a dependency 3. The alias for DatabaseInterface is "MongoDbInstead" 4. The MongoDbInstead class is dependency injected for us

CONTROLLER RESOLVER DEMO

PHP-DI

PHP-DI VS AURYN PHP-DI AURYN Recursive DI and Caching Recursive DI and Caching Nice website, more in-depth docs Github-only, less support Constructor-only Injection Application-wide Injection

READABILITY ! TESTABILITY ! FLEXIBILITY ! MAINTAINABILITY