Inversion of Control Design Pattern for light weight Java

devx Article
Assume Class A has a relationship with Class B: it wants to use the services of Class B. The usual way to establish this relationship is to instantiate Class B inside Class A. Though this approach works, it creates tight coupling between the classes. You can't easily change Class B without modifying Class A. To eliminate the coupling, you can have a Configurator inject the instance of Class B (Object "b") to the instance of Class A (Object "a"). If you want to change the implementation of Class B later on, you simply change the Configurator object. So, the control of how Object "a" gets the reference of Object "b" is inverted. Object "a" is not responsible for getting the reference to Object "b". Instead, the Configurator is responsible for it. This is the basis for the IoC design pattern.

PicoContainer - Inversion of Control: "Simply put, a component designed according to IoC does not go off and get other components that it needs in order to do its job. It instead declares these dependencies, and the container supplies them. Thus the name IoC/DIP/Hollywood Principle. The control of the dependencies for a given component is inverted. It is no longer the component itself that establishes its own dependencies, but something on the outside. That something could be a container like PicoContainer, but could easily be normal code instantiating the component in an embedded sense.
Examples

Here is the simplest possible IoC component :

public interface Orange {
// methods
}
public class AppleImpl implements Apple {
private Orange orange;
public AppleImpl(Orange orange) {
this.orange = orange;
}
// other methods
}

"

Martin Flower