IoC: salient features

1. Eliminates lookup code from within your application.
2. Allows pluggablity and hot swapping.
3. Promotes good OO design.
4. Enables the reuse of existing code.
5. Makes your application extremely testable

In a typical IOC scenario, the container creates all the
objects, wires them together by setting the necessary
properties. It also determines when methods will be
invoked. The three implementation pattern types for IOC
are listed in the table below.

Type 1: Services need to implement a dedicated interface
through which they are provided with an object from which they can look up dependencies (for example, additional needed services).

Type 2: Dependencies are assigned through JavaBeans
properties (for example, setter methods).

Type 3: Dependencies are provided as constructor parameters and are not exposed as JavaBeans properties.

The Spring framework uses the Type 2 and Type 3 implementations for its IOC container. IOC is a broad concept, its two main types are:

1. Dependency Lookup: Type 1 IoC The container provides callbacks to components and a lookup context. The managed objects are responsible for their other lookups. This is the EJB Approach. The Inversion of Control is limited to the Container involved callback methods that the code can use to obtain resources. Here JNDI is needed to look up other EJBs and resources. Because of this reason EJB is not branded as ‘IOC framework’. There are some problems in this implementation. The class needs a application server environment as it is dependent on JNDI and it is hard to test as we need to provide a dummy JNDI contest for testing purpose.

2. Dependency Injection: Type 2 / Type 3 IoC In this application objects are not responsible to looking up resources they depend on. Instead IoC container configures the object externalizing resource lookup from application code into the container. That is, dependencies are injected into objects. Thus lookups are completely removed from application objects and it can be used outside the container also.


Here, the objects can be populated via Setter Injection (Java-Beans properties) or Constructor Injection (constructor arguments). Each method has its own advantage and disadvantage.

Setter Injection: Normally in all the java beans, we use setter and getter method to set and get the value of property as follows

public class nameBean {
String name;
public void setName(String a) {
name = a;
public String getName() {
return name;

We create an instance of the bean ‘nameBean’ (say bean1) and set property as bean1.setName(“amit”); Here in setter injection, we set the property ‘name’ by using the <property> subelement of <bean> tag in spring configuration file as shown below.

<bean id=”bean1" class=”nameBean”>
<property name=”name” >

The subelement <value> sets the ‘name’ property by calling
the set method as setName(“amit”); This process is called
setter injection.

constructor injection : For constructor injection, we use
constructor with parameters as shown below,

public class nameBean {
String name;
public nameBean (String a) {
name = a;

We will set the property ‘name’ while creating an instance of the bean ‘nameBean’ as nameBean bean1 = new
nameBean(“amit”); Here we use the <constructor-arg> element to set the the property by constructor injection as

<bean id=”bean1" class=”nameBean “>
<value>Bean Value</value>

To set properties that reference other beans <ref>, subelement of <property> is used as shown below,

July 2007 | Java Jazz Up |25
Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53 ,            Download PDF