设计模式--------依赖倒置原则（DIP）

依赖倒置原则DIP(Dependency-Inversion Principles)

在传统的结构化编程中，最上层的模块通常都要依赖下面的子模块来实现，也称为高层依赖低层！

DIP原则就是要逆转这种依赖关系，让高层模块不要依赖低层模块.

教科书上的定义：
第1点：高层模块不依赖底层模块，两者都依赖抽象
第2点：抽象不应该依赖于细节，细节应该依赖于抽象

每个较高层次都为它所需要的服务声明一个抽象接口,较低的层次实现这些抽象接口,每个高层类都通过该抽象接口使用下一层的服务,接口属于高层,低层要实现高层的接口,因此现在是低层依赖于高层.
是依赖关系倒置和接口所有权的倒置.

启发式规则:
1.任何变量都不应该持有一个指向具体类的指针或者引用.
2.任何类都不应该从具体类派生(始于抽象,来自具体)
3.任何方法都不应该覆写它的任何基类中的已经实现了的方法.

这个原则对于那些虽然具体但是却稳定的类来说似乎并不是很合适， 如果一个类不太会改变， 而且也不太可能创建其他的派生类，那么依赖它似乎并没有太大的危害。比如java的String类。

我百度了一下，找了不少解释，有一种讲解比较流行，但个人觉得有点问题：
--------原文是这样的---------------
依赖倒置（Dependence Inversion Principle）原则讲的是：要依赖于抽象，不要依赖于具体。
简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：
抽象不应当依赖于细节；细节应当依赖于抽象；
要针对接口编程，不针对实现编程。

反面例子：

缺点：耦合太紧密，Light发生变化将影响ToggleSwitch。

解决办法一：
将Light作成Abstract，然后具体类继承自Light。

优点：ToggleSwitch依赖于抽象类Light，具有更高的稳定性，而BulbLight与Tube

Light继承自Light，可以根据"开放－封闭"原则进行扩展。只要Light不发生变化，BulbLight与TubeLight的变化
就不会波及ToggleSwitch。

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

解决方法二：

优点：更为通用、更为稳定。

结论：
使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为

策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定

性决定了系统的稳定性。

---------------原文结束-----------

正如他的UML图所示
在ToggleSwitch依赖于抽象类Light，那么在ToggleSwitch在实例化的时候，照他

的UML那样，肯定得如下写：Light light=new BulbLight() 或者 new

TubeLight()
那这样，又把底层的依赖给传递到高层了！这和初衷相违背的！
应该按照OO的原则，哪里有变化，就封装那里！
所以我觉得在ToggleSwitch和Light之间应该有个封装类，来封装这个变化点！
正如GOF创建型模式中的工厂模式！

总言之，这个原则的本质就是用抽象（接口或者抽象类）来使高层模块独立于底层模块！以达到高层的自由复用！