Control reversal (IoC) and Dependency injection (DI)

1. Control reversal (inversion of controls) and dependency injection (Dependency injection)

Control inversion, the IOC (inversion of controls), gives the container the invocation of objects traditionally manipulated directly by program code, and implements assembly and management of object components through containers. The so-called "inversion of control" concept is the transfer of control over component objects, from the program code itself to the external container.

The IOC is a very large concept that can be implemented in different ways. There are two main implementations of:<1> dependency lookup (Dependency Lookup): The container provides the callback interface and the context environment to the component. Both EJB and Apache Avalon Use this approach. <2> Dependency Injection (Dependency injection): Components do not make positional queries, only provide common Java methods to allow containers to determine dependencies. The latter is the most popular type of IOC, with interface injection (Interface injection), set value injection (Setter injection) and construction sub Injection (constructor injection) three ways.

Figure 1 Control reversal conceptual structure

Dependency injection is more prevalent because it is a preferable way to allow a container to be solely responsible for dependent queries, and the managed component simply exposes the JavaBean setter method or the constructor or interface with parameters, allowing the container to assemble the object's dependencies at initialization time. The main advantage is that the:<1> lookup location operation is completely unrelated to the application code, compared with the dependent lookup method. <2> does not rely on the container's API to easily use application objects outside of any container. <3> does not require a special interface, and most objects do not have to rely on the container at all.

2. The Hollywood principle

The IOC embodies the Hollywood principle that "don't call, we'll call you". The first time you encounter the Hollywood rule is when you understand the template method (Template Mathod) pattern, the core of the template method pattern is that the base class (the abstract Class) defines the skeleton of the algorithm and delays some steps into the subclass.

Figure 2 Template method pattern class diagram

Now consider the IOC implementation mechanism, where the components define the entire process framework, and some of these business logic implementations need to be joined by other business objects that can participate in the business process in two ways, a dependency lookup (Dependency Lookup), similar to the JDNI implementation, Using Jndi to find the appropriate business object (code 1), the other is dependency injection, which injects the business object into the component through the IOC container.

3. Dependency lookup (Dependency lookup)

The following code shows the dependency lookup mechanism based on the JNDI implementation.

public class MyBusniessObject{
　 private DataSource ds;
　 private MyCollaborator myCollaborator;
　 public MyBusnissObject(){
Context ctx = null;
try{
　　 ctx = new InitialContext();
　　 ds = (DataSource) ctx.lookup(“java:comp/env/dataSourceName”);
　　 myCollaborator =
(MyCollaborator) ctx.lookup(“java:comp/env/myCollaboratorName”);
　　 }……

Code 1 Dependency lookup (Dependency lookup) code implementation

The main problem with dependency lookup is that this code must depend on the JNDI environment, so it cannot run outside the application server, and if you want to find resources and collaboration objects in a different way instead of Jndi, you must extract the Jndi code to refactor into a policy method.