关于接口隔离（ISP）

    接口隔离原则（Interface Segregation Priciple，ISP），简单说来就一句话，即不能强迫客户依赖于和他无关的接口。从本质上来讲，ISP就是隔离变化的波及范围。如果变化波及到了本身并不使用这些变化者功能的地方，这本身就是非常可怕的。对于修改和新增功能无法预测，对于大型项目来说是一场灾难。

     在《敏捷软件开发：原则、模式与实践》中提到，“胖类会导致它们的客户程序之间产生不正常的并且有害的耦合关系。当一个程序客户要求该胖类进行一个改动时，会影响到所有其它的客户程序。因此，客户程序应该仅仅依赖于它们实际调用的方法。通过把胖类的接口分解为多个特定于客户程序的接口，可以实现这个目标。每个特定于客户程序的接口仅仅声明 它的特定客户或者客户组调用的那些函数。接着，该胖类就可以继承所有特定于客户程序的接口，并实现它们。这就解除了客户程序和它们没有调用的方法间的依赖关系，并使客户程序之间互不依赖。“这已经对于ISP如何实现给出了指导性的意见。

     从上述描述来说，我们要清晰的看出，客户程序和接口之间，就像牛顿第三运动定律，存在作用力和反作用力。一方面，接口决定了客户如何使用，另一方面，客户程序又对接口产生影响。在确定两者关系时，一般初始条件下，要优先从客户程序出发来设计接口，这也是DIP原则的要点之一。

     ISP又和OCP，LSP，SRP密切相关（当然，所有的敏捷设计原则之间都是相互关联的）。

     ISP的接口隔离，需要基于SRP原则进行分组处理，即常常需要根据客户所使用的服务来对客户进行分组，这样的优势在于，不必为每个客户创建一套接口，从而避免了大量服务接口的存在，也避免了让服务依赖于每个客户。如果多个客户组调用的服务有重叠， 如果重叠较少，建议接口分离。公有函数应在所有重叠的接口中进行声明，然后在服务者类中继承这些接口，但只实现一次。

      不要企图使用一个统一的类来包装各个分离的接口，避免造成对统一类的大范围依赖，使得修改或者添加某一特定接口，都波及到无关客户程序。

      面对变化的时候，应该扩展接口，而不是修改现有接口。这也是OCP的基本原则，即对扩展是开放的，对修改是封闭的。

      实现ISP，有两种基本方法，一为使用委托分离接口，一为使用多重继承分离接口。一般来说，优先使用多重继承。但如果确实需要进行两个接口之间的转换，使用委托也是可行的。