Till's blog

Me, myself and DI

I think the first time I remember someone mention dependency injection was in late 2009 — I saw a talk on DI at the PHP Unconference in Hamburg. I remember sitting in the sessions thinking — "Well, duh. That's what everyone is supposed to do. Good thing someone came up with a catchy name for it!".

I guess that even in 2009, I was pretty late to the game and because I spend most of my time with PHP and related, I figured that Ruby and Python developers probably caught onto the term much earlier. Let alone Java people who live and breath all these catchy patterns.

By that time Symfony (1), had already started their infamous DI container project along with some great documentation to explain what DI (sans container) really is:

Enter Dependency Injection. Instead of creating the SessionStorage object inside the User class, let's inject the SessionStorage object in the User object by passing it as a constructor argument: ... That's Dependency Injection. Nothing more!

(Hope I'm getting some props for linking to Symfony here!)

The good news is that if the Symfony(1) managed to do one thing, they at least tried to make DI popular within PHP. The bad news is that PHP developers are ignorant and don't realize that DI is a re-branded (object-oriented) concept which existed long before Martin Fowler decided to write about it.

Enter 2011

Fast forward two years later and with the wake of Symfony 2, DI containers are the so called new shit. Must have a DI container!

Maybe I'm not getting it, but I think foremost a DI container adds a level of abstraction that is not just not necessary, but also counter-productive. For me a DI container is a registry pattern on steroids, but let's start slow.

Generally, there are two advantages to said registry pattern:

• accessing data in different parts of the application
• storing data for later retrieval

While that makes a registry OK, people end up writing crappy code like this:

function foo() {
    $db = registry_get('db');
    return $db->query("SELECT foo FROM bar");
}
var_dump(foo());

... while they should be doing something like this:

function foo($db) {
    return $db->query("SELECT foo FROM bar");
    //...
}
$db = registry_get('dbConn');
var_dump(foo($db));

(Keep in mind, it's just an example.)

Is the pattern to blame? Or its mis-use? Or the framework enabling it? Or all?

DI container vs. registry

I'm guessing that both patterns can be used and abused.

But while the registry had to be explicitely created and setup, a DI container is configured using a configuration file and creates all these objects on the fly — for you. Which reminds me of another great pattern called singleton.

Make no mistake, but I believe that all design patterns have a right to exist.

But the impression I get is that people mistake them as general solutions.

Problem?

Since most people embrace DI like sliced bread, let me share the obvious drawbacks I see.

1. Moving away the obvious dependencies from an object makes applications complicated, harder to understand and more difficult to extend.

2. Code becomes magical (for some people) because creation and initialization of dependencies is abstracted away from them and handled completely seperate somewhere else in the application.

3. Seperation can also lead to issues being harder to diagnose

4. Convention over configuration usually clashes with the approach DI containers advocate.

5. Missing support in IDEs.

6. Inline code documentation — people don't even get __call() etc. right.

7. Seperation of concerns and decoupling of dependencies are goals people advocate but they seem to apply to everything but the DI container (object).

8. I'm certainly not going to advocate C- over PHP-code, but let me just say: nothing is free.

Fin?

So all in all I understand where you are coming from, but I reserve the right to disagree.

I hope I provided a little more detail as of why I disagree and why I'm certainly not a lost PHP developer.

Getting another perspective!

I had previously written the above paragraphs, but waited to post this blog entry because Lukas Smith offered some inside on all things DI (container).

And after I talked to Lukas during the PHPBBQ / Github meetup this weekend, I'm still not a fan of DI containers but he (and Kai) shared another perspective with me: testing.

A DI container is indeed useful when you need to swap out a dependency in a different environment (e.g. production versus testing) and (hopefully) everything continues to work. I'm trying to remember when I wrote relatively low-level PHP that I needed e.g. to swap out cURL from a class to mock it and I don't remember anything right now.

Abstraction FTW

I think in most cases I rely on some sort of abstraction already. For example, I really dig HTTP_Request2 which via driver pattern allows me to select curl, socket or even mock. I'm not sure if using that via a DI container would be any better (see above).

When I mock, I focus on the code I've written on top of it. I'm not actually testing HTTP_Request2 in that case.

Containers for the lazy?

Lukas also mentioned not having to implement set*() for all kinds of things because with a container you're able to swap out the dependency somewhere else.

I can see that this might be problem for some people, but I disagree also. For the sake of testable code it's paramount to have these because using a DI container inside your tests is really not appropriate. This might be extreme, but in my opinion using a container defeats the purpose of a unit test — it's supposed to be stand-alone.

Complexity

I just can't see myself using Symfony2 components any time soon. Maybe when it matures and what not, but currently that code-base is a moving target.

I'm inclined to check out Pimple some time though, which seems to be a very lightweight DI container for PHP 5.3. The amount of closures in their examples though, don't exactly make me want to debug anything that comes from it.

Fin

That's all. Thanks for reading this far.