DIP依赖倒置原则

一、定义

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

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

二、层次化

  1.简单介绍

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

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

    DIP依赖倒置原则

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

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

    DIP依赖倒置原则

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

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

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

三、结论

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

上一篇:Android中简单活动窗口的切换--Android


下一篇:C#截取当前活动窗体的图片