敏捷软件开发 - 原则、模式与实践 —— 敏捷设计（六）接口隔离原则

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。

本文对应原书第12章。

接口隔离原则（ISP - The Interface Segregation Principle）

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

这个原则用来处理“胖”接口所具有的缺点。如果类的接口不是内聚的，就表示该类具有“胖”的接口。换句话说，类的“胖”接口可以分解成多组方法。每一组方法都服务于一组不同的客户程序。这样，一些客户程序可以使用一组成员函数，而其他客户程序可以使用其他组的成员函数。

ISP承认存在有一些对象，它们确实不需要内聚的接口；但是ISP建议客户程序不应该看到它们作为单一的类存在。相反，客户程序看到的应该是多个具有内聚接口的抽象类型。

如果强迫客户程序依赖于那些它们不适用的方法，那么这些客户程序就面临着由于这些未使用方法的改变所带来的变更。这无意中导致了所有客户程序之间的耦合。换种说法，如果一个客户程序依赖于一个含有它不使用的方法的类，但是其他客户程序却要使用该方法，那么当其他客户要求这个类改变时，就会影响到这个客户程序。我们希望尽可能地避免这种耦合，因此我们希望分离接口。

接口污染

参看原书12.1部分

实施ISP的方法

1. 使用委托分离接口
   参看原书12.4.1部分
2. 使用多重继承分离接口
   参看原书12.4.2部分

对客户进行分组

常常可以根据客户所调用的服务方法来对客户进行分组。这种分组方法使得可以为每组而不是每个客户创建分离的接口。这极大地减少了服务需要实现的接口数量，同时也避免让服务依赖每个客户类型。

有时，不同的客户组调用的方法会有重叠。如果重叠部分较少，那么组的接口应该保持分离。公用的方法应该在所有有重复的接口中声明。服务者类会从这些接口的每一个中继承公用的方法，但是只实现它们一次。

改变接口

在维护面向对象的应用程序时，常常会改变现有的类和组件的接口。通常这些改变都会造成巨大的影响，并且迫使系统的绝大部分需要重新编译和重新部署。这种影响可以通过为现有的对象增加新接口的方法来缓解，而不是去改变现有的接口。原有接口的客户如果想访问新接口中方法，可以通过对象去询问该接口。

每个原则在应用时都必须小心，不能过度使用它们。如果一个类具有数百个不同的接口，其中一些事根据客户程序分离的，另一些是根据版本分离的，那么该类就是难以琢磨的，这种难以琢磨性是非常令人恐惧的。

结论

胖类会导致它们的客户程序之间产生不正常的并且有害的耦合关系。当一个客户程序要求该胖类进行一个改动时，会影响到所有其他的客户程序。因此，客户程序应该仅仅依赖于它们实际调用的方法。通过把胖类的接口分解为多个特定于客户程序的接口，可以实现这个目标。每个特定于客户程序的接口仅仅声明它的特定客户或者客户组调用的那些函数。接着，该胖类就可以继承所有特定于客户程序的接口，并实现它们。这就解除了客户程序和它们没有调用的方法间的依赖关系，并使客户程序之间互不依赖。

完整内容请查看敏捷软件开发 - 原则、模式与实践系列