设计模式六大原则之依赖倒置原则
一、概念:依赖倒置原则英文缩写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详解》 设计模式六大原则 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
