preface

Experience in the learning process, with the help of others Original text: blog.csdn.net/wanghao7221…

background

Object-oriented method design software system. Its underlying implementation is composed of N objects, all objects through mutual cooperation, the final implementation of the system’s business logic.

If we opened the back cover of a mechanical watch, we would see something similar, with the gears turning the hour, minute and second hands clockwise to produce the correct time on the dial. The picture above depicts a group of independent gears that mesh together and work together to accomplish a task. We can see that in such a gear set, if one gear goes wrong, it may affect the normal operation of the whole gear set.

The nie relation between gears in a gear set is very similar to the coupling relation between objects in a software system. Coupling between objects is inevitable and necessary, which is the foundation of collaborative work. Nowadays, with the increasing scale of industrial applications and the increasingly complex dependencies between objects, there are often multiple dependencies between objects, so the analysis and design of systems by architects and designers will face greater challenges. The coupling degree between objects is too high in the system, will inevitably appear to affect the whole situation.

Coupling relationships occur not only between objects, but also between modules of software systems, and between software systems and hardware systems. How to reduce the coupling degree between systems, modules and objects is always one of the goals of software engineering. In order to solve the problem of high coupling degree between objects, software expert Michael Mattson proposed IOC theory, which is used to achieve the “decoupling” between objects. At present, this theory has been successfully applied in practice, many J2EE projects have adopted the IOC framework product Spring.

concept

It’s an IOC Inversion of Control.

Inversion of control, not a technology, but a design idea

The concept of IOC was first introduced in 1996 by Michael Mattson in an article exploring object-oriented frameworks. For the basic idea of object-oriented design and programming, we have talked a lot, in front of the needless, is simply the complex system is decomposed into mutual cooperation object, the object class by encapsulating, internal implementation external is transparent, thus reducing the complexity of problem solving, flexible and can be reused and expanded. IOC theory puts forward a general idea like this: to achieve decoupling between dependent objects with the help of a “third party”

In Java development, Ioc means handing your designed objects over to the container for control, rather than the traditional direct control within your objects. 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 have an in-depth analysis:

  • Who controls whom and what: Communist traditionJava SEProgramming, we go directly inside the objectnewTo create objects, the program takes the initiative to create dependent objects. whileIocThere is a special container to create these objects, namely byIocContainers to control the creation of images;Who controls whom? The IoC container, of course, controls the objects; Control what? That is, it mainly controls the acquisition of external resources (not just objects including files, etc.).
  • Why is inversion, what is inversion: There is inversion, there is forward, traditional applications are by our own active control in the object to directly 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 object, the object only passively accepts the dependent object, so it is inversion; What has been reversed? The retrieval of dependent objects has been reversed

IOC decoupling process

You see, due to the introduction of the middle position of the “third party”, namely the IOC container, makes A, B, C, D the four objects without coupling, gear transmission between all rely on the “third party”, all turned over control of all objects to “third party” the IOC container, so the IOC container is the key to the core of the whole system, It acts as a kind of “glue” that binds all the objects in the system together. Without this “glue”, objects lose contact with each other, which is why some people refer to the IOC container as the “glue”.

Let’s do another experiment: remove the IOC container in the middle of the image above and look at the system again:

After removing the IOC container, the picture we now see is all we need to accomplish to implement the entire system. At this point, objects A, B, C, AND D are no longer coupled to each other, so that when you implement A, you do not need to consider B, C, and D at all, and the dependency between objects has been reduced to the lowest degree. So what a wonderful thing it would be for system development if an IOC container could be implemented, and everyone involved could just implement their own classes, no relation to anyone else!

Why is inversion of control (IOC) so called? Let’s compare: before the software system introduced IOC container, as shown in Figure 1, object A depends on object B, so when object A is initialized or runs to A certain point, it must take the initiative to create object B or use the already created object B. Whether you create or use object B, you have control. This situation changed completely after the software system introduced IOC container. As shown in Figure 3, due to the addition of IOC container, object A and object B lose direct contact. Therefore, when object A runs to the point where object B is needed, IOC container will actively create an object B and inject it into the place where object A needs it. The process by which object A acquires dependent object B is changed from active to passive, and control is reversed, hence the name “inversion of control”.

Process comparison

What does IOC do and what can it 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 from the code, but from the idea of the “master and slave” change. 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 advantages

Flexibility – it is simple to change the implementation class of a widely used interface – changing the retrieval strategy is simpler for a given class (such as moving a service from the classpath JNDI tree) – it is simple to price interceptors in one place (such as adding an interceptor with a JDBC-based caching DAO)

Readability – These projects have a unified component model rather than a fragmented one. – Simpler code.

Testability – Dependencies are easily replaced when they pass through constructors. – Better maintainability and easier unit testing – more testing leads to better code quality

The IOC shortcomings

  1. The introduction of a third-party IOC container in the software system made the process of generating objects a little more complicated. It was an in-between affair, but an extra procedure was created out of thin air, so when we first started using the IOC framework, the system became less intuitive. Therefore, the introduction of a new framework will increase the training cost of team members’ learning and understanding, and in the future operation and maintenance, new entrants must have the same knowledge system.
  2. Since the IOC container generates objects through reflection, there is a certain loss in operating efficiency. If you’re going for operational efficiency, you have to make trade-offs.
  3. In particular, IOC framework products (such as Spring) require a lot of preparation work, which is quite tedious. For some small projects, it may also increase some work costs objectively.
  4. The maturity of the IOC framework product itself needs to be assessed. If an immature IOC framework product is introduced, it will affect the whole project, so this is also a hidden risk.

We can generally conclude that some projects or products with a small workload are not suitable for using IOC framework products. In addition, if the team members lack knowledge and ability, lack of in-depth understanding of IOC framework products, do not rush into the introduction. Finally, projects or products with a strong emphasis on operational efficiency are not suitable for the introduction of IOC framework products, as is the case with WEB2.0 sites.

IOC container products

IOC containers under Sun ONE technology system include:

Lightweight: Spring, Guice, Pico Container, Avalon, HiveMind;

Heavyweight: EJB

Not light, not heavy: JBoss, Jdon,….

As one of SSH(Struts, Spring, Hibernate) three swordsmen in Java development, Spring framework is used in large and small projects, very mature, widely used. Ejbs are also used in critical industrial-level projects, such as certain telecommunications services.

IOC containers under.net technology system include Spring.Net and Castle

Spring.Net is an IOC container ported from Java’s Spring; Castle’s IOC container is the Windsor part. They are both lightweight and mature frameworks, and Spring.Net has been used in a wide variety of projects.