First of all, forget about definitions. Let’s use a vivid example to understand IOC and DI. Inversion of control: We all have USB ports and HDMI ports on our computers. What keyboard you use on your computer doesn’t depend on the computer itself, but what keyboard is plugged into the USB. So, the device that controls what the computer inputs isn’t controlled by the computer, it’s controlled by what keyboard you plug in. Isn’t this control reversed? Dependency injection: A computer’s input device depends on what keyboard it is plugged into. Insert mechanical keyboard, input device is mechanical keyboard; Insert a numeric keypad and the input device is a numeric keypad. From the point of view of the keyboard: nothing more than from the computer’s point of view, is dependency injection, input what device dependency injection keyboard is; From the keyboard point of view it’s inversion of control, the keyboard that’s inserted to control what the computer is as an input device. The purpose of dependency injection is to be flexible. If the keyboard on your computer is soldered to the computer and the keyboard is broken, the computer is broken.

What is the IOC

Ioc – Inversion of Control. In development, IoC means that you have designed objects to be controlled by the container, rather than the traditional way of controlling them directly from within.

How to Understand IOC

How to understand IoC? The key to a good understanding of IoC is to be clear about “who controls whom, what controls, why there is a reversal (there should be a reversal), which aspects of the reversal”. Let’s take a closer look.

  • Who controls who, controls what: in traditional programming, we directly create objects in the object through the new way, is the program actively create dependent objects; IoC has a special container to create these objects, that is, the IoC container controls object creation; Who controls whom? The IoC container, of course, controls the objects; Control what? It is mainly about controlling external resource acquisition.
  • Why it is inverted and what aspects it is inverted: There is inversion and there is forward, traditional applications are by our own active control in the object to obtain dependent objects, that is, forward; In inversion, the container helps create and inject dependent objects. Why reverse? Because the container helps us find and inject the dependent objects, the objects only passively accept the dependent objects, so it is reversed; What has been reversed? The retrieval of dependent objects has been reversed.

What can the IOC do

Ioc is not a technology, just an idea, an important object-oriented programming principle that can guide us in designing loose-coupled, better systems. In traditional applications, we actively create dependent objects within classes, which leads to high coupling between classes and is difficult to test. With the IoC container, the control of creating and finding dependent objects is transferred to the container, which injects composite objects, so the objects are loosely coupled, which also facilitates testing, functional reuse, and more importantly, makes the overall architecture of the program very flexible.

In fact, the biggest change IoC has brought to programming is not in the code, but in the mind. In IoC thinking, an application becomes passive, waiting for the IoC container to create and inject the resources it needs.

The IOC and DI

Di-dependency Injection (DI) : Dependencies between components are determined by the container at runtime. The purpose of dependency injection is not to bring more functions to the software system, but to increase the frequency of component reuse and build a flexible and extensible platform for the system. Through the dependency injection mechanism, we can specify the resources needed by the target and complete our business logic through simple configuration without any code, regardless of where the specific resources come from and who implements them.

The key to understanding DI is: “Who depends on whom and why, who injects whom and what”. Let’s take a closer look: Who depends on whom: Applications depend on IoC containers, of course. Why they need them: Applications need IoC containers to provide external resources that objects need. It’s obvious what the IoC container injection application’s dependent objects inject: the external resources (including objects, resources, constant data) needed to inject an object

What is the relationship between IOC and DI? In fact, they are different descriptions of the same concept, and since the concept of inversion of control is rather vague (perhaps only understood as the level of container control object, it is difficult to think of who maintains the dependency), so in 2004, Martin Fowler gave a new name: “Dependency injection”, as opposed to IoC, “dependency injection” explicitly describes how the injected object depends on the IoC container to configure dependencies.

Generally, Inversion of Control means a transfer of Control over object creation. Previously, the application controlled the initiative and timing of object creation, but now this Control is transferred to the IoC container, which is a factory for object creation. It just gives you something. With the IoC container, the dependencies are changed, the original dependencies are gone, they all depend on the IoC container, through which they are established.