六大设计原则之依赖倒置原则
Dependence Inversion Principle(DIP)
定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。
问题由来:类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的实现类,这就符合了依赖倒置原则
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()); } }
以后不管怎么扩展Client端,都不需要修改Mother这个类。实际中,Mother这个类将负责完成主要的业务逻辑,一旦需要对它进行修改,将会引入极大的风险。所有依赖倒置原则可以降低类之间的耦合,提高系统的稳定性,降低修改程序造成的风险。
传递依赖有三种方式,例子只是用了接口传递,另外两种传递方式:构造方法传递和setter传递
在实际中,我们要做到以下三点
- 底层模块尽量都要有抽象类或接口,或者两者都有
- 变量的声明类型尽量是抽象类或接口
- 使用继承时遵循里氏替换原则
转载http://blog.csdn.net/zhengzhb/article/details/7289269