设计模式六大原则之依赖倒置原则

一、概念:

依赖倒置原则英文缩写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、高层模块不应该依赖低层模块,两者都应该依赖其抽象
2、抽象不应该依赖细节;
3、细节应该依赖抽象。


抽象:即抽象类或接口,两者是不能够实例化的。
细节:即具体的实现类,实现接口或者继承抽象类所产生的类,两者可以通过关键字new直接被实例化。

二、例子:

不依赖倒置原则:

以搬砖为例。搬运工,可以搬砖。砖头可以是红砖、水泥砖或其他砖。类图如下:

经验复用

这里以搬水泥砖和红砖为例:

水泥砖代码:

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 !
loader remove the Cement Brick !


结果打印出来了,搬运工搬砖成功。但是问题来了,搬运工应该可以搬运泥砖,如果要搬运泥砖的话:

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 remove the Cement Brick !


打印结果不变。但是这样的好处就是,你要增加其他类型的砖头的时候,不用修改loader类,只需某类型砖头,继承砖头抽象类,复写相关代码,然后测试类调用。可以达到要某类型砖头,就增加某类型砖头,而不用反反复复修改loader类。

三、依赖倒置的三种写法:

1、构造函数传递依赖对象。

/**
* 构造函数传递
* @param brick
*/
public Loader(Brick brick) {
// TODO Auto-generated constructor stub
this.brick=brick;
}

2、setter方法传递依赖对象。

public void setBrick(Brick brick)
{
this.brick=brick;
}

3、接口声明依赖对象。

package dim.DIP.simples.brick;
public interface IBrick {
public void removed(Brick brick);
}


有所不足,多多指正,共同进步,万分感谢!

参考资料:

《设计模式之禅》

《HeadFirst》

《StartUML详解》

设计模式六大原则


您的回应...

相关话题

查看全部

也许你感兴趣

换一批

热门标签

更多