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

依赖倒置原则（Dependence Inversion Principle， DIP）

定义：依赖倒置原则具有以下三层含义：

1、高层模块不应该依赖底层模块，两者都应该依赖其抽象；

2、抽象不应该依赖细节；

3、细节应该依赖抽象。

问题由来：类A直接依赖类B，若要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般为高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类A修改为直接依赖接口I，类B和类C实现接口I，这样类A通过接口I和类B或者类C发生联系。

我们用一个例子说明依赖倒置原则。如下述代码所示：

public class BMWCar {
	
	public void run(){
		System.out.println("BMW is runing.....");
	}

}

public class Driver {
	public void drive(BMWCar bmw){
		System.out.println("Driver is driving");
		bmw.run();
	}
}

public class Client {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		Driver driver=new Driver();
		driver.drive(new BMWCar());

	}

}

     那现在如果司机开的是Benz的车，那么我们就得要修改Driver类的drive行为了。那如果司机还开别的类型的车，比如Bick等，那我们岂不是都是对Driver的drive行为作出更改。这是什么原因呢？因为Driver和BMWCar之间的耦合度太强了！

   因此我们引入一个抽象的接口ICar，Driver类与ICar发生依赖关系，BMWCar和BenzCar等实现ICar.

public interface ICar {
	public void run();

}

public class BMWCar implements ICar{
	
	public void run(){
		System.out.println("BMW is runing.....");
	}

}

public class BenzCar implements ICar {

	public void run(){
		System.out.println("Benz is runing.....");
	}
}

public class Driver {
	public void drive(ICar car){
		System.out.println("Driver is driving");
		car.run();
	}
}

public class Client {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		Driver driver=new Driver();
		driver.drive(new BMWCar());
		driver.drive(new BenzCar());

	}
}

      这样修改后，无论以后怎样扩展Client类，都不需要再修改Driver类了。这只是一个简单的例子，实际情况中，代表高层模块的Driver类将负责完成主要的业务逻辑，一旦需要对它进行修改，引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。

      从这个例子，我们可以看出，依赖倒置原则的核心思想是面向接口编程。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。

     依赖关系有三种方式:

1)接口传递依赖对象，如上述例子中使用的方法是接口传递；

2）构造方法传递依赖对象；

3）setter方法传递依赖对象。

    在实际编程中，对于依赖倒置原则的使用，我们需要做到如下3点：

• 低层模块尽量都要有抽象类或接口，或者两者都有。
• 变量的声明类型尽量是抽象类或接口。
• 任何类都不应该从具体类派生。
• 尽量不要覆写基类的方法。
• 使用继承时遵循里氏替换原则。