Dependency Injection

From APIDesign

Revision as of 21:16, 29 September 2010

A special form of component injection following the classical Hollywood principle: the framework calls, and beans just react to such calls. See wikipedia::dependency injection.

Translation Basics

During our JavaOne2010 talk about Modularity patterns we compared dependency injection and injectable singletons. As the comparison was well accepted and as I think it revealed some things that were just implicitly present in our minds, here is an explicit enumeration. Here is the beginner's guide to modularity for dependency injection (namely Spring) fans.

Imports vs. Dependencies

Foremost, for some obvious, difference when bringing the DI knowledge to the modularity world is where to find the set of dependencies of a single component. The answer is simple, but let's seek it the longer way.

The DI fans often look at the code from the perspective of individual source files. Often one can find advice to create an interface (in this case really the Java interface, not just an abstract definition) next to the class that is using it (something like BankAccount) and also define its implementation (like BankAccountImpl) next to that interface. So all these classes, the BankAccount, its implementation BankAccountImpl, and the class Transfer which needs two accounts to move money back and forth are in the same package next too each other.

This is something a true believer in modularity would never do. Why separate BankAccount from BankAccountImpl when they are packaged together? Why make a publicly visible API like BankAccount Java interface, as that limits future evolution as argued in Code Against Interfaces, Not Implementations chapter? The only reason to make BankAccount interface (either Java interface or abstract class) is to allow someone, unknown for the current moment to implement it and register it sometimes later!

So where is the difference? Dependency injection fans treat a single source file as a unit. The modularity guys treat the whole set of sources compiled together as a unit. As a result, when worshiping DI look into import' section of each class to find its dependencies. When living in world of modularity , look into the javacs compile time dependencies (for example into Maven's pom.xml).

Versioning

Modularity is first and foremost created for a distributed world. A world, when software is compiled, linked, assembled and evolved by distributed groups of people, on their own individual schedules, independently. This reflects in making the compilation unit the unit of dependency. When compiling one can reference other such units made by others long time ago. Such units then need an identification, a version number. Hence the versioning is inherently present in the way modularity users build their applications. That is why evolution plays so strong role when dealing with this kind of systems.

Of course, neither applications using DI live in vacuum. They may require external libraries in their environment, they may even be split into multiple parts. But unless they explicitly decide to enter the world of modularity (by creating a framework to be used by others distributed elsewhere), they are usually compiled as a whole at once. As a result the units of DI (aka individual source files) don't need any versioning with respect to each other. They either compile or not. You can change them as you wish. The new version either compiles, or not. No emphasis on evolution is needed.

Application Factory & co.

TBD: Modularity (aka OSGi or NetBeans Runtime Container) provides only global application factories.

Initialization

TBD: Inherent in modularity. Verbose in DI.

Injection

TBD: Composable (e.g. no master description) in modularity. Explicit in DI.