第五章 会修电脑不会修收音机？---依赖倒转原则（设计模式六大原
|
1.依赖倒转原则：抽象不应该依赖细节，细节应该依赖于抽象。就是要针对接口来编程，不要对实现编程。组装机过程中，CPU，内存，硬盘都是在针对接口设计的，如果针对实现来设计，那就会出现换内存需要把主板也换了的尴尬。 2.高层模块不应该依赖底层模块。两个都应该依赖抽象。 3.里氏代换原则：子类型必须能够替换掉他们的父类型。子类继承了父类，那么子类可以以父类的形式出现。 4.在编程世界里，企鹅不能以父类--鸟的身份出现，因为前提说所有鸟都能飞，而企鹅飞不了，所以企鹅不能继承鸟类。如果企鹅继承了鸟，那么企鹅就会飞。 5.只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。 6.高层模块不应该依赖于底层模块，两个都应该依赖抽象。 7.依赖倒转其实就是谁也不要依靠谁，除了约定的接口，大家都可以灵活自如。 8.收音机跟电脑相比就是耦合过度，只要收音机出故障，不管是没有声音，不能调频，还是有杂音，反正都很难修理，不懂得人根本修不来。 9.依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者借口，那就是面向对象的设计，反之就是过程化的设计了。
依赖倒转原则即 依赖倒置原则 。 依赖倒置原则 A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。 B.抽象不应该依赖于具体，具体应该依赖于抽象。 所谓依赖倒置原则（Dependence Inversion Principle）就是要依赖于抽象，不要依赖于具体。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。
面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让
用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的
耦合度。
背景1：公司是福特和本田公司的金牌合作伙伴，现要求开发一套自动驾驶系统，只要汽车上安装该系统就可以实现无人驾驶，该系统可以在福特和本田车上使用，只要这两个品牌的汽车使用该系统就能实现自动驾驶。于是有人做出了分析如图一。
背景2：公司的业务做大了，同时成为了通用、三菱、大众的金牌合作伙伴，于是公司要求该自动驾驶系统也能够安装在这3种公司生产的汽车上。于是我们不得不变动AutoSystem：
（编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |