Inversion of Control(IoC) & Dependency Injection

Inversion of Control(IoC)

Here is an informal definition of IoC: “IoC is when you have someone else create objects for you.” So instead of writing “new MyObject” in your code, the object is created by someone else. This ‘someone else’ is normally referred to as an IoC container.

This simple explanation illustrates some very important ideas:

1. It is called IoC because the control of the object is inverted. It is not the programmer, but someone else who controls the object.
2. IoC is relative in the sense that it only applies to some objects of the application. So there may be IoC for some objects, whereas others are under the direct control of the programmer.
3. IoC containers control and manage the lifecycle of some objects: creation, destruction, and callback invocations.
4. The programmer must identify the classes whose instances are to be managed by the IoC container. There are several ways to do this: with annotations, by extending some specific classes, using external configuration.
5. The programmer can influence, to some extent, the way the objects are managed by the IoC container. Normally, this is achieved by overriding the default behavior of the object callbacks.

Dependency Injection

In the Spring framework, the Dependency Injection (DI) design pattern is used to define the object dependencies between each other. There are three possible ways of DI in Spring

1. Constructor-based: Should be used for mandatory dependencies. In the constructor, we should assign constructor args to final member fields.
2. Setter-based: Should be used for optional dependencies.
3. Field-based: Spring discourages the use of this because it would possibly hide mandatory fields from outside which would otherwise be assigned in the constructor. This would take away the advantage of properly initialized POJO, especially if intended to use outside of the Spring container. Even though we are mostly using a field-based injection in this series of tutorials to simplify the concept we want to deliver, we suggest the developers always avoid using field-based DI in real project scenarios.

Setter Injection

Setter-based DI is realized by calling setter methods on your beans after invoking a no-argument constructor or no-argument static factory method to instantiate your bean.

public class TestSetterDI {
  DemoBean demoBean = null;
  public void setDemoBean(DemoBean demoBean) {
    this.demoBean = demoBean;
  }
}

Constructor Injection

Constructor-based DI is realized by invoking a constructor with a number of arguments, each representing a collaborator. Additionally, calling a static factory method with specific arguments to construct the bean, can be considered almost equivalent, and the rest of this text will consider arguments to a constructor and arguments to a static factory method similarly.

public class ConstructorDI {
  DemoBean demoBean = null;
  public TestSetterDI (DemoBean demoBean) {
    this.demoBean = demoBean;
  }
}

Conclusion

Inversion of control (IOC) talks about who is going to initiate the call whereas Dependency Injection (DI) talks about how one object acquires dependency on other objects through abstraction.