3. WAYS TO FULFILL
DEPENDENCIES
Create the collaborator within a constructor/
method.
Perform a look-up for a collaborator.
Pass the collaborator from outside.
using a Constructor.
using a Setter.
4. 4
INJECT DEPENDENCIES
First of all, avoid concrete instantiation of
collaborator objects within a constructor/method of
an object.
Avoid making call to ‘new’
If you still have to do it, then encapsulate call to ‘new’
by using
A static Factory Method
Factory.
Builder.
5. 5
INJECT DEPENDENCIES/
CLOSURES
Second option, do a “look-up” for the collaborator
object
Use a Service Locator.
Third option, inject concrete implementation of a
collaborator in to an object at run-time.
Use a DI Container.
Fourth option, inject code block instead of a
collaborator.
6. 6
A GENERAL GUIDELINE
Short Answer
Dependency Elimination is better than Dependency
Inversion
Long Answer
Favor Closure Injection
(where its possible and sensible)
over
Dependency Injection
over
Look-up
over
Concrete Instantiation.
7. SETTER OR CONSTRUCTOR
INJECTION?
A tell tale sign of exposing internal implementation
manifests as bunch of getters and setters on the
object.
Setters and Getters break the Command/Query
Pattern (Tell, Don’t ask principle)
Inject collaborators in Constructors.
10. GUIDELINES OF THUMB
Pass only Real Dependencies through constructors.
Without which an object cannot fulfill its responsibilities.
For Policies and Parts
Provide Defaults and allow them to be set through Setters.
For Notifications
Provide NULL/EMPTY Listeners as default and allow new ones
to be added/removed using “Adders/Removers”
11. I STILL HAVE A BIG
PARAMETER LIST?
Too many things going on or
have more than one concept in that object (SRP violation).
Break-up the object.
This will collapse the parameter list.
12. 12
THE RESULT?
Fewer unintended consequences from code changes
and more flexibility in your systems.
Creates Objects that are isolated from each other.
Makes large scale re-structuring of the system possible.
13. 13
VALUE OBJECTS
Must have value semantics.
Immutability
Value once set, cannot be changed.
Operations on them, returns new value objects
Object’s Identity is its value
Equality
Strive to reuse value objects
14. REFERENCES
Agile Principles, Patterns and
Practices
Robert C. Martin and Micah
Martin
Object Design
Rebecca Wirfs-Brock and Alan
McKean
Alec Sharp
The Pragmatic Programmers
Mock Roles, not Objects
Paper by Steve Freeman, Nat
Pryce,Tim Mackinnon, Joe
Walnes
InfoQ presentation by
Steve Freeman and Nat Pryce
Head-First Design Patterns Book
Venkat Subramaniam’s Blog
