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 2


What are the different types of dependency injections ?

There are three types of dependency injections.
  • Constructor Injection (e.g. Pico container, Spring etc): Injection is done through constructors.
  • Setter Injection (e.g. Spring): Injection is done through setter methods.
  • Interface Injection (e.g. Avalon): Injection is done through an interface.
    Spring supports both constructor-based injection and setter-based injection. Here is an example using the Spring’s setter-based injection.

    SpringConfig.xml

    <beans> <bean id="car" class="CarBO" singleton="false" > <property name="dao"> <ref bean="carDao" /> </property> </bean> <bean id="carDao" class="CarDAOImpl" singleton="false" /> </beans>

    Now your CarBO code changes to:

    class CarBO {
    private CarDAO dao = null;
    public CarBO() {}
    ....
    public void setDao(CarDAO carDao){
    this.dao = carDao;
    }

    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);
    }
    }


    The above SpringConfig.xml code creates an instance of CarBO object and CarDAO object and calls the setDao(CarDAO carDao) method, passing in the reference to the CarDAO object. Your caller code would be (e.g. from a Web client or EJB client ) same as above:

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


    Which one to use ?

    The choice between constructor-based injection and setter-based injection goes back to OO programming question Should you fill fields in a constructor or setter methods?. There is no clear cut answer for this question. It is a good practice to start with constructor-based injection since it permits immutability (i.e. if your classes are meant to be immutable) and also constructors with parameters give you a clear statement of what is required to create a valid object. If there is more than one way to create a valid object then provide multiple constructors. But if you have a lot of constructor parameters then your constructors can look messy and also if you have many string based parameters then setter-based injection will be more descriptive because each setter name will indicate what the string is supposed to do (e.g. setFirstName(""), setLastName("") etc)

    What are the benefits of IoC (aka Dependency Injection) ?

  • Minimizes the amount of code in your application. With IoC containers you do not care about how services are created and how you get references to the ones you need. You can also easily add additional services by adding a new constructor or a setter method with little or no extra configuration.
  • Makes your application more testable by not requiring any singletons or JNDI lookup mechanisms in your unit test cases. IoC containers make unit testing and switching implementations very easy by manually allowing you to inject your own objects into the object under test.
  • Loose coupling is promoted with minimal effort and least intrusive mechanism. The factory design pattern is more intrusive because components or services need to be requested explicitly whereas in IoC the dependency is injected into the requesting code. Also some containers promote the design to interfaces not to implementations design concept by encouraging managed objects to implement a well-defined service interface of your own.
  • IoC containers support eager instantiation and lazy loading of services. Containers also provide support for instantiation of managed objects, cyclical dependencies, life cycle management, and dependency resolution between managed objects etc.

    What is the difference between a service locator pattern and an inversion of control pattern ?

    Service locator
  • The calling class which needs the dependent classes needs to tell the service locator which classes are needed. Also the calling classes have the responsibility of finding these dependent classes and invoking them. This makes the classes tightly coupled with each other.
  • Difficult to unit test the classes separately due to tight coupling.

    Inversion Of Control (IoC)

  • In IoC (aka Dependency Injection) pattern the responsibility is shifted to the IoC containers to locate and load the dependent classes based on the information provided in the descriptor files. Changes can be made to the dependent classes by simply modifying the descriptor files. This approach makes the dependent classes loosely coupled with the calling class.
  • Easy to unit test the classes separately due to loose coupling.

    Why dependency injection is more elegant than a JNDI lookup to decouple client and the service ?

    Here are a few reasons why a JNDI look up is not elegant:
  • The client and the service being looked up must agree on a string based name, which is a contract not enforced by the compiler or any deployment-time checks. You will have to wait until runtime to discover any discrepancies in the string based name between the lookup code and the JNDI registry.
  • The JNDI lookup code is verbose with its own try-catch block, which is repeated across the application.
  • The retrieved service objects are not type checked at compile-time and could result in a casting error at runtime.
  • Dependency injection is more elegant because it promotes loose coupling with minimal effort and is the least intrusive mechanism. Dependency is injected into requesting piece of code by the IoC containers like Spring etc. With IoC containers you do not care about how services are created and how you get references to the ones you need. You can also easily add additional services by adding a new constructor or a setter method with little or extra configuration.

    Hibernate Interview Questions - Part 1 >>>




    Home Clouds