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.
Inversion of control (Inversion of Control) is dependent Inversion Principle] A code 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:
, 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:
did you see? Here I only need to change tire type on the line, do not modify any other upper class. This is obviously easier to maintain code. Moreover, in the actual project, this design pattern is also beneficial collaboration and unit testing different groups: such as the development of these four classes are four different groups, so long as the definition of a good interface, four different the group can be carried out simultaneously without mutual development restricted; and for unit tests, if we want to write unit tests for the Car class, you only need to look at Mock Framework classes incoming Car on the line, rather than the Framework, Bottom, Tire all new once again construction Car.
这里我们是采用的构造函数传入的方式进行的依赖注入。其实还有另外两种方法：Setter传递和接口传递。这里就不多讲了，核心思路都是一样的，都是为了实现控制反转。
看到这里你应该能理解什么控制反转和依赖注入了。那什么是控制反转容器(IoC Container)呢？其实上面的例子中，对车类进行初始化的那段代码发生的地方，就是控制反转容器。
显然你也应该观察到了，因为采用了依赖注入，在初始化的过程中就不可避免的会写大量的new。这里IoC容器就解决了这个问题。这个容器可以自动对你的代码进行初始化，你只需要维护一个Configuration（可以是xml可以是一段代码），而不用每次初始化一辆车都要亲手去写那一大段初始化的代码。这是引入IoC Container的第一个好处。
IoC Container的第二个好处是：我们在创建实例的时候不需要了解其中的细节。在上面的例子中，我们自己手动创建一个车instance时候，是从底层往上层new的：
这个过程中，我们需要了解整个Car/Framework/Bottom/Tire类构造函数是怎么定义的，才能一步一步new/注入。
而IoC Container在进行这个工作的时候是反过来的，它先从最上层开始往下找依赖关系，到达最底层之后再往上一步一步new（有点像深度优先遍历）：
这里IoC Container可以直接隐藏具体的创建实例的细节，在我们来看它就像一个工厂：
我们就像是工厂的客户。我们只需要向工厂请求一个Car实例，然后它就给我们按照Config创建了一个Car实例。我们完全不用管这个Car实例是怎么一步一步被创建出来。
实际项目中，有的Service Class可能是十年前写的，有几百个类作为它的底层。假设我们新写的一个API需要实例化这个Service，我们总不可能回头去搞清楚这几百个类的构造函数吧？IoC Container的这个特性就很完美的解决了这类问题——因为这个架构要求你在写class的时候需要写相应的Config文件，所以你要初始化很久以前的Service类的时候，前人都已经写好了Config文件，你直接在需要用的地方注入这个Service就可以了。这大大增加了项目的可维护性且降低了开发难度。
转自：https://www.zhihu.com/question/23277575/answer/169698662