Dependency injection is a technique where object dependencies are passed into the constructor rather than being created within the class. This removes distractions, allows dependencies to be configured externally, and decouples classes by removing hard-coded dependencies. A dependency injection container handles the complex wiring of dependencies to further simplify object creation code and improve testability.

1. Dependency Injection Explained
Zbigniew Łukasiak

2. Why DI is such an elusive idea?
The name.
The original article by Martin Fowler.
Sometimes people say it is all commonsense.
Conflating DI with tools that support it.
Thinking that it is just a Java concept.

3. What is Dependency Injection?

4. Intuition I – removing distractions
Having all dependencies created before the work
starts is removing distractions.
It is like having all the tools assembled and ready.

5. Photo: http://www.flickr.com/photos/fotoosvanrobin/

6. Intuition II - Configs
Magic constants into configs.

7. Configs
But what if you needed { RaiseError => 1 } ?
Connection creation into config!
Object Oriented Config.
Why we do that?
The constants change more frequently.
We want non-coders to be able to change them.

8. Intuition III - Decoupling
The code creating
objects is coupled to
their exact
implementation.
If we move this
creation code out
from our 'business
logic' – we make it
more general.
And easier to test.

9. Decoupling
This lowers rank of coupling from control
coupling to data-structured coupling
This code was copied from a library we used –
we needed a more restrictive UserAgent and we
had to override the whole fetch subroutine
instead of changing only one field
You can also say that LWP::UserAgent was a
magic constant there

10. Decoupling
A workaround – or simplified DI

11. Intuition IV - Avoiding Globals
This is also decoupling.
Everything the object needs in its attributes.
And singletons are also globals!

12. Definition
Dependency Injection is the practice of
passing all object dependencies to its
constructor.

13. Consequences
No globals.
All object creation is separated from 'business
logic'.
This separated code walks the dependency tree
and recursively creates the nodes – it 'wires up'
the application.

14. Example from http://fabien.potencier.org/article/16/symfony-service-container-the-need-for-speed

15. Dependency Injection Container
The object creation code is very hard to debug
and test, ergo it should be as simple and
minimal as possible.
In many cases it can be automated – this is what
DI libraries can do.
How many containers in your program? You
choose. Or the library. But you need at least
one per scope.

16. What is scope?
You cannot create an object before you have all
information needed.
For example in a web app you have two main
scopes: the application scope and request
scope. The objects in request scope cannot be
created before the user sends a request to your
service.

17. Example

20. If you use the connection somewhere don't
retrieve it from some global object – pass it
there explicitly.

21. Testability

22. Can you do DI without DI container library?

23. Law of Demeter

24. Questions?

25. Opera Software is hiring!

26. http://misko.hevery.com/
http://misko.hevery.com/code-reviewers-guide/
http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/
http://blacksheep.parry.org/archives/diy-di/print/