依赖倒置原则之我见

依赖倒置原则（Dependence Inversion Principle），简称DIP。

定义：High level modules should not depend upon low level modules, Both should depend upon abstractions. Abstractions should not depend upon details, Details should depend upon abstractions.

即：高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。

抽象：即抽象类或接口，是不能够实例化的。

细节：即具体的实现类，实现接口或者继承抽象类所产生的类，可以通过关键字new直接被实例化。

问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。

依赖倒置原则其本质就是契约式编程，通过抽象（抽象类或接口）使各个类或模块的实现彼此独立，不相互影响，实现模块间的松耦合。使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。如果没有实现这个原则，那么也就意味着开闭原则（对扩展开发，对修改关闭）也无法实现。

在实际编程中，我们一般需要做到如下3点：

• 低层模块尽量都要有抽象类或接口，或者两者都有。
• 变量的声明类型尽量是抽象类或接口。
• 使用继承时遵循里氏替换原则。 

依赖倒置有三种方式来实现

1、通过构造函数传递依赖对象；

比如在构造函数中的需要传递的参数是抽象类或接口的方式实现。

2、通过setter方法传递依赖对象；

即在我们设置的setXXX方法中的参数为抽象类或接口，来实现传递依赖对象。

3、接口声明实现依赖对象，也叫接口注入；

即在函数声明中参数为抽象类或接口，来实现传递依赖对象，从而达到直接使用依赖对象的目的。

为方便理解，举一些生活中的例子：

1、AGP插槽。主板和显卡之间关系的抽象。主板和显卡通常是使用AGP插槽来连接的，这样，只要接口适配，不管是主板还是显卡更换，都不是问题。

2、驾照。司机和汽车之间关系的抽象。有驾照的司机可以驾驶各种汽车。

3、电源插座。

设计模式中最能体现DIP原则的是抽象工厂模式。在抽象工厂模式中，工厂和产品都可以是抽象的，如果客户要使用的话，只要关注于工厂和产品的接口即可，不必关注与工厂和产品的具体实现。

DIP对于并行开发的影响：两个类之间有依赖关系，只要制定出他们之间的接口，就可以并行开发了。

备注：

1、什么叫做高层模块依赖于底层模块？

      面向过程的开发时，为了复用一些常用代码，通常会把这些代码写成函数库的形式。这样，以后做新项目时，调用这些底层函数就可以了。这就叫做高层模块依赖于底层模块。

高层模块一般和业务逻辑相关，底层模块一般和具体实现相关。

2、何谓“倒置”？

   这是因为传统的软件开发方法，如结构化的分析和设计，倾向于创建高层模块依赖于低层模块、抽象依赖于具体的软件结构。实际上，这些方法的目标之一就是去定义描述上层模块如何调用低层模块的层次结构。所以，相对于传统的过程化的方法通常所产生的那种依赖结构，一个设计良好的面向对象的程序中的依赖结构就是“被倒置”的。

    来看一下那些依赖于低层模块的高层模块的含义。一个应用中的重要策略决定及业务模型正是在这些高层的模块中。也正是这些模型包含着应用的特性。但是，当这些模块依赖于低层模块时，低层模块的修改将会直接影响到它们，迫使它们也去改变。这种境况是荒谬的。应该是处于高层的模块去迫使那些低层的模块发生改变。应该是处于高层的模块优先于低层的模块。无论如何高层的模块也不应依赖于低层的模块。而且，我们想能够复用的是高层的模块。通过子程序库的形式，我们已经可以很好地复用低层的模块了。当高层的模块依赖于低层的模块时，这些高层模块就很难在不同的环境中复用。但是，当那些高层模块独立于低层模块时，它们就能很简单地被复用了。这正是位于框架设计的最核心之处的原则。