Talking about features of the framework, In this part I’ll explain the characteristics of the Spring framework called Inversion of Control (IoC), or also called Dependency Injection (DI). This is a key element that needs to be good understanding.
In the “Spring Framework Reference Documentation,” written by Rod Johnson, explained that:
IoC is also known as dependency injection (DI). It is a process whereby objects define their dependencies, that is, the other objects they work with, only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself controlling the instantiation or location of its dependencies by using direct construction of classes, or a mechanism such as the Service Locator pattern.
A Java application is that the application is built from a Java class, or called a bean. Ideally, a bean is free or independent, it is not bound or dependent on other beans. By not depending on a bean to another bean, this principle called loose coupling. Spring framework emphasizes the use of loose coupling. The opposite of loose coupling is tight coupling, here is the different:
class Traveler
{
Car c=new car();
void start journey()
{
c.move();
}
}
class Car
{
void move()
{
//logic...
}
}
It appears that the bean car is referred to as the Traveler explicitly because, there is a variable declaration “Car c = new Car ();“. This is avoided when using Spring Framework. Spring, utilizing the interface. An interface, supports loose coupling because inside the interface there is no business logic.
For example, we create a template first
interface vehicle
{
void move();
}
The new business logic, is created on the class that implements the interface. In this example, two classes, car and bike, which implement the same interface, are assumed to have different business logic.
class Car implements Vehicle
{
public void move() // business logic for car
}
class bike implements Vehicle
{
public void move() // business logic for bike
}
To remain a loose coupling, the class traveler declares a variable referring to an interface.
class Traveler
{
vehicle v;
public void setV(Vehicle V)
{
this.v = v;
}
void startJourney()
{
v.move();
}
}
In this section, the bean “Traveler” has no direct association with bean “car” or “bike”. Because there is no direct link with any of the bean, the programming way is loose coupling. There are several advantages why a bean labeled of loose coupling properties:
- Changes or deletions of the bean, will not directly affect other program codes or the other(s) bean.
- It will be easier when testing apps. A bean can be replaced with another bean easily and quickly. Simple.
In the previous example, the bean Traveler testing method using bean “car” or “bike”, can use the role of DI (Dependency Injection). Where bean car or bike can be injected to bean Traveler as needed. here’s example:
class Traveler
{
Vehicle v;
public void setV(Vehicle v)
{
this.v = v;
}
}
Injection can be done through the xml configuration file, for example:
<bean id="TheTraveler" class="Traveler"> <property name="v" ref="TheCar" /> </bean> <bean id="TheCar" class="Car"> </bean> <bean id="TheBike" class="Bike"> </bean>
This technique is called Dependency Injection. With DI feature, all beans are loose coupling and injection is done outside of java program flexibly. DI (Dependency Injection) effect is valid at the time when application running (runtime).