类A直接依赖于类B，假如要将类A修改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑。类B和C是底层模块，负责基本的原子操作。假如修改类A，将会给程序带来不必要的风险。而遵循依赖倒置原则的程序设计可以解决这一问题。

原文链接：http://tianweili.github.io/blog/2015/02/07/dependence-inversion-principle/

什么是依赖倒置原则

英文缩写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.

翻译过来就三层含义：

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
• 抽象不应该依赖细节；
• 细节应该依赖抽象。
@H_502_25@

抽象：即抽象类或接口，两者是不能够实例化的。

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

现在我们来通过实例还原开篇问题的场景，以便更好的来理解。下面代码描述了一个简单的场景，Jim作为人有吃的方法，苹果有取得自己名字的方法，然后实现Jim去吃苹果。

代码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

//具体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等各种水果，都只需要增加自己的实现类就可以了。由于遵循依赖倒置原则，只依赖于抽象，而不依赖于细节，所以增加类无需修改其他类。

代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

//人接口 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); } }

运行结果：


1
2

Jim eat apple Jim eat banana

• People类是复杂的业务逻辑，属于高层模块，而Fruit是原子模块，属于低层模块。People依赖于抽象的Fruit接口，这就做到了：高层模块不应该依赖低层模块，两者都应该依赖于抽象（抽象类或接口）。
• People和Fruit接口与各自的实现类没有关系，增加实现类不会影响接口，这就做到了：抽象（抽象类或接口）不应该依赖于细节（具体实现类）。
• Jim、Apple、Banana实现类都要去实现各自的接口所定义的抽象方法，所以是依赖于接口的。这就做到了：细节（具体实现类）应该依赖抽象。
@H_502_25@

什么是倒置

到了这里，我们对依赖倒置原则的“依赖”就很好理解了，但是什么是“倒置”呢。是这样子的，刚开始按照正常人的一般思维方式，我想吃香蕉就是吃香蕉，想吃苹果就吃苹果，编程也是这样，都是按照面向实现的思维方式来设计。而现在要倒置思维，提取公共的抽象，面向接口（抽象类）编程。不再依赖于具体实现了，而是依赖于接口或抽象类，这就是依赖的思维方式“倒置”了。

依赖的三种实现方式

对象的依赖关系有三种方式来传递：

接口方法中声明依赖对象。

就是我们上面代码所展示的那样。

构造方法传递依赖对象。

在构造函数中的需要传递的参数是抽象类或接口的方式实现。代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

//具体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模块开发完成后自己才能开发，否则编译都无法通过，这就是单线程的开发。为了能够两人并行开发，设计时遵循依赖倒置原则，提取抽象，就可以大大提高开发进度。

总结

说到底，依赖倒置原则的核心就是面向接口编程的思想，尽量对每个实现类都提取抽象和公共接口形成接口或抽象类，依赖于抽象而不要依赖于具体实现。依赖倒置原则的本质其实就是通过抽象（抽象类或接口）使各个类或模块的实现彼此独立，不相互影响，实现模块间的松耦合。但是这个原则也是6个设计原则中最难以实现的了，如果没有实现这个原则，那么也就意味着开闭原则（对扩展开放，对修改关闭）也无法实现。

---

作者：李天炜

原文链接：http://tianweili.github.io/blog/2015/02/07/dependence-inversion-principle/

转载请注明作者及出处，谢谢。