Dependency Injection
From APIDesign
(→Translation Basics) |
(→Imports vs. Dependencies) |
||
| Line 7: | Line 7: | ||
=== Imports vs. [[Dependencies]] === | === 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 [[modular]] world, look into the ''javac'' compile time [[dependencies]] (for example into [[Maven]]'s ''pom.xml''). | ||
=== Versioning === | === Versioning === | ||
Revision as of 20:52, 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.
Contents |
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 of 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 modular world, look into the javac compile time dependencies (for example into Maven's pom.xml).
Versioning
TBD: No versioning in DI.
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.
Follow
