第五章 会修电脑不会修收音机?---依赖倒转原则(设计模式六大原则(3):依赖倒置原则)

前端之家收集整理的这篇文章主要介绍了第五章 会修电脑不会修收音机?---依赖倒转原则(设计模式六大原则(3):依赖倒置原则)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

1.依赖倒转原则:抽象不应该依赖细节,细节应该依赖于抽象。就是要针对接口来编程,不要对实现编程。组装机过程中,cpu,内存,硬盘都是在针对接口设计的,如果针对实现来设计,那就会出现换内存需要把主板也换了的尴尬。

2.高层模块不应该依赖底层模块。两个都应该依赖抽象。

3.里氏代换原则:子类型必须能够替换掉他们的父类型。子类继承了父类,那么子类可以以父类的形式出现。

4.在编程世界里,企鹅不能以父类--鸟的身份出现,因为前提说所有鸟都能飞,而企鹅飞不了,所以企鹅不能继承鸟类。如果企鹅继承了鸟,那么企鹅就会飞。

5.只有当子类可以替换掉父类,软件单位的功能不受到影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为。

6.高层模块不应该依赖于底层模块,两个都应该依赖抽象。

7.依赖倒转其实就是谁也不要依靠谁,除了约定的接口,大家都可以灵活自如。

8.收音机跟电脑相比就是耦合过度,只要收音机出故障,不管是没有声音,不能调频,还是有杂音,反正都很难修理,不懂得人根本修不来。

9.依赖倒转其实可以说是面向对象设计的标志,用哪种语言来编写程序不重要,如果编写时考虑的都是如何针对抽象编程而不是针对细节编程,即程序中所有的依赖关系都是终止于抽象类或者借口,那就是面向对象的设计,反之就是过程化的设计了。


依赖倒转原则即 依赖倒置原则 。

依赖倒置原则

A.高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象。

B.抽象不应该依赖于具体,具体应该依赖于抽象。

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

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

背景1:公司是福特和本田公司的金牌合作伙伴,现要求开发一套自动驾驶系统,只要汽车上安装该系统就可以实现无人驾驶,该系统可以在福特和本田车上使用,只要这两个品牌的汽车使用该系统就能实现自动驾驶。于是有人做出了分析如图一。

对于图一分析:我们定义了一个AutoSystem类,一个FordCar类,一个HondaCar类。FordCar类和HondaCar类中各有三个方法:Run(启动Car)、Turn(转弯Car)、Stop(停止Car),当然了一个汽车肯定不止这些功能,这里只要能说明问题即可。AutoSystem类是一个自动驾驶系统,自动操纵这两辆车。

背景2:公司的业务做大了,同时成为了通用、三菱、大众的金牌合作伙伴,于是公司要求该自动驾驶系统也能够安装在这3种公司生产的汽车上。于是我们不得不变动AutoSystem:

现在AutoSystem系统依赖于ICar 这个抽象,而与具体的实现细节HondaCar、FordCar、BmwCar无关,所以实现细节的变化不会影响AutoSystem。对于实现细节只要实现ICar 即可,即实现细节依赖于ICar 抽象。
综上:
一个应用中的重要策略决定及业务模型正是在这些高层的模块中。也正是这些模型包含着应用的特性。但是,当这些模块依赖于低层模块时,低层模块的修改将会直接影响到它们,迫使它们也去改变。这种境况是荒谬的。应该是处于高
层的模块去迫使那些低层的模块发生改变。应该是处于高层的模块优先于低层的模块。无论如何高层的模块也不应依赖于低层的模块。而且,我们想能够复用的是高层的模块。通过 子程序库的形式,我们已经可以很好地复用低层的模块了。当高层的模块依赖于低层的模块时,这些高层模块就很难在不同的环境中复用。但是,当那些高层 模块独立于低层模块时,它们就能很简单地被复用了。这正是位于框架设计的最核心之处的原则。
总结:依赖倒置原则
A.高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象。
B.抽象不应该依赖于具体,具体应该依赖于抽象。
原文链接:https://www.f2er.com/javaschema/285587.html

猜你在找的设计模式相关文章