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.)
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 either on Henning Koch’s response either, it picks up on some of your argument.
It’s interesting that you’d say DI is easy in Perl and other dynamic languages: I said the same in the comments on Henning Koch’s article…
Re: Dependency Injection Rocks
Adrian on 2005-10-30T10:36:06
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 instance of the more general technique of removing hard coded dependencies. However I don't think that for many people the specific techniques of dependency injection are necessarily particularly obvious.
To put it another way. The naming and description of Dependency Injection is a really good pedagogical tool for highlighting certain kinds of dependencies, and demonstrating a variety of ways of removing them.
Indeed all design patterns are like this. The definition of design pattern could almost be something that "falls out naturally from good OO design sense"
:-) In my experience people learn best from examples - and that's what design patterns are. Little nuggets of easily digestible good design.
There's also the rise of the dependency injection frameworks. I'm uncertain that this would have happened without the naming of Dependency Injection.
I know that since I started reading about IoC/DI I started noticing where I've been doing dependency injection in my own code. The thing that I hadn't noticed, until clever sods like Fowler went and named it, is that I'd been doing the same thing in a variety of different ways.
Now that I've noticed that I can start thinking about better ways of abstracting out the DI stuff from the rest of the code, which is going to make the main flow of control easier to grok.
