面向对象设计原则--依赖倒置原则(DIP)

在我们传统的结构化编程中，最上层的模块通常都要依赖下面的子模块来实现，也
称为高层依赖低层！
所以DIP原则就是要逆转这种依赖关系，让高层模块不要依赖低层模块，所以称之为依赖倒置原则！
DIP原则，我们可以从2点来解读：
第1点：高层模块不依赖底层模块，两者都依赖抽象
第2点：抽象不应该依赖于细节，细节应该依赖于抽象

上面这2点，也是教科书这么定义的，读上去比较抽象点！下面我会讲点自己的心得，和大家研究研究！不对的地方还请指教！

依照上面2点来做OOP，原则上可以解决高层的复用问题以及底层改动会波及到高层，形成赖传递的问题！

我百度了一下，找了不少解释，有一种讲解比较流行，但个人觉得有点问题：
--------原文是这样的---------------
依赖倒置（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创建型模式中的工厂模式！

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

其实不管是SRP好，OCP也好，还是LSP也好，都能够从DIP推演出来，而所有的这些原则的本质就是强调抽象，强调在高低层之间用上
一个抽象的中间层！以期降低模块间的耦合性！