DIP依赖倒置原则

1、定义

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

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

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.依赖于抽象

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

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

3、结论

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