依赖倒置（Dependence Inversion Principle）原则讲的是：要依赖于抽象，不要依赖于具体。

简单的说，依赖倒置原则要求客户端依赖于抽象耦合。

抽象不应当依赖于细节；细节应当依赖于抽象；

要针对接口编程，不针对实现编程。

 

举例说明：

 

反面例子：

 

缺点：

耦合太紧密，Light发生变化将影响ToggleSwitch

 

解决办法一：

将Light作成Abstract，然后具体类继承自Light。

 

 

 

优点：

ToggleSwitch依赖于抽象类Light，具有更高的稳定性，而BulbLight与TubeLight继承自Light，可以根据"开放－封闭"原则进行扩展。只要Light不发生变化，BulbLight与TubeLight的变化就不会波及ToggleSwitch。

 

缺点：

如果用ToggleSwitch控制一台电视就很困难了。总不能让TV继承自Light吧。

 

解决方法二：

 

 

 

 

优点：

更为通用、更为稳定。

 

 

启发式规则:

1、任何变量都不应该持有一个指向具体类的指针或者引用

2、任何类都不应该从具体类派生(始于抽象,来自具体)

3、任何方法都不应该覆写它的任何基类中的已经实现了的方法

 

如何抽象:

抽象反映高层策略，就是应用中那些不会随着具体细节的改变而改变的规则，常用的词语就是隐喻(metaphore).仔细分析需求，先找出那些业务规则，然后把它们抽象出来形成你的接口。层次化你的设计，常见的方式就是划分出显示层，业务层，持久层，再在每层做抽象。这是最粗糙的层次化，你可以在每层再根据需要划分更细的层次。在实现的时候始终遵循前面提到的原则：只依赖于接口。谁也无法在开始就做到最好，因此要不断迭代，精化设计。

使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。

 

 

结论：

使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。