Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Adrian (66)

Adrian
  adrianh@quietstars.com
http://www.quietstars.com/

The hats I wear at work include: accessibility consultant; information architect; software developer (of the agile/XP/TDD breed - mostly in Perl); usability consultant; web site designer. I'm very dull:-) . [technorati.com]

Journal of Adrian (66)

Monday October 17, 2005
05:59 AM

Dependency Injection rocks!

[ #27210 ]

Since there aren't comments on his blog I'm gonna take a mild poke at Artistotle's recent Dependency Injection post here :-)

He asks, in relation to Fowler's DI article:

Why do the design patterns people come up with such ridiculously elaborate conceptualisations of perfectly trivial ideas?

First off, I'd disagree that these ideas are trivial. If it's trivial why do I see so much code with tightly coupled external dependencies? Why am I so often faced with applications where I have to mock up half the fardling world before I can test a single module?

The DI pattern might not be difficult to understand or apply - but the problems it can help solve are not trivial.

Now, I do agree that Fowler's exposition isn't an example of his best writing. It's a bit of a mish-mash article which is trying to cover at least four different things (what DI is, why it's useful to separate it from inversion of control, why it can be better than things like service locators, how this relates to the J2EE complexity backlash, etc.)

However it did do one hugely useful thing. It named Dependency Injection and separated it out from the more general Inversion Of Control.

I read and reread the definition, examined the flimsy code snippets carefully, stared at the nearly tautologic diagrams for roughly 10 minutes, trying to grasp the deeply profound idea but failing. It finally dawned on me, after investing much effort, that it was right there – only banal enough that it was obscured by the heaps of pontification. It turns out the concept is so trite I've used it more times than I can remember, without ever having thought of it as any kind of dinstinct idea.

That last sentence is a doosy.

The whole point of patterns is to describe and name common design strategies - and thank god for that.

If you don't have DI in your head as a distinct concept - something you can name and describe - then it becomes really hard to communicate that idea. Judging from the code I regularly encounter it's an idea that could do with a bit more communication :-)

Now Fowler has done the work of naming DI and separating it out from the more general inversion of control pattern I've been given the gift of a beautiful new communication tool.

My coding partner can say things to me like "Hmm... the fact that this code is pulling all it's configuration information out of these singletons is making testing a pain in the arse, maybe refactor it so it uses dependency injection?"

Think about how much information is in that question. Try communicating that intent without naming the design patterns "singleton" and "dependency injection" and see how long it takes.

I do think that part of the reason the descriptions of DI seem so clumsy to us Perl folk, is that it's a harder concept to put into code with languages like Java.

DI is pretty darn easy in dynamic languages like Perl, Ruby and Lisp. We can also do really neat things at runtime that mean we can solve the problems that DI solves with considerably less effort than Java folk.

Jim Weirich's nice OSCON presentation Dependency Injection: Vitally Important or Completely Irrelevant? does a nice job of highlighting this (and does a better job of describing DI too.)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Hey, thanks for the feedback. :-)

    Yeah, Kragen Sitaker argued the same when I mentioned my article on IRC. To that I argue that the value of the Dependency Injection moniker is not in itself, so much as it is in naming the concept of a Dependency. If you recognise dependencies as such, then injecting them just falls out naturally from good OO design sense – that’s what I am saying in that article.

    Don’t miss my follow-up [plasmasturm.org] either on Henning Koch’s response [netalive.org] either, it picks up on som

    • Hey, thanks for the feedback. :-)

      You're welcome :-)

      To that I argue that the value of the Dependency Injection moniker is not in itself, so much as it is in naming the concept of a Dependency. If you recognise dependencies as such, then injecting them just falls out naturally from good OO design sense – that’s what I am saying in that article.

      I'd disagree with the "falls out naturally" bit. Well... kind of anyway.

      You're right that dependency injection techniques are a specific instanc