《敏捷软件开发》— 设计原则（三）

一、依赖倒置原则

高层模块不应该依赖于底层模块，二者都应该依赖于抽象。
抽象不应该依赖于细节。细节应该依赖于抽象。

这里有个很有趣的问题：为什么是倒置呢？在经典的层次结构中，我们会把系统设置为三层模式：表示层，服务层，持久化层。其中，表示层依赖于服务层，服务层依赖于持久化层。一个设计良好的面向对象程序，其依赖程序结构相对于传统的过程式方法设计的通常结构而言就是被倒置了。

不难发现，原始的依赖关系是紧耦合的。本应该是高层的策略设置影响低层的实现细节。然而，现在是低层模块的改动将导致高层模块的改动和重新编译。这显然是错误的依赖关系。

1、层次化

为了实现层次化，我们通常会在高层次为其所需要的服务提供一个抽象接口，低层次负责实现这些接口。高层次的接口实例的初始化一般发生在配置类或框架中，这也称为依赖注入（DI）。这样，高层就不需要依赖于低层，反而是低层次需要依赖于高层中声明的抽象服务接口。这样就很好的解耦了不同层次的依赖关系：

（1）接口所有权的倒置

上述关系不仅仅是依赖关系的倒置，也是接口所有权的倒置。在 DIP 的应用场景中，往往是客户拥有抽象接口，而它们的服务者则从这些抽象接口派生。

（2）依赖于抽象

依赖于抽象这条启发式规则可以帮助我们在开发中满足 DIP 原则。根据这条规则，我们可以推出：

• 任何变量都不应该吃有一个指向具体类的指针或者引用
• 任何类都不应该从具体类派生
• 任何方法都不应该覆写它的任何基类中的已经实现了的方法

这几个推论太过绝对化。大部分情况下，我们还是要结合具体问题具体分析，使用不同的模式解决依赖的问题。

二、接口隔离原则（ISP）

不应该强迫客户依赖于它们不用的方法

这个原则用来处理胖接口所具有的缺点。如果类的接口不是内聚的，就表示该类具有胖的接口。换句话说，类的胖接口可以分解成多组方法。每一组方法都服务于以组不同的客户程序。不难发现，这样的胖接口同时也违反了单一职责原则。

1、接口污染

考虑安全系统中的门接口，其支持加锁（lock）、解锁（unlock）和是否打开（isDoorOpen）的查询功能:

如果我们要增加一个定时门的接口，我们可以借助实现了观察者模式的 Timer 类：

最直观的想法就是使 Door 接口继承于 TimerClient。这样我们可以通过继承 Door 接口直接进行定时门的实现：

不难发现，在 Door 的接口中继承 TimerClient 只是为了给其子类增加便利，而对其本身并无作用。因此，这就是对接口的污染。

2、分离客户与分离接口

在我们开发时，往往是考虑接口改变了，客户端会怎样变化。然而由于接口属于客户，因此，需求的变化也会直接导致接口改变。然而，如果我们要在上述结构中修改接口，将导致 Door 的不必要修改于重新编译，这显然是不合理的。

3、满足 ISP

我们可以通过委托（代理模式或适配器模式）解决上述问题：

我们也可以通过多继承的方式组合接口。