IoC > Dependency Management

Inversion of Control is a design pattern in which a software component relinquishes control over something to some other component, often dubbed a container. The question is “what to invert?” What should the container be responsible for?

Several frameworks and contrainer platforms such as PicoContainer, Avalon, and the Spring Framework offer support for inversion of dependency management—that is, the components are not responsible for gathering or instantiating their dependencies on other components or resources. Instead, the container supplies these dependencies to the component in one of several ways. Martin Fowler has recently christened two of these methods the Dependency Injection and the Service Locator patterns.

But is that really all there is to IoC? I don’t think that’s Fowler’s arguement, but I’ve heard a number of definitions and explainations about what this design pattern is really about. 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. It’s about finding the balance between container management and component self-management. One school of thought is that the component should have all of it’s aspects and resources managed by the container. In fact, the Avalon approach is essentially along these lines. Other frameworks offer varying support of IoC in the aspects of lifecycle, lifestyle (singleton vs. transient vs. pooled…), and configuration.

One thing I do want to point out about Configuration IoC—it’s often missused. IMHO, a good Configuration IoC framework will offer proper abstraction from the underlying configuration mechanism (be it XML or Beanshell or whatever). Moreover, when used in a container framework, the configuration should be centralized. That is, configuration is it’s own seperate concern. It also means that the component shouldn’t really know or care about where the configuration came from or how it was stored. That’s a container matter. To do this, you can offer a proper configuration API (like Avalon) or even use plain ol’ java data objects. Point is, just having the container pass a URL to some XML configuration file isn’t quite true IoC or Separation of Concerns (and I’m guilty of this one in the past).

The point of this little rant is to reiterate that IoC is about more than just dependency resolution—it’s about inverting ANY type of control. And each IoC framework needs to clearly understand what it is inverting and why.

Oh, and I happen to be giving a presentation on IoC Frameworks for my local Java Users Group soon. I’m putting together material from the presentation and a short tutorial on my site that compares PicoContainer and Avalon Fortress. Should be a nice introduction to either framework.