设计模式六大原则之依赖倒置原则
一、概念:依赖倒置原则英文缩写DIP(Dependence Inversion Principle)原始定义:High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. 翻译过来就三层含义: 1、高层模块不应该依赖低层模块,两者都应该依赖其抽象;
抽象:即抽象类或接口,两者是不能够实例化的。 二、例子:不依赖倒置原则: 以搬砖为例。搬运工,可以搬砖。砖头可以是红砖、水泥砖或其他砖。类图如下:
这里以搬水泥砖和红砖为例: 水泥砖代码: package dim.DIP.simples; public class CementBrick { /** * 搬水泥砖 */ public void removed() { System.out.println("loader remove the Cement Brick !"); } } 红砖代码: package dim.DIP.simples; public class RedBrick { /** * 搬红砖 */ public void removed() { System.out.println("loader remove the redBrick !"); } } 搬运工: package dim.DIP.simples; public class Loader { /** * 搬运工,搬红砖 */ public void removedRBrick() { new RedBrick().removed(); } /** * 搬运工搬水泥砖 */ public void removedCbrick() { new CementBrick().removed(); } } 测试类: package dim.DIP.simples; public class TestClass { public static void main(String[] args) { //搬运工 Loader loader=new Loader(); //搬水泥砖 loader.removedCbrick(); //搬红砖 loader.removedRBrick(); } } 打印结果: loader remove the redBrick !
结果打印出来了,搬运工搬砖成功。但是问题来了,搬运工应该可以搬运泥砖,如果要搬运泥砖的话: 1、要增加泥砖类。 2、要修改loader类,增加搬运泥砖的操作。 3、测试类也要改动。 增加一两类砖可以很快修改代码。但是增加100类、1000类怎么搞。难道还得修改1000次loader类?这不科学。得遵循依赖倒置原则。
依赖倒置原则简单运用: 同样是上述搬砖情景,但是类图如下:
这里砖头是抽象,红砖和水泥砖是细节。红砖,水泥砖要依赖于砖头类。但是砖头不依赖于红砖与水泥砖。 loaderClass也是抽象类,loader是细节。
代码如下: 砖头抽象类: package dim.DIP.simples.brick; public abstract class Brick { /** * 可以被搬 */ public abstract void removed(); /** * 可以砌墙 */ public abstract void builded(); } 水泥砖继承砖头抽象类:
package dim.DIP.simples.brick; public class CementBrick extends Brick{ public void removed() { System.out.println("loader remove the Cement Brick !"); } @Override public void builded() { // TODO Auto-generated method stub } } 红砖继承砖头抽象类:
package dim.DIP.simples.brick; public class RedBrick extends Brick{ public void removed() { System.out.println("loader remove the redBrick !"); } @Override public void builded() { // TODO Auto-generated method stub } } 搬运工抽象类:
package dim.DIP.simples.brick; public abstract class LoaderClass { /** * 有能力搬砖 */ public abstract void removedBrick(); } 搬运工继承搬运工抽象类:
package dim.DIP.simples.brick; public class Loader extends LoaderClass{ private Brick brick; /** * 构造函数传递 * @param brick */ public Loader(Brick brick) { // TODO Auto-generated constructor stub this.brick=brick; } /** * 搬运工,搬砖 */ public void removedBrick() { brick.removed(); } /** * 设置搬什么砖 * @param brick */ public void setBrick(Brick brick) { this.brick=brick; } } 测试类: package dim.DIP.simples.brick; public class TestClass { public static void main(String[] args) { //搬红砖 Brick RBrick=new RedBrick(); Loader loader=new Loader(RBrick); loader.removedBrick(); //搬水泥砖 Brick CBrick=new CementBrick(); loader.setBrick(CBrick); loader.removedBrick(); } } 测试结果: loader remove the redBrick !
打印结果不变。但是这样的好处就是,你要增加其他类型的砖头的时候,不用修改loader类,只需某类型砖头,继承砖头抽象类,复写相关代码,然后测试类调用。可以达到要某类型砖头,就增加某类型砖头,而不用反反复复修改loader类。 三、依赖倒置的三种写法:1、构造函数传递依赖对象。 /** 2、setter方法传递依赖对象。 public void setBrick(Brick brick) 3、接口声明依赖对象。 有所不足,多多指正,共同进步,万分感谢! 参考资料: 《设计模式之禅》 《HeadFirst》 《StartUML详解》 设计模式六大原则 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |