The
Inversion of Control principle has been getting plenty of attention in software architecture circles over the last year or so. The big question is whether it should be getting so much attention in the same vein with arguably "serious" architecture developments, like service-orientation.
I personally am torn since IoC, and its little brother, Dependency Injection, solve real problems on a daily basis for software designers and architects. IoC is a terrific way for a component to state explicitly, and also make configurable, its dependencies on other components, systems resources, etc. IoC also makes the increasingly automated world of software testing that much easier by giving test harnesses the control to inject dependencies. Test harnesses can send in mock objects that haven't been developed yet or run faster than the real thing. So in addition to real, practical day-to-day benefits, IoC gives us effective architectural control like pliability and pluggability using a pretty straighforward mechanism. So, what's not to love about that?
Well, a couple of things, and this is partially holding IoC back from real greatness. First, IoC technically breaks encapsulation since the implementation internals of an object, especially its critical dependencies, are exposed and changeable. This makes it easy to break the Liskov Substitution Principle, probably one of the most important concepts in a software engineer's toolbox. And second, since dependencies are now moved from within the object itself, to an external component, which often keeps the information in an non-verified configuration file, it makes typing, configuration management, and interface complexity a big headache.
Figure 1: Simple Inversion of Control
Fortunately, the IoC story continues to develop and get better. I just came across Sony Mathew's
articulate new treatise on IoC that was just posted on TheServerSide. In it, Sony discusses a much more streamlined new version of IoC, known as Context IoC, that doesn't use messy constructor dependency setters and has many powerful composability features. I am struck and encouraged by the power and simplicity of Sony's approach. I'm taking this as partial evidence of IoC's ongoing maturation, as well as the very cool new dependency injection features going into EJB 3.0, plus tons of exciting things happening in the industry (see Howard Ship's
comments on the HiveMind/PicoContainer faceoff as one small example).
In the end, IoC is here to stay, and I think encapsulation and LSP worries are explained away in a component-based world where all components must be a client and have explicit clients (ala UML's modeling the seams). The final arbiter will be the effectiveness of any tradeoff of malleability vs. stability. IoC creates a pivot point between the two since quick and easy non-compile time dependency changes can cause sudden, unexpected changes in system behavior for no externally obvious reason. For now however, I think the advantages are greater than the disadvantages and I'm casting my vote with IoC for now. I do, however, reserve the right to change it later. :-)
Technorati: Enterprise Architecture, Computers and Internet, Programming