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.)