设计模式六大原则之--依赖倒置原则（DIP）

1. 依赖倒置原则，(Dependence Inversion Principle, DIP )

定义：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.(高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。)

2.理解：

低层模块：不可分割的原子逻辑；

高层模块：低层模块的再组合；

抽象：   接口或抽象类（特点：不能直接被实例化）；

细节：   与接口或抽象类对应的实现类（特点：可以直拉被实例化）；

据此，DIP在Java语言中的表现就是：

1. 模块间的依赖通过抽象类或接口发生，实现类之间的依赖关系也是通过抽象类或接口产生（实现类之间不应发生直接的依赖关系）；
2. 接口或抽象不依赖于实现类，但实现类依赖接口或抽象类；

再次理解DIP：

依赖倒置原则 要求"高层模块不应该依赖于低层模块，二者都应该依赖于抽象。"这一原则在分层架构模式中，得到了淋漓尽致地运用。例如，业务逻辑层（高层模块）的对象就不应该直接依赖于数据访问层（低层模块）的具体实现对象，而应该通过数据访问层的抽象接口进行访问，如下图所示。如果高层模块直接依赖于低层模块，一旦低层模块发生变化，就会影响到高层模块。通过引入抽象，对于高层模块而言，低层模块的实现是可替换的。这实际上也是"开放封闭原则"的体现。这一原则同时还体现了软件设计对"间接"的追求。下图中的数据访问抽象层就是在设计中引入的一层间接性。

依赖倒置原则还要求"抽象不应该依赖于细节，细节应该依赖于抽象"。这与之前的要求一脉相承。关键仍然是"抽象"，抽象属于高层，细节属于低层，低层依赖于高层，而不是高层依赖于低层，这正是依赖倒置的真谛。依赖倒置原则与"面向接口编程"的思想不谋而合。GOF在《设计模式》一书中旗帜鲜明地提出了面向对象设计的首要原则，那就是"针对接口编程，而不是针对实现编程"。因为客户程序关心的仅仅是对象提供什么功能，而不是功能如何实现，甚至不关心对象的具体类型。这就好像电源插头只关心插座是两相还是三相，而无需知道插头如何与插座内的电线相连。

什么是依赖“正置”、“反置”？

依赖正置：类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程。这也是正常人的思维方式，比如要开奔驰就开奔驰（而没考虑宝马），

依赖倒置：编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”便由此而生。

3.问题由来：

类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。[解决方案]将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

4.使用DIP的好处：

• 可以通过抽象使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合（也是本质）；
• 可以规避一些非技术因素引起的问题（如项目大时，需求变化的概率也越大，通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束，可以减少需求变化引起的工作量剧增情况。同时，发生人员变动，只要文档完善，也可让维护人员轻松地扩展和维护）；
• 可以促进并行开发（如，两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行，而TDD开发模式更是DIP的最高级应用（特别适合项目人员整体水平较低时使用））。

5.难点：

• DIP是6大原则中最难以实现的原则，它是实现开闭原则的重要途径，DIP没有实现，就别想实现对扩展开放，对修改关闭。在项目中只要记住“面向接口编程”就基本上抓住了DIP的核心。
• 使用此原则时要审时度势，每个原则的优点都是有限度的，所以别为一个原则而放弃了终极目标：投产上线和盈利。

6.实践建议：

• 每个类尽量都有接口或抽象类，或者二者都有；（有了抽象才可能DIP）
  
• 变量的表面尽量是接口或抽象类；（工具类一般不需要）
  

• 任何类都不应该从具体类派生；（如果项目处于开发状态，就不应该有这种情况，当然，设计缺陷在所难免，因此不要超过两层的继承。但对于项目维护者来说，可以不用考虑这个规则，因为维护工作基本上都是进行扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的bug，何必去继承最高的基类呢？（当然不应该轻易继承，之所以要这样，是因为可能不甚了解父类或者无法获得父类的代码））

7依赖的三种写法：

依赖是可以传递的，只要做到抽象依赖，即使是多层的依赖传递也无所畏惧。

A。构造函数传递依赖对象

public interface IDriver{
	//是司机就应该会驾驶汽车
	public void drive();
}

public class Driver implements IDriver{
	private ICar car;
	//构造函数注入
	public Driver(ICar _car){
		this.car = _car;
	}	
	//司机的主要职责就是驾驶汽车
	public void drive(){
		this.car.run();
	}
}

B。Setter方法传递依赖对象

public interface IDriver {
	//车辆型号
	public void setCar(ICar car);
	//是司机就应该会驾驶汽车
	public void drive();
}

public class Driver implements IDriver{
	private ICar car;
	public void setCar(ICar car){
		this.car = car;
	}
	//司机的主要职责就是驾驶汽车
	public void drive(){
		this.car.run();
	}
}

C。接口声明依赖对象

public interface IDriver{
	//是司机就应该会驾驶汽车
	public void drive(ICar car);
}

public class Driver implements IDriver{
	//司机的主要职责就是驾驶汽车
	public void drive(ICar car){
		car.run();
	}
}

8.范例：

8.1 面对实现编程（当然，这里为了展现出问题，当然最小需求时，可以这样。。。）

司机驾驶奔驰车类图

//司机源代码
public class Driver{
	//是司机就应该会驾驶汽车
	public void drive(Benz benz){//1
		benz.run();
	}
}
//奔驰源代码
public class Benz{
	//汽车肯定会跑
	public void run(){
		System.out.println("奔驰汽车开始运行。。。");
	}
}
//场景类源代码
public class Client{
	public static void main(String[] args){
		Driver zhangsan = new Driver();
		Benz benz = new Benz();//2
		//张三开奔驰车
		zhangsan.drive(benz);
	}
}

但假若现在给出宝马类，发生变更呢？

//宝马车源代码
public class BMW{
	//汽车肯定会跑
	public void run(){
		System.out.println("宝马汽车开始运行。。。");
	}
}

看看，宝马有了，却不能让张三开起来，这也太不合理了，我们的设计出了问题：司机类和奔驰类之间是 紧耦合 的关系，其导致的结果就是系统的可维护性大降低，可读性降低。//若需要改为开宝马，必须得更改上述标注的 第1（低层模块，太不应该）、2（高层模块，业务变化，应该略做更改，正常） 处才可以。

8.2 现根据DIP原则，重新编写如下：

引入DIP后的类图

下面建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，在IDriver中，通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入ICar接口，至于到底是哪个类型号的Car，需要在高层模块中声明或修正。

public interface IDriver{
	//是司机就应该会驾驶汽车
	public void drive(ICar car);
}

public class Driver implements IDriver{
	//司机的主要职责就是驾驶汽车
	public void drive(ICar car){
		car.run();
	}
}

public interface ICar{
	//是汽车就应该能跑
	public void run();
}


//奔驰源代码
public class Benz implements ICar{
	//汽车肯定会跑
	public void run(){
		System.out.println("奔驰汽车开始运行。。。");
	}
}

//宝马车源代码
public class BMW implements ICar{
	//汽车肯定会跑
	public void run(){
		System.out.println("宝马汽车开始运行。。。");
	}
}

//场景类源代码
public class Client{
	public static void main(String[] args){
		Driver zhangsan = new Driver();
		Benz benz = new Benz();//可更改这里
		//张三开奔驰车
		zhangsan.drive(benz);//可更改这里
	}
}	

若为宝马了，只需在高层模块进行变换（上述浅兰标注），代码如下：

//场景类源代码
public class Client{
	public static void main(String[] args){
		Driver zhangsan = new Driver();
	        BWM bwm = new BWM();
		//张三开宝马
		zhangsan.drive(bwm);
	}
}	

这样，在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他低层模块如Driver类不需要任何修改，业务就可以运行，
把变更引起的风险降低到最小。


8.3  再来思考依赖倒置对并行开发的影响。两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行，而TDD(Test-Driven Development,测试驱动开发)开发模式就是DIP的最高级应用。
回顾上述例子，甲程序员负责IDriver的开发，乙程序员负责ICar的开发，两个开发人员只要制定好了接口，就可以独立地开发了，甲开发进度比较快， 完成了IDriver以及相关的实现类Driver的开发工作，而乙程序员滞后开发，那甲是否可以进行单元测试呢？可以，我们引入一个JMock工具，其最基本的功能就是根据抽象虚拟一个对象进行测试，测试类如下所示：

	//测试类
	public class DriverTest extends TestCase{
		Mockery context = new JUnit4Mockey();
		@Test
		public void testDriver(){
			//根据接口虚拟一个对象
			final ICar car = context.mock(ICar.class);
			IDriver driver = new Driver();
			//内部类
			context.checking(new Expectations()){
				oneOf(car).run();
			});
			driver.drive(car);
		}
	}

转自： http://blog.csdn.net/yuanlong_zheng/article/details/7434172