What is Inversion Of Control(IOC)?

09:58 Spring 3.0 No Comments

Inversion of control or dependency injection (which is a specific type of IoC) is a term used to resolve object
dependencies by injecting an instantiated object to satisfy dependency as opposed to explicitly requesting an
object. So objects will not be explicitly requested but objects are provided as needed with the help of an Inversion Of Controller container (e.g. Spring etc).

This is analogous to the Hollywood principal where the servicing objects say to the requesting client code (i.e. the caller) “don’t call us, we’ll call you”. Hence it is called inversion of control.


Many of us are familiar with the software development context where client code collaborates with other dependent objects (or servicing objects) by knowing which objects to talk to, where to locate them and how to talk with them. This is achieved by embedding the code required for locating and instantiating the requested components within the client code.

Simple Code(Without IOC)

class TestSO {
  public void getSO(String Prop) {
      SoDAO dao = new  SoDAOImpl();
      List listSo = dao.find SoByProp(Prop);
     }
}

called code:

interface SoDAO (){
     public abstract List findSoByProp(Prop);
}

interface SoDAOImpl extends SoDAO (){
   public List findSoByProp(Prop) {
  }
}

This tight coupling can be resolved by applying the factory design pattern and program to interfaces not to
implementations driven development. Simplified factory class implemented with a singleton design pattern:

class SoDAOFactory {
 private static final SoDAOFactory singleton = new SoDAOFactory();
 private SoDAOFactory(){}
 public SoDAOFactory getInstance(){
 return singleton;
}

public SoDAO getDAO(){
   return new SoDAOImpl();
  }
}

Now the caller code should be changed to:

class SoTest {
 public void getSo(String Prop) {
 SoDAO dao = SoDAOFactory.getInstance().getDAO();
 List listSo = dao.findSoByProp(Prop);
}
}

But the factory design pattern is still an intrusive mechanism because servicing objects need to be requested
explicitly. Also if you work with large software systems, as the system grows the number of factory classes can become quite large. All the factory classes are simple singleton classes that make use of static methods and field variables, and therefore cannot make use of inheritance. This results in same basic code structure repeated in all the factory classes.


Let us look at how dependency injection comes to our rescue. It takes the approach that clients declare their
dependency on servicing objects through a configuration file (like spring-config.xml) and some external piece of code (e.g. Spring) assumes the responsibility of locating and instantiating these servicing components and
supplying the relevant references when needed to the client code whereby acting as the factory objects. This
external piece of code is often referred to as IoC (specifically known as dependency injection) container or
framework.

Look at SpringConfig.xml file below:

<beans>
<bean id="SoBean" class="SoTest" singleton="false" >
<constructor-arg>
<ref bean="SoDao" />
</constructor-arg>
</bean>
<bean id="SoDao” class="SoDAOImpl" singleton="false" />
</beans>

Now code will changes to below:

class SoTest {
   private SoDAO dao = null;
   public SoBO(SoDAO dao) {
     this.dao = dao;
    }
    public void getSo(String prop) {
       List listSo = dao.findSoByProp(prop);
    }
 }

Your calling code would be (e.g. from a Web client or EJB client):

    ApplicationContext ctx = new FileSystemXmlApplicationContext("SpringConfig.xml");
    SoTest  sOo = (SoTest)ctx.getBean("SoBean");
    String prop = "beneton";
    sOo.getSo(prop)

You can use IoC containers like Spring framework to inject your business objects and DAOs into your calling
classes. Dependencies can be wired by either using annotations or using XML as shown above. Tapestry 4.0
makes use of the Hivemind IoC container for injecting application state objects, pages etc.
IoC or dependency injection containers generally control creation of objects (by calling “new”) and resolve
dependencies between objects it manages. Spring framework, Pico containers, Hivemind etc are IoC containers to name a few. IoC containers support eager instantiation, which is quite useful if you want self-starting services that “come up” on their own when the server starts. They also support lazy loading, which is useful when you have many services which may only be sparsely used.