ooGlossary.comIoC, or "Inversion of Control" (also commonly referred to as "Dependency Injection"), is one of those confusing technical terms that refers to something commonplace in programming. Once the term is explained, the meaning becomes obvious and people scream "Why didn't you just say that??!!"
The term "inversion of control" simply means that in one scenario myObject would contain code to create an instance of myDao, and we're inverting that, so that myObject expects someone else to control myDao on it's behalf and it only expects it to be available for use. "Dependency injection" means that any object myObject might depend on (like myDao) is "injected" into myObject instance data rather than created directly by myObject. The upshot is a myObject that can be portable and flexible and used with any number of children and/or implementations of myDao, that it's not dependent on any particular path to the file that contains myDao, and that, in general, the higher you get in your model's composition tree, the more responsibility any given object might have for it's "servants".
There are 2 basic techniques used in IoC: setter injection and constructor injection. The latter is simply a way to replace this:
with this:
(outside myObject)
and this: (inside myObject's init() method)
The idea is to minimize coupling by making any object that wants to use another object responsible for setting up any dependencies and then passing them on to the target object rather than hardcoding dependencies into the target object. This makes a system more flexible and able to adapt to changes or alternative uses without having to edit the code of your lower-level classes.
In other words, myObject is written to rely on myDao, but not to CREATE myDao... it expects that it will be handed an instance of myDao to use at some point before it needs it.
The other technique, setter injection, is basically the same as constructor injection except that instead of passing myDao into myObject.init(), it will be passed into myObject.setMyDao(myDao) at some point before myObject is expected to use the DAO for anything.
Frameworks like ColdSpring (CS) help make this process (which sounds like a chore) quite simple by allowing you to use an XML grammar to specify which objects are dependent on which others and then automate the creation of any given instance... simply calling ColdSpring.getBean("myObject"), CS is able to determine what myObject expects, set up any requirements, create the instance of myObject and return it to the caller.