Jan
20
IoC is not just Dependency Injection
Jeffrey Aaron Farr has managed to “accurately sum up(IoC > Dependency Management)”:http://www.jadetower.org/muses/archives/000020.html some of the points I’ve been wanting to make concerning the feedback (mine included) to the “recent article(Inversion of Control Containers and the Dependency Injection pattern)”:http://www.martinfowler.com/articles/injection.html by Martin Fowler, and has done so far more eloquently that I would of. He correctly points out that IoC is about more than resolution of dependencies, a point Martin himself makes in the article:
The conclusion I’m coming to is that, as Fowler points out, there are lots of forms of inversion with Dependency Injection merely one of them. For example, in all three of the container frameworks mentioned above you will find at least three types of IoC:
- Dependency IoC
- Lifecycle IoC
- Configuration IoC
It’s important to recognize these other aspects as part of the IoC design pattern. IoC is not just about dependency management.
I did initially take issue with Jeffrey classing Configuration IoC as being different to Dependency IoC, although realised he may have a point. Clearly a dependency is something which a component requires to do its job – this may include information traditionally thought of as configuration data, such as the location of a database. What about a path for logging? There may be a default directory that can be overridden – in which case is this path a dependency, or simple configuration? In this case the path is not required for the component to work.
Clearly dependency is required before the object is used (something which Type 3 IoC containers such as PicoContainer can enforce), however many configuration-type values may be legitimately changed after creation, something which Type 2 IoC containers such as Spring would be very good at, but which Type 3 IoC containers could not do without recreating the component with the new configuration data. The question remains as to how useful configuration IoC would really be, although the “JMX”:http://java.sun.com/products/JavaManagement/ specification (which can be considered a Type1/2 IoC hybrid container) makes great use of it.
Sam, I’ve noticed repeatedly that you talk about Spring as a Type 2 IoC container. While this the style that we recommend, Spring supports both Type 2 and Type 3 since 1.0 M3, aka setter injection and constructor injection (and also Type 1 via BeanFactoryAware). We even arguably offer more sophisticated constructor resolution than Pico.
Furthermore, XML is by no means the only way to create bean definitions with Spring – it is just the most popular one. You can use programmatic registration via DefaultListableBeanFactory, or load definitions from a property file via PropertiesBeanDefinitionReader.
BTW, I also noticed that you consider Spring’s web framework too hard to set up. While there is certainly a tradeoff involved in terms of flexibility versus simplicity, I wonder what gave you that impression. I would be happy to accept constructive feedback! :-)
Juergen
Thanks for the clarification Juergen! You’re quite right concerning the configuration of Spring. As for providing Type 3 IoC I was unaware of this, as the last version I used was M2. Type 2 is of course required if you want to provide Configuration IoC (I am unsure if Pico can do this – if it can then it therefore follows that it also provides type 2 IoC).
As for the web framework being complex I was referring to needing to embed references in my spring config file and a separate property file etc. I think part of the problem is the system is so flexible that you can do too much, as a result it is less user friendly than configuring Struts for example.
I’ve decided to update my original piece on this including your suggestions – I’ll try and post it today
Hmm, anyone who says “IoC is not about dependency management” after reading Martin Fowler’s article missed his point. Mr. Fowler is not trying to redefine IoC or rename it. Rather he is saying IoC has had a well-defined meaning for years and not until very recently when these so called “IoC containers” popped up was there any misunderstanding what IoC meant. So he is trying to give a new, specific names to the pattern these containers use so they would *stop* confusing the whole naming issue trying to redefine IoC to something else from its original meaning.
Erm, I didn’t say it wasn’t about dependency management, or that Martin Fowler said it was – a fact that the inclusion of a quote from Jeffrey Aaron Farr’s post should make clear. As such my post is just reiterating the point for people (a point I think needs to be made as until recently I didn’t fully realise it).
I think sometimes Martin can be guilty of renaming stuff for the sake of it (some would say that it just gives us a richer language, I would argue that in many cases it can just promote misunderstanding) however in this case I do agree with him.