Spring---about IOC

Concept

The IOC (inversion of control inversion) is the core of spring, which runs through all the Times. The so-called IOC, for the spring framework, is the responsibility of spring to control the object's life cycle and the relationship between objects.

Comparison between the traditional development model and the IOC development model

Traditional development patterns: objects depend on each other. In an object, if you want to use a different object, you have to get it, you have to new one, after use, we also have to destroy objects, such as the database connection. Objects are always coupled to other interfaces or classes.

IOC Development mode: The IOC container arranges dependencies between objects. All classes are registered in the Spring container, tell spring what you are, what you need, and spring will give you what you want when the system runs to the right time, and also give you what you need, The creation and destruction of all classes is controlled by spring, which means that the object that controls the lifetime of the object is no longer a reference to it, but spring. For an object in particular, it was previously controlled by other objects, and now all objects are controlled by spring, so this is called control inversion.

The theoretical background of the IOC

Figure One: Coupled objects

One is a graph that references each other among the objects in our traditional system. As we all know, in the software system with object-oriented method design, its bottom-up implementation is composed of N objects, all the objects through the cooperation of each other, finally realize the business logic of the system. If we open the rear cover of the mechanical watch, we will see a similar situation, with each gear driving the hour, minute and second hand clockwise, thus creating the correct time on the dial. A gear set, described in Figure 1, has multiple independent gears that mesh together to work together to accomplish a task. We can see that in such a gear group, if there is a problem with a gear, it may affect the normal operation of the entire gear set. The meshing relationship between gears in a gear group is very similar to the coupling relationship between the objects in the software system. The coupling between objects is unavoidable and necessary, which is the basis of collaborative work. Now, with the increasing scale of industrial applications and the increasingly complex dependencies between objects, there are often multiple dependencies between objects, so architects and designers will face greater challenges in analyzing and designing systems. It is inevitable that the reaching will occur when the coupling between the objects has passed the high system.

How to reduce the coupling between system, module and object is one of the goals that software engineering always pursues. In order to solve the problem of high coupling between objects, software expert Michael Mattson proposed IOC theory to achieve "decoupling" between objects, which has been successfully applied to practice, and many of the EE projects have adopted IOC framework products.

Figure II: The decoupling process

The second is to use the IOC principle to decouple the relationship between the objects. In simple terms, the complex systems are decomposed into objects of mutual cooperation, and after encapsulation, the internal implementation is transparent to the outside, which reduces the complexity of solving the problem and can be reused and extended flexibly. The idea presented by IOC theory is broadly true: the decoupling of objects with dependencies is achieved by means of "third parties".

You see, because the introduction of the middle position of the "third party", that is, the IOC container, so that a, B, C, D these 4 objects do not have a coupling relationship, the transmission between the gears all rely on "third party", all the control of the object to the "third party" IOC container, so, The IOC container is a key core of the entire system, and it acts like an "adhesive" that binds all objects in the system together, and without the "binder", the object and the object will lose touch with each other, and that is the origin of the IOC container being likened to the "binder".

Let's do another experiment: take the intermediate IOC container off and then look at the system. such as three

Figure three: the ideal system

The picture we are looking at now is all that we need to accomplish for the entire system. At this time, a, B, C, D, there is no coupling between the 4 objects, there is no connection, so that when you implement a, there is no need to consider the B, C and D, the dependency between the objects has been reduced to a minimum. So, if you can really implement the IOC container, for system development, this will be a wonderful thing, participate in the development of each member as long as the implementation of their own classes can be, and other people do not have any relationship!
Let's take a look at why the inversion of Control (IOC) is a name? Let's compare:
Before the introduction of the IOC container, the software system 1 shows that object a relies on object B, so when object a initializes or runs to a certain point, it must take the initiative to create object B or Use object B that has already been created. Whether you are creating or using object B, you have control over your own hands.
After the introduction of the IOC container, the software system completely changed, 2, as the IOC container joins, object A and object B lose direct contact, so when object a runs to object B, the IOC container will actively create an object B to inject to object a where it is needed.
Through the contrast, we do not look ugly: object A to rely on the process of object B, from the active behavior to passive behavior, control reversed, this is the name of "control reversal" the origin.

Dependency Injection (DI)

In 2004, Martin Fowler explored the same issue, since the IOC was a reversal of control, so "what controls are reversed?" After detailed analysis and argument, he came to the answer: "The process of acquiring dependent objects has been reversed." After control is reversed, the process of acquiring a dependent object is managed by itself into an active injection by the IOC container. So he gave the "inversion of control" a more appropriate name called "Dependency Injection (Dependency injection)". His answer, in effect, gives a way to implement the IOC: inject. The so-called dependency injection is that the IOC container dynamically injects some kind of dependency into the object during operation.

Therefore, Dependency injection (DI) and inversion of control (IOC) are the same thing that is described from different angles, that is, by introducing an IOC container, the decoupling of objects is realized by means of dependency injection .
Let's give an example of life to help understand the process of dependency injection. Everyone on the USB interface and USB devices should be familiar with it, USB for our use of computers to provide a great convenience, and now have a lot of external devices are supported USB interface.

Figure Four: USB ports and USB devices

Now, we use a computer host and USB interface to accomplish a task: to read a file from an external USB device.
When the host computer reads the file, it does not care about what external device is connected to the USB interface, and it does not need to know. Its task is to read the USB interface, the attached external device as long as the USB interface standard can be met. So, if I connect a USB flash drive to the host computer, then the host will read the file from the USB stick, and if I connect the computer host to an external hard drive, the host computer will read the file from the external hard drive. The power to hook up external devices by my master, that is, the control of my own, as for the USB interface is connected to what device, computer host is not determined, it can only passively accept. When a computer host needs an external device, it doesn't have to tell me, and I'll take the initiative to help it hang on to the external device it wants. This is a common example of dependency injection in our lives. In this process, I played the role of the IOC container.
By this example, the idea of dependency injection is very clear: when the computer host reads the file, I will attach it to the external device that it relies on to help him hook up. The whole process of external device injection and the process of a dependent object being injected inside another object while the system is running is exactly the same.
We apply the dependency injection to the software system and then describe the process:
Object A relies on object B, and when object a needs to use object B, the IOC container immediately creates an object B for the object A. The IOC container is an object manufacturing plant, what you need, it will be sent to you, you directly use it, and no longer have to care about how you use the things are made, do not care how the final is destroyed, all of these are arranged by the IOC container.
In a traditional implementation, the internal code of the program controls the relationship between components. We often use the New keyword to implement a combination of relationships between two components, which can cause coupling between components. The IOC solves this problem well, and it will implement inter-component relationships by referring to external containers from within the program, meaning that a container dynamically injects a dependency between components into the component at run time.

IOC What benefits we have brought to us

The IOC does not have a strong intrusion into business objects during the programming process, and after using IOC, recall has a better implementation of new, reusable, and extensible.

Let's start with the USB example, what's the benefit of using a USB external device over the internal drive?
1, reduce the coupling between components

USB device as a computer host external device, before inserting the host, and the computer host does not have any relationship, only after we are connected together, the two are linked, have relevance. Therefore, no matter what happens on either side, it will not affect the operation of the other party. This characteristic is embodied in software engineering, which is maintainability, which is very convenient for unit testing, easy to debug programs and diagnose faults. Each class in the code can be tested individually, without affecting each other, as long as the function is correct, which is the benefit of low coupling or no coupling between components.

2, improve the development efficiency and product quality

The independence between USB device and computer host, but also brings another benefit, the manufacturer of the USB device and the manufacturer of the computer host can be completely unrelated to each other, the only thing they need to abide by is the USB interface standard. This feature is reflected in the software development process, the benefits are too big. The members of each development team only need to be concerned with the business logic of their own, without having to care about other people's progress, because your tasks are not related to others, your tasks can be tested individually, your tasks are not dependent on other people's components, and you don't have to be confused about responsibilities. Therefore, in a large and medium-sized project, the team members clear division of labor, responsibility is clear, it is easy to divide a large task into small tasks, development efficiency and product quality will be greatly improved.

3, unified standards, improve the reuse of modules

The same USB external device can be plugged into any USB-enabled device, can be plugged into a computer host, or can be plugged into a DV machine, USB external devices can be reused. In software engineering, this feature is good reusability, we can use common components of universality, reuse to other parts of the project, or other projects, of course, this is the basic object-oriented features. Clearly, the IOC has not only implemented this principle better, but also improved the reusability of modules. Implementations that conform to the interface standards can be plugged into modules that support this standard.

4, the module has hot-swappable characteristics

As with USB peripherals, modules have hot-swappable features. IOC generates objects in an external way, that is, the object generation is placed in the configuration file to define, so that when we replace a implementation subclass will become very simple, as long as the configuration file is modified, fully with the hot-plug features.
Are these benefits not enough to impress us and allow us to use the IOC framework in our project development process?

IOC summary

IOC control inversion: It is said that the control of creating an object instance is stripped from the code control to the IOC container control, which is actually what you control in the XML file, focusing on the principle

Di Dependency Injection: When an object instance is created, an attribute value or other object instance is injected for the object, focusing on implementing

This article references Yu Mutao: Http://www.cnblogs.com/superjt/p/4311577.html's article

Spring---about IOC