《设计模式之禅》第二版 学习之六大设计原则（二）

昨天学习了六个设计原则中的单一职责原则和里氏替换原则，今天继续学习依赖倒置原则和接口隔离原则，因为都是一些偏理论的东西，虽说理解，但在使用中还是会比较吃力，建议没事的时候多回过头来看几遍，孰能生巧，用起来也会得心应手。

依赖倒置原则

依赖倒置原则（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.翻译过来，包含三层含义：

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

高层模块和低层模块容易理解，每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。
那什么是抽象？什么又是细节呢？在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。依赖倒置原则在Java语言中的表现就是：

模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；

接口或抽象类不依赖于实现类；

实现类依赖接口或抽象类。
更加精简的定义就是“面向接口编程”——OOD（Object-Oriented Design，面向对象设
计）的精髓之一。

我们通过一个例子来说明。现在的汽车越来越便宜了，一个卫生间的造价就可以买到一辆不错的汽车，有汽车就必然有人来驾驶，司机驾驶奔驰车的类图如图3-1所示。

奔驰车可以提供一个方法run，代表车辆运行，实现过程如代码清单3-1所示。

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

司机通过调用奔驰车的run方法开动奔驰车，其源代码如下所示。

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

有车，有司机，在Client场景类产生相应的对象，其源代码如下所示。

public class Client {  public static void main(String[] args) {   Driver zhangSan = new Driver();   Benz benz = new Benz();   zhangSan.drive(benz); //张三开奔驰车  }}

通过以上的代码，完成了司机开动奔驰车的场景，到目前为止，这个司机开奔驰车的项目没有任何问题。但是业务需求变更永无休止，技术前进就永无止境，在发生变更时才能发觉我们的设计或程序是否是松耦合。我们在一段貌似磐石的程序上加上一块小石头：张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？麻烦出来了，那好，我们走一步是一步，我们先把宝马车产生出来。

public class BMW {//宝马车当然也可以开动了  public void run(){   System.out.println("宝马汽车开始运行...");  }}

宝马车也产生了，但是我们却没有办法让张三开动起来，为什么？张三没有开动宝马车的方法！这就是我们的设计出现了问题，司机类和奔驰车类之间是紧耦合的关系，其导致的结果就是系统的可维护性大大降低，可读性降低，两个相似的类需要阅读两个文件，你乐意吗？还有稳定性，什么是稳定性？固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。被依赖者的变更竟然让依赖者来承担修改的成本，这样的依赖关系谁肯承担！

设计是否具备稳定性，只要适当地“松松土”，观察“设计的蓝图”是否还可以茁壮地成长就可以得出结论，稳定性较高的设计，在周围环境频繁变化的时候，依然可以做到“我自岿然不动”。

根据以上证明，如果不使用依赖倒置原则就会加重类间的耦合性，降低系统的稳定性，
增加并行开发引起的风险，降低代码的可读性和可维护性。承接上面的例子，引入依赖倒置
原则后的类图如图3-2所示。

建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽
车，必须实现drive()方法，其实现过程如代码所示。

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

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

在IDriver中，通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入了ICar接口，至于到底是哪个型号的Car，需要在高层模块中声明。

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("宝马汽车开始运行..."); }}

在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此在高层次的模块中应用都是抽象。

public class Client { public static void main(String[] args) {  IDriver zhangSan = new Driver();  ICar benz = new Benz();  //张三开奔驰车  zhangSan.drive(benz); }}

Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，zhangSan的表面类型是IDriver，Benz的表面类型是ICar，也许你要问，在这个高层模块中也调用到了低层模块，比如new Driver()和new Benz()等，如何解释？确实如此，zhangSan的表面类型是IDriver，是一个接口，是抽象的、非实体化的，在其后的所有操作中，zhangSan都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。当然，张三如果要开宝马车，也很容易，我们只要修改业务场景类就可以，

public class Client { public static void main(String[] args) {   IDriver zhangSan = new Driver();   ICar bmw = new BMW();   //张三开奔驰车   zhangSan.drive(bmw); }}

在新增加低层模块时，只修改了业务场景类，也就是高层模块对其他低层模块如Driver类不需要做任何修改，业务就可以运行，把“变更”引起的风险扩散降到最低。
在Java中，只要定义变量就必然要有类型，一个变量可以有两种类型：表面类型和实际类型，表面类型是在定义的时候赋予的类型，实际类型是对象的类型，如zhangSan的表面类型是IDriver，实际类型是Driver。
对象的依赖关系有三种方式来传递，如下所示。
1. 构造函数传递依赖对象
在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫做构造函数注
入。

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(); }}

2.Setter方法传递依赖对象
在抽象中设置Setter方法声明依赖关系，依照依赖注入的说法，这是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(); }}

3.接口声明依赖对象
在接口的方法中声明依赖对象，上面奔驰，宝马的例子就采用了接口声明依赖的方式，该方法也叫做接口注入。

依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以:
每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
● 变量的表面类型尽量是接口或者是抽象类
● 任何类都不应该从具体类派生
● 尽量不要覆写基类的方法
● 结合里氏替换原则使用

接口隔离原则

在讲接口隔离原则之前，先明确一下我们的主角——接口。接口分为两种：
● 实例接口（Object Interface），在Java中声明一个类，然后用new关键字产生一个实例，它是对一个类型的事物的描述，这是一种接口。比如你定义Person这个类，然后使用Person zhangSan=new Person()产生了一个实例，这个实例要遵从的标准就是Person这个类，Person类就是zhangSan的接口。疑惑？看不懂？不要紧，那是因为让Java语言浸染的时间太长了，只要知道从这个角度来看，Java中的类也是一种接口。
● 类接口（Class Interface），Java中经常使用的interface关键字定义的接口。
主角已经定义清楚了，那什么是隔离呢？它有两种定义，如下所示：

• Clients should not be forced to depend upon interfaces that they don’t use.（客户端不应该依赖它不需要的接口。）
• The dependency of one class to another one should depend on the smallest possible interface.（类间的依赖关系应该建立在最小的接口上。）
  我们把这两个定义剖析一下，先说第一种定义：“客户端不应该依赖它不需要的接口”，那依赖什么？依赖它需要的接口，客户端需要什么接口就提供什么接口，把不需要的接口剔除掉，那就需要对接口进行细化，保证其纯洁性；再看第二种定义：“类间的依赖关系应该建立在最小的接口上”，它要求是最小的接口，也是要求接口细化，接口纯洁，与第一个定义如出一辙，只是一个事物的两种不同描述。
  我们可以把这两个定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。
  这与单一职责原则不是相同的吗？错，接口隔离原则与单一职责的审视角度是不相同的，单一职
  责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要
  求接口的方法尽量少。

接口隔离原则是对接口进行规范约束，其包含以下4层含义：
● 接口要尽量小

这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度
的，首先就是不能违反单一职责原则，并且根据接口隔离原则拆分接口时，首先必须满足单一职责原则。
● 接口要高内聚
高内聚就是提高接口、类、模块的处理能力，减少对外的交互。
● 定制服务
一个系统或系统内的模块之间必然会有耦合，有耦合就要有相互访问的接口（并不一定就是Java中定义的Interface，也可能是一个类或单纯的数据交换），我们设计时就需要为各个访问者（即客户端）定制服务，什么是定制服务？定制服务就是单独为一个个调用者供最合适的接口。减少接口中的无用方法。
● 接口设计是有限度的
接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构
的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口
设计一定要注意适度，这个“度”如何来判断呢？根据经验和常识判断，没有一个固化或可测
量的标准。

---

接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。但是，这个原子该怎么划分是设计模式中的一大难题，在实践中可以根据以下几个规则来衡量：
● 一个接口只服务于一个子模块或业务逻辑；
● 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；
● 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理；
● 了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的你就照抄。千万别，环境不同，接口拆分的标准就不同。深入了解业务逻辑，最好的接口设计就出自你的手中！