It’s not an Ioc — Inversion of Control. It’s a design idea.
In Java development, Ioc means handing your designed objects over to the container for control, rather than the traditional direct control within your objects.
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 positive reversal), and which aspects of the reversal. Let’s analyze it in depth:
1. Who controls whom and what
In traditional Java SE programming, we create objects directly inside the object through new, and the program actively creates dependent objects. IoC, on the other hand, has a special container to create these objects, that is, the IoC container controls the creation of objects.
Who controls whom? The IoC container, of course, controls the object.
Control what? That is, it mainly controls the acquisition of external resources (not just objects including files, etc.).
2, why is the reversal, which aspects of the reversal
There is inversion and there is forward, the traditional application is by our own active control in the object to directly obtain the dependent object, 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 inversion.
What has been reversed? The retrieval of dependent objects has been reversed.
To illustrate, traditional programming, as shown in Figure 2-1, takes the initiative to create related objects and then combine them:
When you have an IoC/DI container, you no longer actively create these objects in the client class, as shown in the figure below:
What can the IoC do
IoC is not a technology, just an idea, an important object-oriented programming discipline that can guide us in designing loose-coupled, better programs. 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 given to the container, which injects composite objects. Therefore, objects are loosely coupled between objects, which 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. The application used to be the boss, taking the initiative to acquire whatever resources it wanted, but in IoC/DI thinking, the application became passive, waiting for the IoC container to create and inject the resources it needed.
The IoC embodies one of the laws of object-oriented design — the Hollywood law: “Don’t come to us, we’ll come to you.” That is, the IoC container helps the object to find the corresponding dependent object and inject, rather than the object to find.
The IoC and DI
DI – Dependency Injection: The dependencies between components are determined by the container at runtime. Figuratively, the container dynamically injects a Dependency into the component.
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, why depends on whom, who infuses whom, what infuses”. Let’s take a closer look:
Who depends on whom: Applications depend on the IoC container, of course;
Why dependencies are needed: Applications need IoC containers to provide external resources that objects need;
Who injects whom: It is obvious that the IoC container injects an application object, an object that the application depends on;
What is injected: The external resources (including objects, resources, and constant data) needed to inject an object.
What does IoC have to do with DI?
In fact, they are different descriptions of the same concept. Since the concept of inversion of control is rather vague (perhaps only understood as the level of the container controlling objects, it is difficult to think of who maintains the object relationship), Martin Fowler, a master of science, gave a new name in 2004: “Dependency injection”, in contrast to IoC, “dependency injection” explicitly describes how “the injected object depends on the IoC container to configure dependent objects”.
I have read a lot of articles on the understanding of Spring’s Ioc. Many people’s explanations of Ioc and DI are obscure and difficult to understand. Anyway, I have a feeling that I cannot explain and understand them. He explains every word of IoC (Inversion of control) and DI (dependency injection) very clearly, and when he reads it, it feels like a revelation.
I believe it will be of great help to those who are new to the Spring framework to understand Ioc.
Text source network, only for the use of learning, copyright belongs to the original author, if there is infringement, please contact delete.
I’ve compiled the interview questions and answers in PDF files, as well as a set of learning materials covering, but not limited to, the Java Virtual Machine, the Spring framework, Java threads, data structures, design patterns and more.
Follow the public account “Java Circle” for information, as well as quality articles delivered daily.
