October 2011
ZendDi

Who Am I?
•Ralph Schindler (ralphschindler)
Software Engineer on the Zend Framework team
•At Zend for almost 4 years
•Before that TippingPoint/3Com
Programming PHP for 13+ years
Live in New Orleans, LA.
•Lived in Austin, Tx for 5 years
My background with Di
•I was part of the original roundtable 3yr ago @ zendcon
–Fabien + Stephan + Myself
2

First Some Background
•Background
Di Definitions
Some generic patterns
3

Dependency Injection
•Subject matter expert: Martin Fowler
not the only one, but has a nice take on it
•http://martinfowler.com/articles/
injection.html
4

Di vs. DiC
•Di is a pattern
This is non-negotiable
DI is about Inversion Of Control (IoC)
–sometimes not an easy concept to grasp for
beginner and intermediate developers
•DiC is a tool
Subject to a developer’s or a group of
developers requirements
I.E.: no formal definition
•as such, lots of frameworks provide this in some
way shape or form
5

Important Fowler Quote
•“Inversion of control is a common feature
of frameworks, but it's something that
comes at a price. It tends to be hard to
understand and leads to problems when
you are trying to debug. So on the whole I
prefer to avoid it unless I need it. This isn't
to say it's a bad thing, just that I think it
needs to justify itself over the more
straightforward alternative.”
6

Di: In a Nutshell
•Obligatory:
7

Di’s Misguided Argument
•Testing
everyone quotes this as the argument for
dependency injection
•correct for silo’d development
•if you are the only consumer of your code
too much emphasis here
8

The Better Di Argument
•Makes it easy for developers to swap
out implementation
•Paddy Brady:
... “it helps ensure source code can be
maintained in a highly decoupled state.
Which make it easier to subclass the Zend
Framework to death, and modify it’s
components before use.”
9

Di Identified Types
•Constructor
Favored by PicoContainer derivatives
•Setter
Favored by Spring Container derivatives
10

Di 3rd Injection Type
•Interface Injection
but first as segue ...
11

What is an Interface
•A contract that forces subtypes to conform
to particular method signatures so that
objects can exhibit particular behaviors
12

Interfaces
•Interface best practices
No constructors
No static methods
•Why? Because interfaces are about
“alternate implementations”
•PHP allows statics and constructors in
interfaces
for better or worse
13

Interfaces explained
•A better way to think about it
Interfaces are about contracts in behavior
between developers
Point in case, search for “friends” in this
page:
•http://martinfowler.com/articles/injection.html
14

Interfaces in practice
15

Back To Interface Injection
•First and foremost: a communication tool
•Form of setter injection (or, injection via
method)
•The dependency is implied by the
interface and the injection point is forced
by the interface
Always part of the type’s hierarchy
•Rely’s on a managing/consuming object/
framework for execution - or a really strict
developer
16

Interface Injection Example
17

Interface Injection Pattern
•Not formal / it is semi-de-facto
•Interface injection is tricker to understand
without context
•(Semi) Well known pattern at play
the “Aware” interface name
18

Interface Injection Downside
•At the application layer, it leads to having
to write and consume lots of interfaces to
get things sorted out
19

Interface Injection Downside
20

Constructor vs. Setter Injection
•Constructor
Pro: object in ready state
Con: there is a param per dependency
•too busy of an object? or just right?
Con: dependencies are not polymorphic
Pro/Con: dependencies can (not?) be
swappable after instantiation
Pro: object declares complexity up front
Con: can lead to cyclical dependencies
21

Constructor vs. Setter Injection
•Constructor continued:
•Constructors are not subject to Liskov Substitution
Principle (Ctor is not part of the type in question)
–In other languages ctors are static
22

Constructor vs. Setter Injection
•Setter
Pro: clear injection points for each
dependency
Con: consumer has to be very honest about
injecting all dependencies
Con: construct is not up front about required
dependencies
•hard to distinguish optional vs. required
dependencies
–is this really such a thing?
23

Misconceptions?
•(SL) Service Locators !== (DiC) Dependency
Injection Containers
•But DiC == SL
DiC’s can be the foundation of consumed for
service location
24

Typical Dependency Injection Graph
25

Service Locator
•It is understood that services to be locator
aware
•Pros:
not all code paths in the consuming object
might use all the dependencies
•Example: controller
•Cons:
service locator becomes the dependency
26

Service Locator Graph
27

•ZendDi
28

Why Di For Zend
•Considering a DiC is a first world problem
for developers
•Why did we create this component?
You’re afraid of “new”?
You asked for it
•Having a DI Container that tries to
understand your code makes you code
better
29

Questions Raised
•But is it really possible to force developers
to write better code?
•How do we look at a use case and tell if
the DiC is falling short, or the developer is
writing bad code?
There is a fine line
30

DiCs Out There - Not PHP
•Java
Spring, PicoContainer
•.net
Spring.Net, StructureMap, Unity, Castle’s
Windsor
31

ZendDi perspective
•we support both:
"This issue has led to a lot of debate between
the various teams who provide dependency
injectors as part of their frameworks. However
it seems that most people who build these
frameworks have realized that it's important to
support both mechanisms, even if there's a
preference for one of them."
•-Martin Fowler
32

Developing ZendDi
•Development of ZendDi
33

Goals
•Find a way to produce a DiC that works for
PHP developers and all their “tendencies”
very hard to identify
•Performant - as best as possible
we have no persistent memory
•The same or less code required than
actually just writing the code in the first
place
34

A Note on DI and Performance
•Di is just code, it is a performant as not
practicing Di
so long as you’re still using the same number
of dependencies/objects
•DiC is not performance friendly!
Front loading workflow, structural needs
NOT Hello World friendly!
35

ZendDi Parts
•Two main components
Definition
Instance Configuration
•Runtime concerns
36

ZendDi Definition
•Goals
Explain what the code looks like, what it
expects
Identify which classes have dependencies
Identify injection points
Names for all the moving parts
37

ZendDi Definition
•Instantiation:
Constructor (new keyword)
Callback (factory pattern)
•Via object factory
•Via static factory method
38

ZendDi Definition
•From a very fundamental level, injection
always comes in the two forms
Via constructor params
Via method injection
•We (currently) do not support public
property setting
39

ZendDi Definition
•Naming dependency/configuration entry
points
Is an object expected? Is there a type hint?
•Where does it originate from?
Is a scalar expected? Is it optional?
40

ZendDi Configuration
•Goals
Encapsulate runtime data required to wire
instances
•Could be environment specific (dev. different than
production)
Be able to identify which objects fulfill a
dependency (preferred types)
41

Definition & Configuration
•A better understanding:
Definitions can be shipped with your code,
they are independent of how they are used
Configuration is what is expected of anyone
consuming ZendDi
42

Building Definitions
•At Runtime (on-demand)
Great for development, terrible for
production, esp. with annotations turned on
•Compiler (Reflection+Scanner)
(yesterday’s talk on ZendCode)
Compiled into an array; used with
ArrayDefinition
•By-Hand
ClassDefinition
BuilderDefinition
43

Demo Time
•Live Demo Time
•Code:
https://github.com/ralphschindler/Zend_DI-
Examples
Uses ZF2 Beta Phars
44

Other Containers
•Yadif (beberlei)
•Pimple (Fabien Potencier)
•Symfony Di Container for 5.3
•PicoContainer
more than 5 years old
45

ZendDi Todo
•Further divorce the Service Locator /
Dependency Injection Container
•Service locators can be defined by
callbacks (closures)
46

Thanks!
•Questions, Concerns?
•Thanks!
47