Clouds
Home

Test Driven Development

Aspect Oriented Programming

Annotation Based Programming

Inversion Of Control - Part 1

Inversion Of Control - Part 2

Hibernate Interview Questions - Part 1

Hibernate Interview Questions - Part 2

Hibernate Interview Questions - Part 3

Spring Interview Questions

EJB 3.0 Interview Questions

Inversion Of Control Interview Questions - Part 1


What is inversion of control (IoC) (also known more specifically as dependency injection) ?

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, Hivemind 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. Most of us are familiar with the software development context where client code (requesting 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. The above approach will tightly couple the dependent components with the client code. Caller code:

class CarBO {
public void getCars(String color) {
//if you need to use a different implementation class say FastCarDAOImpl then need to
//make a change to the caller here (i.e. CarDAO dao = new FastCarDAOImpl()). so the
//caller is tightly coupled. If this line is called by 10 different callers then you
//need to make changes in 10 places.
CarDAO dao = new CarDAOImpl();
List listCars = dao.findCarsByColor(color);
}
}


Being called code:

interface CarDAO (){
public abstract List findCarsByColor(color);
}

interface CarDAOImpl extends CarDAO (){
public List findCarsByColor(color) {
//data access logic goes here
}
}


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 CarDAOFactory {
private static final CarDAOFactory onlyInstance = new CarDAOFactory();
private CarDAOFactory(){}//private so that cannot be instantiated from outside the class
public CarDAOFactory getInstance(){
return onlyInstance;
}
public CarDAO getDAO(){
//if the implementation changes to FastCarDAOImpl then change here only instead of 10
//different places.
return new CarDAOImpl();
}
}


Now the caller code should be changed to:

class CarBO {
public void getCars(String color) {
//if you need to use a different implementation class say FastCarDAOImpl then need to
//make one change only to the factory class CarDAOFactory to return a different
//implementation (i.e. FastCarDAOImpl) rather than having to change all the callers.
CarDAO dao = CarDAOFactory.getInstance().getDAO();
List listCars = dao.findCarsByColor(color);
}
}


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.

SpringConfig.xml

<beans>
<bean id="car" class="CarBO" singleton="false" >
<constructor-arg>
<ref bean="carDao" />
</constructor-arg>
</bean>
<bean id="carDao" class="CarDAOImpl" singleton="false" />
</beans>


Now your CarBO code changes to:

class CarBO {
private CarDAO dao = null;
public CarBO(CarDAO dao) {
this.dao = dao;
}
public void getCars(String color) {
//if you need to use a different implementation class say FastCarDAOImpl then need to
//make one change only to the SpringConfig.xml file to use a different implementation
//class(i.e. class="FastCarDAOImpl") rather than having to change all the callers.
List listCars = dao.findCarsByColor(color);
}
}


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

ApplicationContext ctx = new FileSystemXmlApplicationContext("SpringConfig.xml");
//lookup "car" in your caller where "carDao" is dependency injected using the constructor.
CarBO bo = (CarBO)ctx.getBean("car"); //Spring creates an instance of the CarBO object with
//an instance of CarDAO object as the constructor arg.
String color = red;
bo.getCars(color)


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.

Inversion Of Control Interview Questions - Part 2>>>




Home Clouds