"The Path to SSH" Spring's IOC-level deep--spring IOC principle [Popular explanation] (c)

1. Background of the IOC theory
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.

Figure 1: Coupling objects in a software 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.

Figure 2: Complex dependencies between objects

The coupling relationship not only occurs between the object and the object, but also between the modules of the software system and between the software system and the hardware 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 Java EE projects use the IOC framework product spring.

2. What is control reversal (IoC)
IOC is the abbreviation for inversion of control, most books translated into "Inversion of controls", and some books translated into "control reverse" or "control inversion".
In 1996, Michael Mattson, in an article on the object-oriented framework, first proposed the concept of IOC. For object-oriented design and programming of the basic idea, we have already talked a lot, not to repeat, the simple is to break down the complex system into mutual cooperation objects, these object classes through encapsulation, the internal implementation of the external is transparent, thereby reducing the complexity of solving the problem, and can be reused and expanded flexibly. The idea of IOC theory is broadly like this: With the help of a "third party" to achieve decoupling between objects that have dependencies, the following figure:

Figure 3:IOC Decoupling process

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 out the IOC container in the middle of the image, and then look at the system:

Figure 4: System after taking out the IOC container

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 an IOC container, it would be a wonderful thing for system development, and every member involved in the development would be able to implement their own classes and have nothing to do with anyone else.
Let's take a look at why the inversion of Control (IOC) is so named. Let's compare:
Software system before the IOC container is introduced, as shown in Figure 1, object A relies on object B, then object A, when initializing or running to a point, must take the initiative to create object B or use the 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 is completely changed, as shown in Figure 3, because 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.

3. Aliases for IOC: 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 5:usb Interface and USB device

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 the computer host needs external equipment, it does not need to tell me, I will actively help it hang on the external device it wants, you see how 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.
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.

4. What benefits does the IOC bring to US

We still start with the USB example, the use of USB external devices than the use of internal hard disk, in the end what benefits.
First, the USB device as the 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 the software engineering, is the maintainability is good, is very convenient to carry on the unit test, facilitates the debugging procedure and diagnoses the fault. 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.
Second, the independent of the USB device and the computer host, but also brings another benefit, the manufacturer of the production of USB equipment and the manufacturer of 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.
Third, the same USB external device can be plugged into any USB-enabled device, can be plugged into the computer host, you can also plug into the 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.
Iv. 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.
The above benefits are not enough to impress us, let us use the IOC framework in the project development process.

5. Technical Analysis of IOC containers
The most basic technology in the IOC is "reflection (Reflection)" programming, currently supported by languages such as. Net C #, Java, and PHP5, where PHP5 's technical books are sometimes translated into "maps." As for the concept and usage of reflection, it should be clear that, in layman's terms, the object is dynamically generated based on the given class name (string mode). This way of programming allows an object to determine exactly which object it is when it is built. The application of reflection is very extensive, many mature frameworks, such as Hibernate in Java, Spring Framework. NET in the NHibernate, spring.net framework is the "reflection" as the most basic technical means.
Reflection technology actually appeared very early, but it has been neglected and has not been further exploited. At the time, the reflection programming method was at least 10 times times slower than normal object generation. Now the reflection technology has been improved and optimized, has been very mature, the reflection of the generation of objects and common object generation method, the speed is not large, about 1-2 times the gap.
We can think of the IOC container's working mode as a distillation of the factory pattern, and we can think of the IOC container as a factory where the objects to be produced are defined in the configuration file, and then use the programming language's reflection programming to generate the corresponding object based on the class name given in the configuration file. In terms of implementation, the IOC generates code for objects that were previously written dead in the factory method, and is changed to be defined by the configuration file, which separates the factory from the object generation, which is designed to improve flexibility and maintainability.
6. Some products of the IOC container
The IOC containers in the Sun One technology system are: Lightweight with spring, Guice, Pico Container, Avalon, hivemind, heavy-weight ejb, Jboss,jdon and so on. Spring Framework as one of the Three Musketeers in Java development (Struts, Spring, Hibernate), large and medium-sized projects are used, very mature, widely used, EJB is also used in key industrial projects, such as some telecommunications services.
. The IOC containers under the Net technology system are: Spring.net, Castle and so on. Spring.net is an IOC container ported from the Java Spring, and the Castle IOC container is the Windsor part. They are lightweight frameworks that are relatively mature, where spring.net has been gradually applied to various projects.
7. What should be noted in 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 shortcomings of the introduction of the IOC framework, to be aware of, to eliminate the misuse of the framework.
First, the software system due to the introduction of a third-party IOC container, the process of generating objects has become somewhat complex, it is a matter between the two, and a little more than a formality, so, when we first use the IOC framework, we will feel the system becomes less intuitive. Therefore, the introduction of a new framework will increase the training costs of team members to learn and understand, and in the future maintenance of the operation, but also to let the new participants have the same knowledge system.
Second, because the IOC container generates objects through reflection, there is a certain loss in operational efficiency. If you want to pursue operational efficiency, you have to weigh this.
Third, specific to the IOC framework products (such as: Spring), the need for a lot of preparation work, more cumbersome, for some small projects, the objective may also increase some of the cost of work.
Iv. the maturity of the IOC framework product itself needs to be evaluated, and if an immature IOC framework product is introduced, it will affect the entire project, so this is also an implicit risk.
We can generally conclude that some projects or products that do not work very well are not suitable for use with the IOC framework products. In addition, if the team members of the lack of knowledge, the IOC framework products do not have a deep understanding, do not introduce. Finally, special emphasis is placed on the operational efficiency of the project or product, which is also less suitable for the introduction of IOC framework products, as is the case with the WEB2.0 website.

Resources:

http://jiwenke.iteye.com/blog/493965

Reprinted from: Commando, http://blog.csdn.net/m13666368773/article/details/7802126