alo

April 05

Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 2

Inversion of Control (Dependency Injection)

nDependency injection (Martin Fowler – 2004)

nBeans define their dependencies through constructor arguments or properties

nDependencies used from within a bean aren’t asked for outwardly, but are injected into the bean by the container, ie the container provides the injection at runtime

n“Don’t talk to strangers”, also known as the Hollywood principle – “don’t call me I will call you”

nDecouples object creators and locators from application logic. Easy to maintain and reuse

nTesting is easier


	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.