设计模式系列文章问题由来
类A直接依赖于类B，加入要将类A修改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑。类B和C是底层模块，负责基本的原子操作。假如修改类A，将会给程序带来不必要的风险。而遵循依赖倒置原则的程序设计可以解决这一问题。
什么是依赖倒置原则
英文缩写DIP（Dependence Inversion Principle）。
原始定义：High level modules should depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
翻译过来就三层含义：
抽象：即抽象类或接口，两者是不能够实例化的。
细节：即具体的实现类，实现接口或者继承抽象类所产生的类，两者可以通过关键字new直接被实例化。
现在我们来通过实例还原开篇问题的场景，以便更好的来理解。下面代码描述了一个简单的场景，Jim作为人有吃的方法，苹果有取得自己名字的方法，然后实现Jim去吃苹果。代码如下：
//具体Jim人类public class Jim {public void eat(Apple apple){System.out.println(“Jim eat ” + apple.getName());}}//具体苹果类public class Apple {public String getName(){return “apple”;}}public class Client {public static void main(String[] args) {Jim jim = new Jim();Apple apple = new Apple();jim.eat(apple);}}
运行结果：Jim eat apple
上面代码看起来比较简单，但其实是一个非常脆弱的设计。现在Jim可以吃苹果了，但是不能只吃苹果而不吃别的水果啊，这样下去肯定会造成营养失衡。现在想让Jim吃香蕉了（好像香蕉里含钾元素比较多，吃点比较有益），突然发现Jim是吃不了香蕉的，那怎么办呢？看来只有修改代码了啊，由于上面代码中Jim类依赖于Apple类，所以导致不得不去改动Jim类里面的代码。那如果下次Jim又要吃别的水果了呢？继续修改代码？这种处理方式显然是不可取的，频繁修改会带来很大的系统风险，改着改着可能就发现Jim不会吃水果了。
上面的代码之所以会出现上述难堪的问题，就是因为Jim类依赖于Apple类，两者是紧耦合的关系，其导致的结果就是系统的可维护性大大降低。要增加香蕉类却要去修改Jim类代码，这是不可忍受的，你改你的代码为什么要动我的啊，显然Jim不乐意了。我们常说要设计一个健壮稳定的系统，香港虚拟主机，而这里只是增加了一个香蕉类，就要去修改Jim类，健壮和稳定还从何谈起。
而根据依赖倒置原则，我们可以对上述代码做些修改，提取抽象的部分。首先我们提取出两个接口：People和Fruit，都提供各自必需的抽象方法，这样以后无论是增加Jim人类，还是增加Apple、Banana等各种水果，都只需要增加自己的实现类就可以了。由于遵循依赖倒置原则，只依赖于抽象，而不依赖于细节，所以增加类无需修改其他类。代码如下：
//人接口public interface People {public void eat(Fruit fruit);//人都有吃的方法，不然都饿死了}//水果接口public interface Fruit {public String getName();//水果都是有名字的}//具体Jim人类public class Jim implements People{public void eat(Fruit fruit){System.out.println(“Jim eat ” + fruit.getName());}}//具体苹果类public class Apple implements Fruit{public String getName(){return “apple”;}}//具体香蕉类public class Banana implements Fruit{public String getName(){return “banana”;}}public class Client {public static void main(String[] args) {People jim = new Jim();Fruit apple = new Apple();Fruit Banana = new Banana();//这里符合了里氏替换原则jim.eat(apple);jim.eat(Banana);}}
运行结果：
Jim eat appleJim eat banana
什么是倒置
到了这里，我们对依赖倒置原则的“依赖”就很好理解了，但是什么是“倒置”呢。是这样子的，刚开始按照正常人的一般思维方式，我想吃香蕉就是吃香蕉，想吃苹果就吃苹果，编程也是这样，都是按照面向实现的思维方式来设计。而现在要倒置思维，提取公共的抽象，面向接口（抽象类）编程。不再依赖于具体实现了，而是依赖于接口或抽象类，这就是依赖的思维方式“倒置”了。
依赖的三种实现方式
对象的依赖关系有三种方式来传递：
接口方法中声明依赖对象。就是我们上面代码所展示的那样。构造方法传递依赖对象。在构造函数中的需要传递的参数是抽象类或接口的方式实现。代码如下：//具体Jim人类public class Jim implements People{private Fruit fruit;public Jim(Fruit fruit){//构造方法传递依赖对象this.fruit = fruit;}public void eat(Fruit fruit){System.out.println(“Jim eat ” + this.fruit.getName());}}Setter方法传递依赖对象。在我们设置的setXXX方法中的参数为抽象类或接口，来实现传递依赖对象。代码如下：//具体Jim人类public class Jim implements People{private Fruit fruit;public void setFruit(Fruit fruit){//setter方式传递依赖对象this.fruit = fruit;}public void eat(){System.out.println(“Jim eat ” + this.fruit.getName());}}优点
从上面的代码修改过程中，我们可以看到由于类之间松耦合的设计，面向接口编程依赖抽象而不依赖细节，所以在修改某个类的代码时，不会牵涉到其他类的修改，显著降低系统风险，提高系统健壮性。
还有一个优点是，在我们实际项目开发中，都是多人团队协作，每人负责某一模块。比如一个人负责开发People模块，一人负责开发Fruit模块，如果未采用依赖倒置原则，香港服务器租用，没有提取抽象，那么开发People模块的人必须等Fruit模块开发完成后自己才能开发，香港服务器，否则编译都无法通过，这就是单线程的开发。为了能够两人并行开发，设计时遵循依赖倒置原则，提取抽象，就可以大大提高开发进度。
总结可以提高你的水平。(戏从对手来。
