April 05
Prof. Ismael H. F. Santos -  ismael@tecgraf.puc-rio.br                                                          2
nIoC can be thought of in terms of what distinguishes a framework from library.
nA Library performs some work when called and returns to caller. Framework encapsulates some abstract design incorporated with behavior but to use you must incorporate your unique behavior via callbacks or sub-classing.
n
nIoC is a principle that is used to wire an application together, how dependencies or object graphs are created.
n
nIn Spring, the IoC “flavor” is referred to as Dependency Injection - DI.
Inversion of Control (Dependency Injection)
Inversion of Control has already been referred to as Dependency Injection. The basic principle is that beans define their dependencies (i.e. the other objects they work with) only through constructor arguments or properties. Then, it is the job of the container to actually inject those dependencies when it creates the bean. This is fundamentally the inverse (hence the name Inversion of Control) of the bean instantiating or locating its dependencies on its own using direct construction of classes, or something like the Service Locator pattern. While we will not elaborate too much on the advantages of Dependency Injection, it becomes evident upon usage that code gets much cleaner and reaching a higher grade of decoupling is much easier when beans do not look up their dependencies, but are provided them, and additionally do not even know where the dependencies are located and of what actual type they are.
As touched on in the previous paragraph, Inversion of Control/Dependency Injection exists in two major variants:

•setter-based dependency injection is realized by calling setters on your beans after invoking a no-argument constructor to instantiate your bean. Beans defined in the BeanFactory that use setter-based dependency injection are true JavaBeans. Spring generally advocates usage of setter-based dependency injection, since a large number of constructor arguments can get unwieldy, especially when some properties are optional.

•constructor-based dependency injection is realized by invoking a constructor with a number of arguments, each representing a collaborator or property. Although Spring generally advocates usage of setter-based dependency injection as much as possible, it does fully support the constructor-based approach as well, since you may wish to use it with pre-existing beans which provide only multi-argument constructors, and no setters. Additionally, for simpler beans, some people prefer the constructor approach as a means of ensuring beans can not be constructed in an invalid state.