Dependency Injection: New Ground or Solid Footing?

Spring and other dependency injection frameworks have really paid off for many developers in terms of reducing coupling, improving unit testing, and cleaning architectures.  As architects, it is helpful to understand the history of a technology in order to properly understand the situations where it is best applied, its limitations, and its future direction.  For example, knowing that EJBs came out of the CORBA world and that SOA is an evolution on Message-Oriented Middleware (MOM) systems helps architects understand the place of these technologies in the software world.  For many, however, DI seems to come out of nowhere.  

Andrew McVeigh has written a detailed history of dependency injection, summarized here.   McVeigh is an academic that is working on  architecture description languages (ADLs) as part of his  Ph.D.  He has also worked with Rod Johnson on a commercial product.  

While DI may not have directly sprung from ADL efforts, McVeigh says that ADLs and DI are similar methods to solve a common problem.  This is similiar to convergent evolution, whereby, for example, birds and bats have separately evolved similar structures, wings, that are well-suited to an important behavior, flying.  

McVeigh writes:

To academics familiar with the research behind software components over the last twenty years, it is clear that DI is very closely related to a well-established area of software research known as architecture description languages (ADLs).  The job of an ADL is to assemble or wire components together via configuration....In fact, the Spring bean configuration language is (technically speaking) a non-hierarchical ADL with implicit connectors.  

McVeigh provides this definition of a software component:

A component is a unit of software that can be instantiated, and is insulated from its environment by explicitly indicating which services (via interfaces) are provided and required.

McVeigh compares software components with electronic components since both should be "interchangeable, tangible units which are clear about which services they provide and which services they require."  As you wire up your receiver, speakers, DVD, and your new 96"  HDTV, the  shape of the input and output connectors explicitly inform you which services each component requires and provides, respectively.  

A Java or .Net class is not a component per se.  A class can describe what it provides by means of its interfaces, but it does not declare exactly what it depends on to run.  It is true that method types declare what a specific method requires, but nothing declares what is required by the class as a whole.   Spring and other DI containers fill this gap by allowing class annotations or external configuration files to explicitly declare what a class requires.  Configuration together with a Java class creates a software component that almost meets McVeigh's definition. Spring Bean's fall just short of McVeigh's definition of a component because for Spring the connectors are implicit - you can only set the bean property and Spring simply calls the setter.  

A major feature of ADL's is the fact that the connectors are explicit.  It's not just loose wire, but a cable with an HDMI connector on the end.  The explicit nature of the connectors provide ADLs with interesting architecutal features, including improved testability and improved architecural tooling.  In certain ADL's the connectors can be more functional.  They can act like components in their own right, by performing extra functions like filtering or error handling.

Another major differentiator between ADLs and current DI technology is the notion of a Composite Component.  Once you've wired all your electronics together, you have a Home Entertainment System.  Yet, it isn't like Frosty the Snowman.  There is no additional entity that magically appears once everything is put together just so.  Your Home Entertainment System is nothing but the components and the wires that connect them.  

Using McVeigh's ADL language called Backbone, you can create a new Composite Component by wiring up existing components.  You can't perform this trick with Spring today since every Spring bean must be associated with a class.  Despite it's power, Backbase is much easier to read than Spring XML configurations.

McVeigh narrates and interesting history of ADL.  The first ADL was Conic, written in Pascal and used in distributed computing in the 1980s.  Another ADL, Darwin, influenced COM.  The UML specification contains an ADL that was influenced by Rational Realtime and the ROOM methodology.  

Some of the future directions of dependency injection that McVeigh details include:

• The ability to swap out components at runtime.
• Evolving systems over time by capturing the change sets in ADL.
• Fractal-like composition - being able to drill into a layered system and see composite components at every level.
• GUIs - a natural fit for composite development
• Architectural design and analysis tools.

Finally, McVeigh laments the disconnect between academic and industry in software development.  Academics aren't interested in the industry's trodden ground and academic work is inaccessible to industry, and may be considered not worthy of production.  Yet it's apparent both could gain by a closer relationship.

McVeighs shows us that not only is Dependency Injection here to stay, but it has a long history and an interesting future.
*Note: editted Feb 1st in response to reader comments