To understand inversion of control (Inversion of Control), I feel the need to understand the important idea of software design: Dependency Inversion Principle (Dependency Inversion Principle) .
One: What is the Dependency Inversion Principle?
Suppose we design a car: first design wheels, wheel size and design according to the chassis, and then based on the chassis design of the body, according to last the entire vehicle body design is good. Here there is a "dependent" relationship: car-dependent body, the body relies chassis, chassis dependent on wheels.
This design looks good, but the maintainability is very low. After the completion of the design assumptions, the boss suddenly said that according to changes in market demand, we have to put the car wheel designs have changed freshman code. This time we egg pain: Because we are dimensioned according to the wheel chassis, wheels to change the size of a chassis design must be modified; likewise the body because it is based on the design of the chassis, the body can change too, similarly automotive design have to change - almost the entire design had to change! We now put it another thought. Let's design probably looks of the car, then the body is designed according to the car's appearance, according to the vehicle chassis design, chassis design based on the last wheel. At this time, the dependency on upside down: the wheels rely chassis, chassis dependent on the body, the body relies car.
At this time, say the boss to change the wheel design, we only need to change the wheel design, without moving the chassis, body, car design. This is the Dependency Inversion Principle - the original high-rise buildings rely on the underlying architecture "upside down" over and become dependent on the underlying building high-rise buildings. High-rise buildings need to decide what the underlying demand to achieve this, but not with high-level cap layer is how to achieve. This situation "pull launched a whole" does not appear in front.
II: Inversion of Control (Inversion of Control)
It is a kind of code Dependency Inversion principle of design ideas. DETAILED employed is called dependency injection (the Dependency Injection) . In fact, these concepts initial contact will feel foggy. To put it bluntly, these types of concepts about the relationship as follows:
In order to understand these concepts, we still use the car example above. But this time into the code. We first define four Class, cars, body, chassis, tires. Then initialize the car, and finally run the car. Code structure is as follows:
Thus, is equivalent to the first example above, the superstructure rely on the underlying architecture - constructor for each class constructor is called directly underlying code. Suppose we need to change my tires (Tire) class, put it into a dynamic dimension, not always been 30. We need such a change:
Because we changed the definition of the tire, in order to allow normal operation of the whole process, we need to make the following changes:
From this we can see that, just to modify the constructor tires, but this design requires modifying all constructor entire upper class ! In software engineering, this design is almost impossible to maintain - in actual projects, some classes may be the underlying class of thousands, if each modification of this class, we have to modify all it as a dependency class, that software maintenance costs are too high. So we need to Inversion of Control (IoC), lower and upper control, rather than in control of the lower top. We rely on this way injection (Dependency Injection) to achieve the inversion of control. The so-called dependency injection, that is, the bottom class as a parameter the upper class, the upper class to a lower class to achieve "control ." Here we use dependency injection delivery constructor to re-write the definition of vehicle class:
Here we then become dynamic tire size, the same for the whole system running smoothly, we need to make the following changes: