设计模式六大原则(3):依赖倒置原则 (转载)
定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。
问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。
解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率。
依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在 java中,抽象指的是接口或者抽象类,细节就是具体的实现类,使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任 务交给他们的实现类去完成。
依赖倒置原则的核心思想是面向接口编程,我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的,母亲给孩子讲故事,只要给她一本书,她就可以照着书给孩子讲故事了。代码如下:
class Book{ public String getContent(){ return "很久很久以前有一个阿拉伯的故事……"; } } class Mother{ public void narrate(Book book){ System.out.println("妈妈开始讲故事"); System.out.println(book.getContent()); } } public class Client{ public static void main(String[] args){ Mother mother = new Mother(); mother.narrate(new Book()); } }
运行结果:
妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
运行良好,假如有一天,需求变成这样:不是给书而是给一份报纸,让这位母亲讲一下报纸上的故事,报纸的代码如下:
class Newspaper{ public String getContent(){ return "林书豪38+7领导尼克斯击败湖人……"; } }
这位母亲却办不到,因为她居然不会读报纸上的故事,这太荒唐了,只是将书换成报纸,居然必须要修改Mother才能读。假如以后需求换成杂志呢?换 成网页呢?还要不断地修改Mother,这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了,必须降低他们之间的耦合度才行。
我们引入一个抽象的接口IReader。读物,只要是带字的都属于读物:
interface IReader{ public String getContent(); }
Mother类与接口IReader发生依赖关系,而Book和Newspaper都属于读物的范畴,他们各自都去实现IReader接口,这样就符合依赖倒置原则了,代码修改为:
interface IReader{ public String getContent(); } class Newspaper implements IReader { public String getContent(){ return "林书豪17+9助尼克斯击败老鹰……"; } } class Book implements IReader{ public String getContent(){ return "很久很久以前有一个阿拉伯的故事……"; } } class Mother{ public void narrate(IReader reader){ System.out.println("妈妈开始讲故事"); System.out.println(reader.getContent()); } } public class Client{ public static void main(String[] args){ Mother mother = new Mother(); mother.narrate(new Book()); mother.narrate(new Newspaper()); } }
运行结果:
妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
妈妈开始讲故事
林书豪17+9助尼克斯击败老鹰……
这样修改后,无论以后怎样扩展Client类,都不需要再修改Mother类了。这只是一个简单的例子,实际情况中,代表高层模块的 Mother类将负责完成主要的业务逻辑,一旦需要对它进行修改,引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性,提高系统的稳定性, 降低修改程序造成的风险。
采用依赖倒置原则给多人并行开发带来了极大的便利,比如上例中,原本Mother类与Book类直接耦合时,Mother类必须等Book类编码完成后才 可以进行编码,因为Mother类依赖于Book类。修改后的程序则可以同时开工,互不影响,因为Mother与Book类一点关系也没有。参与协作开发 的人越多、项目越庞大,采用依赖导致原则的意义就越重大。现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。
传递依赖关系有三种方式,以上的例子中使用的方法是接口传递,另外还有两种传递方式:构造方法传递和setter方法传递,相信用过Spring框架的,对依赖的传递方式一定不会陌生。
在实际编程中,我们一般需要做到如下3点:
- 低层模块尽量都要有抽象类或接口,或者两者都有。
- 变量的声明类型尽量是抽象类或接口。
- 使用继承时遵循里氏替换原则。
依赖倒置原则的核心就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。
相关推荐
依赖倒置原则的2个重要方针 1.高层模块不应该依赖于低层模块,二者都应该依赖于抽象 2.抽象不应该依赖于细节,细节应该依赖于抽象
依赖倒置原则(Dependence Inversion Principle),缩写为DIP。原始定义:High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend ...
The articles that will appear in this column will focus on the use of C++ and OOD, and will address issues of software engineering.
http://blog.csdn.net/xingjiarong/article/details/50094307
7依赖倒置原则-课程内容.rar
设计模式6大原则:依赖倒置原则
7依赖倒置原则-MOOC课程内容.pdf
主要介绍了PHP面向对象五大原则之依赖倒置原则(DIP),简单讲述了依赖倒置原则的概念、原理并结合实例形式分析了php依赖倒置原则相关定义与使用方法,需要的朋友可以参考下
本章我们要讲解的是S.O.L.I.D五大原则JavaScript语言实现的第5篇,依赖倒置原则LSP(The Dependency Inversion Principle )。 英文原文:...
注入依赖构造函数传递对象利用set方法传入依赖对象接口声明依赖对象,也叫接口注入注解注入最佳实践每个类都应该有其接口或者抽象,或者两者都有,有了抽象才可以依赖倒
依赖倒置 控制反转 依赖注入 面向
主要介绍了详解Java设计模式中的依赖倒置原则,针对面对对象编程中的抽象的运用,需要的朋友可以参考下
代码库解释依赖倒置原则 本练习的目标是开发依赖倒置原则 (DIP)。 您的任务:用 OpenStreetMapGeocoding 替换 GoogleGeocoding,并通过这样做来识别和纠正 DIP 违规。
依赖倒置原则(Dependence Inversion Principle,简称DIP)这个名字看着有点别扭,“依赖”还“倒置”,这到底是什么意思?依赖倒置原则的原始定义是:High level modules should not depend upon low level modules...
依赖倒置原则(The Dependency Inversion Principle?) 接口分离原则(The Interface Segregation Principle) 包的的设计原则 发布/重用等价原则(REP) 公共闭合原则(CCP) 共同重用原则(CRP) 非循环依赖原则(ADP) ...
“控制反转(Inversion of Control)的一个... Martin提出的依赖倒置原则(Dependency Inversion Principle),它的另一个昵称是好莱坞原则(Hollywood Principle:不要调用我,让我来调用你)”[PicoContainer 2004]。
3.依赖倒置原则:面向接口编程 4.接口隔离原则: 客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。 5.迪米特法则还有一个更简单的定义:只与直接的朋友通信。其中,我们称出现成员...