Inversion of Control and Dependency Injector Pattern
Martin Fowler has pubished a new article:
bq. In the Java community there’s been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of “Inversion of Control”. In this article I dig into how this pattern works, give it the more specific name of “Dependency Injector”, and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.
Joe Walnes 
The PicoContainer team has decided to embrace this new pattern name: “Constructor based Dependency Injection”. This means that we will update the documentation and get rid of the (now obsolete) “IoC type 3” term.
See! I was right all along in my evaluation of thoughtworks employees.
Hani!
So IoC was basically a new name for DIP (Dependancy Inversion Principle) now has another new name?
Whatever you call it, the pattern is a good one. Now can we go back to talking about how we use it rather than what its called?
Don’t underestimate the importance of establishing an unambiguous vocabulary. If the name of the pattern doesn’t convey anything meaningful about the principles of the pattern, people are going to have a hard time using it.
DEPENDENCY INJECTOR!! :-)
Now, what did you want to know about the usage of it?
Should the setter injection for the spring framework be called metadata injection then?
Aslak, you do have a point (actually a point I myself made on my blog a while back but conveniently forgot!). I’m actually a little annoyed because:
a.) We now don’t have a nice TLA for it, like we did for DIP or IoC
b.) I just wrote a bloody article on the topic of IoC and now everyones gone and changed their minds about what its called
Anyway, if PicoContainer is now a Constructor based Dependency Injection framework, and Spring a Property/Setter based Dependency Injection framework, is Avalon a Service based Dependency Injection framework? The definitions of the 3 types of IoC frameworks still remain valid if we are talking about Dependency Injection, so we should still be able to talk about Type 1,2 and 3 frameworks I guess.
Fowler called Avalon’s approach “Interface Injection”, since it uses interfaces to determine what gets loaded. Personally, I agree with Fowler’s point that “Interface”, “Setter” and “Constructor” as the three different types of Dependency Injection are easier to remember than Type 1, 2 and 3.
Kevin, that makes sense to me. Personally the people that talked about Type 1 IoC providing depedencies via services made no sense to me (in so much as EJB is type 1 IoC but doesn’t use services in the same way as Avalon)
Dependency Injection is just a way of resolving dependencies in IoC. The are no equality here.
What a confusing term. Dependency information is not injected anywhere, it is pulled out of the objects internals and grouped at the point at which they are constructed (where it should have been all along in a proper OO design).
I don’t understand why nobody uses any of the existing names for this architectural style (some which go back oh, 20 years at least).
So I have built this plugin engine, similar to Eclipse. It is small, handles plugin lifecycle, dependencies, versioning, load/unload/reload at runtime, embeded jar/zip files within a single archive file (without needing to unzip to dir to use them at runtime), built around extension points and extensions. What is this then? Is it IoC? Or is it something else? It is built on the idea of using small, pluggable modules that can easily be worked into any application, shared across applications, etc. Being only 45K in size with embeded xml pull parser, I like to think of it as yet another container, perhaps a bit more than these IoC containers, but not sure.
Avalon is not dependency injection, it is service location. It’s just that the service locator is then injected. According to the avalon definition of IoC, locating the service locator yourself is not IoC.
I thought Martin’s article gave a clear explanation of the differences between dependency injection and service location. However, for me it missed the key point of constructor dependency injection: Simplicity.
When using Constructor Dependency Injection and TDD, your tests and classes can contain no infrastructure code to do with satisfying dependecies. It is easy to see what you are testing and what you are mocking.
Whilst it is certainly possible to do TDD with the service locator pattern, the set-up and teardown code required makes tests unwieldy.
“I don’t understand why nobody uses any of the existing names for this architectural style (some which go back oh, 20 years at least).”
Because Fowler likes to blow them off his ass and get credit for them with all the seriousness of a guy who is saving the world. Oh Fowler, shut up already.
I like you Pinocio, because other than all these kiss asses that write here, you stand up and take a stand. My God, it is enough, i am sick of Fowler’s patterns, he is gonna call the way i pick my nose a pattern one of these days, and all these idiots are going to start using it.
And it is funny, how now PicoContainer which is the b utt of jokes (sorry, is it needed? what the fuck is it for) are going to gain legality as a pattern itself. Phew, this stinks.
Note: Pinocio didn’t write the comment you refer to.
Dependency Injectors and a request for some Pragmatism
I recently took offence at the fact that Martin Fowler has decided that the well known phrase Inversion Of Control was no longer suitable, and instead decided to rename it Dependency Injector. Among my reasons for this annoying me (beyond…