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

一、概念：

依赖倒置原则英文缩写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、接口声明依赖对象。

public interface ILoader {
public void removedBrick(Brick brick);
}

有所不足，多多指正，共同进步，万分感谢！

参考资料：

《设计模式之禅》

《HeadFirst》

《StartUML详解》

设计模式六大原则