设计模式之依赖倒置原则含义及现实举例

发布时间：2015-04-02 00:00 来源：偶my耶的博客

所谓依赖倒置原则（Dependence Inversion Principle ）就是要依赖于抽象，不要依赖于具体。简单的说就是对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变化时，上层也要跟着变化，这就会导致模块的复用性降低而且大大提高了开发的成本。 面向对象的开发很好的解决了这个问题，一般的情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变化，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序域实现细节的耦合度。

抽象不应该依赖细节，细节应该依赖于抽象。说白了，就是针对接口编程，不要针对实现编程。

依赖倒置原则包含三层含义：

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

2)抽象不应该依赖细节;

3)细节应该依赖抽象。

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

1、通过构造函数传递依赖对象； 比如在构造函数中的需要传递的参数是抽象类或接口的方式实现。

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

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

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

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

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

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

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

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

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

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

2、何谓“倒置”？

这是因为传统的软件开发方法，如结构化的分析和设计，倾向于创建高层模块依赖于低层模块、抽象依赖于具体的软件结构。实际上，这些方法的目标之一就是去定义描述上层模块如何调用低层模块的层次结构。因此，相对于传统的过程化的方法通常所产生的那种依赖结构，一个设计良好的面向对象的程序中的依赖结构就是“被倒置”的。 来看一下那些依赖于低层模块的高层模块的含义。一个应用中的重要策略决定及业务模型正是在这些高层的模块中。也正是这些模型包含着应用的特性。但是，当这些模块依赖于低层模块时，低层模块的修改将会直接影响到它们，迫使它们也去改变。这种境况是荒谬的。应该是处于高层的模块去迫使那些低层的模块发生改变。应该是处于高层的模块优先于低层的模块。无论如何高层的模块也不应依赖于低层的模块。而且，我们想能够复用的是高层的模块。通过子程序库的形式，我们已经可以很好地复用低层的模块了。

当高层的模块依赖于低层的模块时，这些高层模块就很难在不同的环境中复用。但是，当那些高层模块独立于低层模块时，它们就能很简单地被复用了。这正是位于框架设计的最核心之处的原则。