Notice that the preferred term is Dependency Injection.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I have not read HFDP thoroughly but I sincerely feel that IoC can be best attributed to template method design pattern.GOF says
"...framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate, and the thread of control. A framework predefines these design parameters so that you, the application designer/implementer, can concentrate on the specifics of your application. The framework captures the design decisions that are common to its application domain. Frameworks thus emphasize over code reuse, though a framework will usually include concrete subclasses you can put to work immediately.
Reuse on this level leads to an inversion of control between the application and the software on which it�s based. When you use a toolkit (or a conventional subroutine library for that matter), you write the main body of the application and call the code you want to reuse. When you use a framework, you reuse the main body and write the code calls. You�ll have to write operations withparticular names and calling conventions, but that reduces the design decisions you have to make."
doesn't it sounds pretty much like template pattern which says
"Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm�s structure."
so whenever we are creating frameworks ..we are having a class hierarchy with lots of aggregation, composition and delegation..but essentially we are writing some code our selves and expect that the framework we do the rest...we use hooks or what is also called Callbacks to make sure the framework calls the rest of my method ..
We're getting two things by the same name. I liked "inversion of control" for the kind of template or framework stuff Raghubir described. It means the framework controls the sequence and logic of some operation and calls your code to provide certain details. For example, an EJB container controls the life cycle of a bean and calls your methods to do interesting things at the right times - create, do service, activate, passivate, etc.
"Dependency injection" is about gluing components together at runtime to avoid hard dependencies at compile time. For example you code to JDBC standards, but we hook up a particular driver from configuration at runtime. Or in your own code you might write all your code to a persistance API but plug in the persistance implementation at server startup. This is very cool for testing; you can plug in a test version of persistance that doesn't need a database or any files set up ahead of time.
The confusion over the two things by one name goes back to some early papers, but we don't need to keep the confusion going.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Feb 18, 2006
I am a bit busy with my certification but ..could not help providing this link ... I hope most of us have seen this ...this is can be read as a sequel to this discussion
Yeah, that's the guilty article. It has both Inversion of Control and Dependency Injection in the title, and I had trouble keeping track of which he was talking about at all times. I think it has led more than a couple folks to say Inversion of Control when they're really talking about Dependency Injection.
I use an "application assembler" flavor of injection in several places. One component reads configuration and connects other components to each other. The dependency list for the assembler is scary looking but it gets all the ugliness into one place. Not perfect by any means, but nicely isolated.