IOC framework (converted)

1 Background of IOC Theory
We all know that in a software system designed using an object-oriented method, its underlying implementation is composed of n objects, and all objects are through mutual cooperation, finally, implement the business logic of the system.

 
Figure 1 coupling objects in the Software System

If we open the back cover of the mechanical watch, we will see a similar situation as above. Each Gear will drive the clockwise rotation of the hour, minute and second hands respectively, so as to generate the correct time on the dial. As described in Figure 1, a gear group has multiple independent gears that work together to complete a task. We can see that in such a gear group, if a gear has a problem, it may affect the normal operation of the entire gear group.
The meshing relationship between gears in the gear group is very similar to the coupling relationship between objects in the software system. Coupling between objects is inevitable and necessary, which is the basis of collaborative work. Nowadays, with the increasing scale of industrial applications, the dependencies between objects become more and more complex, and multiple dependencies between objects often appear. Therefore, architects and designers will face greater challenges in system analysis and design. If the coupling between objects is too high, the system will inevitably take a long lead.

 

 

 
Figure 2: complex dependency between objects

Coupling occurs not only between objects, but also between modules of software systems and between software systems and hardware systems. How to Reduce the coupling between systems, modules and objects is always one of the goals of software engineering. To solve the problem of high coupling between objects, software expert Michael Mattson proposed the IOC theory to achieve "decoupling" between objects. At present, this theory has been successfully applied to practice, many J2EE projects adopt the IOC framework product spring.

2. What is IOC) 
IOC is short for inversion of control. Most books translate it into "control inversion", and some others translate it into "control inversion" or "control inversion ".
In 1996, Michael Mattson first proposed the concept of IOC in an article about the object-oriented framework. We have already talked a lot about the basic idea of object-oriented design and programming. Simply put, we will break down complicated systems into mutual cooperation objects, after these object classes are encapsulated, internal implementation is transparent to the outside, which reduces the complexity of solving the problem and can be flexibly reused and expanded. The idea put forward by IOC theory is roughly like this: decoupling between dependent objects with the help of "third parties", such:

 

Figure 3 IOC decoupling process

As you can see, the introduction of the "third party" in the middle, that is, the IOC container, makes the four objects A, B, C, and D have no coupling relationship, the drive between gears depends on the "third party", and the control of all objects is handed over to the "third party" IOC container. Therefore, the IOC container becomes the key core of the entire system, it plays a role similar to "adhesive", and binds all objects in the system together. Without this "adhesive", objects and objects will be lost, this is why some people think of IOC containers as "Adhesives.
Let's try again: remove the IOC container in the middle, and then look at the system:
 

Figure 4: system after IOC container Removal

The picture we see now is all we need to do to implement the entire system. At this time, there is no coupling between the four objects A, B, C, and D, and there is no connection between them. In this case, when you implement, there is no need to consider B, C, and D at all. The dependency between objects has been minimized. Therefore, if the IOC container is implemented, it would be a wonderful thing for system development. Every member involved in the development only needs to implement their own classes, it has nothing to do with others!
Let's take a look at why the IOC name is used? Let's make a comparison:
Before the IOC container is introduced, the software system shows that object a depends on object B, so when object A is initialized or running to a certain point, you must create object B or use the created object B. Whether you create or use object B, you have control.
After the software system introduces the IOC container, this situation has completely changed. 3 shows that, due to the addition of the IOC container, the direct connection between object A and object B is lost. Therefore, when object a runs to object B, the IOC container will create an object B and inject it to the location required by object.
Through the comparison, we can't see it: the process in which object A obtains dependent object B is changed from active behavior to passive behavior, and the control is reversed, this is the origin of the name "control inversion.

 

3. Alias of IOC: dependency injection (DI)
In 2004, Martin Fowler discussed the same issue. Since IOC is a reversal of control, "which aspects of control have been reversed ?", After detailed analysis and demonstration, he got the answer: "the process of obtaining dependent objects is reversed ". After the control is reversed, the process of obtaining dependent objects changes from self-management to active injection by the IOC container. Therefore, he gave "control inversion" a more appropriate name called "dependency injection )". His answer is actually a method for implementing IOC: injection. The so-called dependency injection means that the IOC container dynamically injects a dependency into the object during runtime.

 

Therefore, dependency injection (DI) and control inversion (IOC) are the same thing described from different perspectives, that is, by introducing IOC containers and injecting dependencies, decouples objects.
Let's take an example in our daily life to help us understand the dependency injection process. You should be familiar with USB interfaces and USB devices. USB provides great convenience for us to use computers. Many external devices now support USB interfaces.

 

Figure 6: USB interface and USB device

 

Now, we use the computer host and USB interface to implement a task: reading a file from an external USB device.
When the Computer Host reads files, it does not care about what external devices are connected to the USB interface, and does not need to know. Its task is to read the USB interface. The mounted external device only needs to comply with the USB interface standard. Therefore, if I connect a USB flash drive to a computer host, the Host reads the file from the USB flash drive. If I connect an external hard drive to the computer host, then the Computer Host reads files from an external hard disk. The power of mounting an external device is determined by me, that is, the control is owned by me. As for what devices are mounted to the USB interface, the Computer Host cannot decide, and it can only be passively accepted. When a Computer Host needs an external device, it doesn't need to be told at all, so I will take the initiative to help it hook up the external device it wants, and you can see how well my service is in place. This is a common example of dependency injection in our lives. In this process, I played the role of the IOC container.
In this example, the idea of dependency injection is clear: when the Computer Host reads a file, I will connect the external device on which it depends. The whole process of external device injection is exactly the same as that of injecting a dependent object into another object during system operation.
We inject dependencies into the software system and describe the process again:
Object A depends on object B. When object A needs to use object B, the IOC container will immediately create object B and send it to object. The IOC container is an object manufacturing factory. If you need anything, it will send it to you and you can use it directly, instead of worrying about how your work is made, you don't have to worry about how it is destroyed. All of this is done by the IOC container.
In the traditional implementation, the internal code of the program controls the relationship between components. We often use the new keyword to combine the relations between two components. This implementation will cause coupling between components. IOC solves this problem well. It refers to the external container from within the program to realize the relationship between components, that is, the container dynamically injects a dependency between components into the components at runtime.

 

4 what benefits does IOC bring to us?

Let's talk about the advantages of using a USB external device over a built-in hard disk?
First, the USB device is an external device of the Computer Host. Before it is inserted into the host, it has nothing to do with the computer host. Only after it is connected together can the two be associated. Therefore, no matter what happens to either party, the operation of the other party will not be affected. This kind of feature is embodied in software engineering, that is, it has good maintainability and is very easy to conduct unit tests, so as to facilitate program debugging and fault diagnosis. Each class in the code can be tested independently, and each other does not affect each other. You only need to ensure that your own functions are correct. This is the benefit of low coupling or no coupling between components.
2. The independence between the USB device and the Computer Host brings another benefit. the manufacturer of the USB device and the manufacturer of the Computer Host can be completely irrelevant, the only thing they need to follow is the USB interface standard. This feature is reflected in the software development process, but it is too good. Members of each development team only need to focus on implementing their own business logic, and do not need to care about the progress of other people's work, because your tasks have nothing to do with others, your tasks can be tested independently, and your tasks do not depend on others' components, so you no longer need to clarify responsibility. Therefore, in a large and medium-sized project, the division of labor and responsibilities of team members are clear. It is easy to divide a large task into small tasks, and the development efficiency and product quality will be greatly improved.
Third, the same USB external device can be plugged in to any device that supports USB, can be plugged into the computer host, or can be plugged into the dvserver, the USB external device can be reused. In software engineering, this feature is highly reusable. We can separate common components and reuse them to other parts of the project or other projects, of course, this is also the basic feature of object-oriented. Obviously, IOC not only better implements this principle, but also improves the reusability of modules. All implementations that comply with the interface standards can be inserted into modules that support this standard.
Fourth, like USB external devices, the module has the hot swapping feature. The IOC generation object method is converted to the external method, that is, the object generation is defined in the configuration file, so that when we replace an implementation subclass, it will become very simple, you only need to modify the configuration file, which has the Hot Plug-In feature.
Aren't the above advantages enough to impress us. Can we use the IOC framework in the project development process?

5 IOC container Technical Analysis
The most basic technology in IOC is reflection programming. net C #, Java, PhP5, and other languages are supported. Among them, PhP5 technical books are sometimes translated as "ing ". We should be very clear about the concepts and usage of reflection. In general, it is to dynamically generate Objects Based on the given class name (string method. This programming method allows an object to decide which object is generated. Reflection is widely used. There are many mature frameworks, such as Hibernate and spring frameworks in Java ,.. net. the net framework uses "reflection" as the most basic technical means.
Reflection technology has appeared for a long time, but it has been ignored and is not used further. At that time, the reflection programming method was at least 10 times slower than the normal object generation method. The current reflection technology has been improved and optimized, and is very mature. The velocity of generating objects using reflection methods is not much different from that of generating objects using common object methods, which is about 1-2 times the speed.
We can regard the IOC container working mode as the sublimation of the factory mode, and the IOC container as a factory. All the objects to be produced in this factory are defined in the configuration file, then, the reflection programming in the programming language is used to generate the corresponding object based on the class name given in the configuration file. From the perspective of implementation, IOC is to generate code for the previously written objects in the factory method, which is defined by the configuration file, that is, to separate the factory and object generation, the purpose is to improve flexibility and maintainability.
6. Some IOC container Products
IOC containers under the sun one technical system include: lightweight spring, guice, Pico container, aveon, hivemind; heavyweight: EJB; lightweight: JBoss, jdon, and so on. Spring framework is one of the three muskeys in SSH (struts, spring, and hibernate) in Java Development. It is widely used in large, medium, and small projects. It is also used in key industrial projects, for example, some telecom services.
IOC containers under the. NET technical system include spring. NET and Castle. Spring. NET is an IOC container transplanted from spring in Java, and Castle's IOC container is part of the Windsor. They are both lightweight frameworks and mature, among which spring. net has been gradually applied to various projects.
7 What should I pay attention to when using the IOC framework?
The use of IOC framework products can bring great benefits to our development process, but we also need to fully understand the disadvantages of introducing the IOC framework, so that we can be aware of it and eliminate the abuse of the framework.
First, because the third-party IOC container is introduced in the software system, the process of generating objects becomes a little complicated. It was originally a task between the two, and there was another procedure out of thin air. Therefore, when we first started using the IOC framework, we felt that the system was not very intuitive. Therefore, the introduction of a new framework will increase the training cost for team members to learn and understand. In the future operation and maintenance, new entrants must have the same knowledge system.
Second, because the IOC container generates objects through reflection, there is a certain loss in the running efficiency. If you want to pursue operational efficiency, you must weigh it.
Third, for IOC framework products (such as spring), a large amount of preparation work is required, which is complicated. For some small projects, it may also increase work costs objectively.
Fourth, the maturity of the IOC framework product itself needs to be evaluated. If an immature IOC framework product is introduced, it will affect the entire project, so this is also a hidden risk.
We can conclude that some projects or products with a low workload are not suitable for IOC framework products. In addition, if the team members lack the knowledge and ability, do not rashly introduce IOC framework products. Finally, projects or products with special emphasis on operational efficiency are not suitable for introducing IOC framework products, such as Web websites.