IoC Container
The basic concept of the Inversion of Control pattern (other name, dependency injection) is that programmers don’t need to create objects but describe how they should be created. Don’t directly connect to the components and services together in code but describe which services are needed by a component in a configuration file. A container (in the case of the Spring framework, the IOC container) is responsible for all this. In IOC scenario, the container creates all the objects, connects them together by setting the necessary properties, and determines when the methods can be invoked. The implementation pattern types (dependency styles) for IOC used by Spring Framework are as follows.
- Dependencies can be assigned through JavaBeans properties with setter methods.
- Dependencies are provided as constructor parameters.
Spring philosophy is avoiding tight coupling between classes and to develop Java applications in a much simpler way (forget the annoyance of EJB complexity).
IoC (Inversion of Control)
IoC is not a new concept and exists for many years. Using object-oriented design principles and features such as interface, inheritance, and polymorphism, the IoC pattern enables better software design that facilitates reuse, loose coupling, and easy testing of software components.
Spring is developed mainly on the concept of Inversion of Control. In inversion control pattern (also familiar as dependency injection) you never create Java objects but you describe them how they should be created (or to say, how you like them created with all the data for your requirement). Which components are to be connected (or which component should be wired to another) and the services required are described in a XML file (you can call it as a configuration file). The Spring container (or to say, IOC container) is responsible to hook up all required for your job at runtime. For a practical program on IoC to understand better and easily, refer the Developing a Simple Spring Application.
Assume Class A has a relationship with Class B. It would like to use the services of Class B. The general way to put this (has-a) relationship is to instantiate Class B in Class A. Though it is alright, it establishes a ftight coupling in between the classes. It is not easily possible to change Class B without changing Class A.
To eliminate this tight coupling, you need to have a Configurator to inject the instance of Class B (Object "b") to the instance of Class A (Object "a"). If you would like to change the implementation of Class B in later stages, just simply modifiy the Configurator object. The control of getting the reference of object "b" in object "a" is inverted. Object "a" is not bothered for obtaining the reference of Object "b". It is the Configurator responsible for it. This is the basis for the IoC design pattern. Inversion of Control is all about inverting the control or how one object gets other object.
To illustrate the benefits of Configurator object, the following examples show a simple usage with and without IoC.
Note: Have some patience to go through as it is very much required to understand what IoC is.
Listing 1 and Figure 1 are simple examples in which Class A uses Class B:
public class A
{
private B b;
public A()
{
b = new B();
}
}
Listing 1 assumes the following design decisions.
- Class A needs a reference of Class B.
- Class B is a concrete class that has a default constructor.
- Class A has an instance of class B (known as has-a relationship).
- No other class can access the instance of Class B.
Any of the above design decisions change, the code in Listing 1 must be altered. For example, if Class B is changed to have a non-default constructor, which takes Class C (see Figure 2), then Listing 1 would change to Listing 2.
public class A
{
private B b;
public A()
{
C c = new C();
B = new B(c);
}
}
Once again, Listing 2 assumes certain design decisions. Now Object "a" owns both Object "b" and Object "c". If Class B or Class C changes, then Class A needs to change as well. Finally to say, a modest design of a very simple class with some built-in design notions becomes a terrible maintenance in the days to come; just feel it.
Other way, a framework built on IoC design pattern is used, the menace of creating Object "b" shifts from Object "a" to IoC framework and is responsible to create and place Object "b" into Object "a". IoC shields Class A from the changes made in Class B. Before an object of "a" is needed, the IoC pumps the reference of Object "b" into Object "a".
Listing 3 illustrates earlier Class A modified with IoC design pattern.
public class A
{
private B b;
public A()
{
}
public setB(B b)
{
this.b = b;
}
}
Listing 3 takes the responsibility of the following policy ideas.
- A needs a reference to B and is not aware of how B is created and injected.
- B can be any Java class like a concrete class or an abstract class or an interface.
- Just before the object of Class A is needed, it requires a reference to the object of Class B.
From the above design ideas, you can notice that there is no tight coupling between classes A and B. Both can be changed independently without affecting the other. One point is if class B changes its methods, class A also requires to change. Object "b" creation and injection need not be known at implementation stage of object A. Here comes IoC framework. IoC make use of setB() to pump object "b" into object "a" (see figure 3).
Object dependencies uses and takes advantage of Dependency Injection (DI). DI is neat, stretchable and simple for maintenance which is very much required in large projects. Now-a-days, Spring has becomes a standard framework to use with Enterprise Applications (EA) which reduces the EA coding complexity by offering loose coupling. Module testing becomes easier with loose coupling.
More on IoC exists in the first program Developing a Simple Spring Application.
