面向对象设计原则--依赖倒置原则(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推演出来,而所有的这些原则的本质就是强调抽象,强调在高低层之间用上
一个抽象的中间层!以期降低模块间的耦合性!

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页