Software Evolution: Inversion and Injection
by Jon Stonecash
Wed, Oct 01, 2008
Room:
Time:
0:00
Useful software evolves and adapts to changing needs. This continuing change cannot happen if the software design and implementation is riddled with dependencies: A change to module A triggers changes in B and C, that collectively, trigger more changes in D, E, F, and G and so on until the software explodes. This sounds like a terrific special-effects movie but a very bad information technology experience. There are design practices that build "fire walls" that isolate one part of the software from other parts, but ultimately the question becomes, how can one part of the software invoke the services of another part without becoming dependent on that other part? This sounds very much like a Zen riddle: "What is the sound of one hand clapping?"
Enter the twin concepts of Inversion of Control and Dependency Injection. With Inversion of Control, when a particular module of the software is dependent upon a particular service, say logging, that dependency is abstracted down to an interface. Any invocation of the logging function is made against the interface. Before the module can execute, it must obtain a reference to an object that implements the interface. There are a lot of ways to accomplish this: 1) passing the reference as a part of instantiating or invoking the functions of the module, 2) returning the reference from a factory method, and 3) injecting the dependency reference as part of a Dependency Injection framework.
We will look the design patterns for Inversion of Control and demonstrate code that uses the following Dependency Injection frameworks:
- Castle Windsor
- StructureMap
- Unity
- Spring.NET
About the Author
Jon Stonecash is a Senior Consultant at Magenic. Jon Stonecash has worked in software development for much longer than he would like to admit. In that time Jon has had the opportunity to make most of the serious software development mistakes at least once. He has programmed in over a dozen languages including several different assembly languages, Fortran, COBOL, SNOBOL, classic Visual Basic, VB.NET, and C#. He has survived the structured programming revolution and the object-oriented revolutions (having inexplicably missed out on the sexual revolution). Jon's software development activities have included the development of operating systems, scientific and engineering applications, and enterprise systems. He has worked in every phase of software development from the initial specification of requirements through to customer support. Along the way, he picked up a BS in Mathematics and an MBA. He still has hopes of finding something that he can be reasonably good at. His long term interests center about databases and the aspects of the application that handle data access and business logic. He is also interested in the tools and processes that assist the development process. Jon can be reached at jons@magenic.com.