DIP依赖倒置原则

一、定义

　　1.高层模块不应该依赖低层模块，二者都应该依赖抽象

　　2.抽象不应该依赖于细节。细节应该依赖于抽象

二、层次化

　　1.简单介绍

　　结构良好的面向对象架构都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务。

　　对于这个陈述的简单理解可能会致使设计者设计出类似下图的结构。

　　　　

　　图中，高层的Policy层使用了低层的Mechanism层，而Mechanism层又使用了更细节的Utility层。这样，Policy层对下面的Utility层的改动都是敏感的。 这种依赖关系是传递的。这是非常糟糕的。

　　下图则展示了一个更为合适的模型。 每个较高层次都为它所需要的服务声明一个抽象接口。较低的层次实现了这些抽象接口。每个高层类都通过该抽象接口使用下一层，这样高层就不依赖于低层。低层反而依赖于在高层中声明的抽象服务接口。这解除了Policy层、Mechanism层和Utility层的两两依赖关系。

　　　　

　　2.倒置的接口所有权

　　这里的倒置不仅仅是依赖关系的倒置，它也是接口所有权的倒置。

　　但是当应用DIP时，我们发现往往是客户拥有抽象接口，而它们的服务者则从这些抽象接口派生。

　　这就是著名的Hollywood(好莱坞)原则:"Don't call us,we'll call you.(不要找我们，我们会去找你)"。

　　低层模块实现了在高层模块中声明并被高层模块调用的接口。

　　Hollywood原则解释：

//不应用IOC
class A
{
    B b = new B(); 
} 
//应用IOC 
class A 
{
    B b = null; // 你不需要自己找B,当你需要的时候，B会自动替你初始化。
    public A(B b)
    {
        this.b=b;
    }     
}    

　　通过这种导致的接口所有权，对于Mechanism层或者Utility层的任务改动都不会再影响到Policy层。而且，Policy层可以定义符合policyServiceInstance的任何上下文重用。通过倒置这些依赖关系，我们创建了一个更灵活、更持久、更易改变的结构。

　　3.依赖于抽象

　　依赖于抽象建议我们不应该依赖于具体类--也就是说，程序中所有的依赖关系都应该终止于抽象类或者接口。

• 任何变量都不应该持有一个指向具体类的引用
• 任何类都不应该从具体类派生
• 任何方法都不应该重写它的任何基类中的已实现了的方法 有时必须创建具体类的实例，而创建的模块将会依赖它们，如果一个具体的类不太会改变，并且也不会创建其他类似的派生类，那么依赖于它并不会造成损害。

三、结论

　　事实上，这种依赖关系的导致正是好的面向对象设计的标志所在。使用何种语言来编写程序是无关紧要的。如果程序的依赖关系是倒置的，他就是面向对象的设计。如果程序的依赖关系不是倒置的，他就是过程化设计。