Dependency Injection Explained

Zbigniew ukasiak

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.

Dependency Injection is obviously about dependencies, but the 'injection' part is rather fuzzy.

I think that even for people who already do everything that defines DI it is still useful to know the name to talk about the code.

The DI libraries are less useful in languages with less prominent types.What is Dependency Injection?

The original definition Martin Fowler very complicated and hard to grasp.

No consensus on-line but it looks like something is emerging.First some intuitions.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.

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

Intuition II - Configs

Magic constants into configs.

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.

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.

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

Decoupling

A workaround or simplified DI

Intuition IV - Avoiding Globals

This is also decoupling.

Everything the object needs in its attributes.

And singletons are also globals!

Definition

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

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.

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

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.

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.

Example

Another take

What if we wanted to pass a special $dbh to LoginPage? Maybe we should pass $dbh there? Wrong too many params and we are not really using them pass UserRepository instead.

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

Testability

Can you do DI without DI container library?

Law of Demeter

Questions?

Opera Software is hiring!

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/

Click to edit the title text format