《敏捷软件开发-原则、模式与实践》-第十二章 接口隔离原则（ISP）

    如果类的接口不是内聚的，则这个接口是“胖”接口，它可以分解成多组方法。乍一看这个概念，让我有点摸不着头脑，所以接着看后面的内容。
    首先，我们了解什么叫“接口污染”。举个栗子：有几个类：door（接口）,timeDoor,Timer,TimerClient。当我们需要一个可以定时功能的timeDoor时，我们需要将timeDoor注册到timer中去（public void register(int timeout,TimerClient client)），并通过timerClient实现timeout()。那么我们很容易想到，可以令timeDoor去实现timerClient接口，这样就能将timedoor作为参数传入到register函数中，从而实现定时功能。这样我们就完美的完成了一个接口污染。当我们为了一个子类的功能而在接口中去添加方法时，这就是对接口的污染。试想如果这么添加，那么我们其他的实现类也要去实现这个根本不需要的方法，这就造成了子类中方法的退化，也就是我们上一章所说的违反了LSP。

    接着，作者给出了ISP的概念：不应该强迫客户以利于它们不用的方法。在上述问题中，在java中其实很好解决，我们的timeDoor类应该同时实现door和timerClient接口就可以了（在C++中使用多重继承）。其实按照我们一般开发者的思维都是去同时实现这两个接口，没睡吃饱了没事又让door去实现timerClient接口吧。但是此处举得例子还是很好的让我们理解了什么是接口污染。
    结论：胖类会导致它们的客户程序之间产生不正常的并且有害的耦合关系。当一个客户程序要求该胖类进行一个改动时，会影响到其他所有的客户程序。因此，客户程序应该仅仅依赖于他们实际调用的方法。通过把胖类的接口分解成多个特定于客户程序的几口，可以实现这个目标。每个特定于客户程序的接口仅仅声明它的特定客户或者客户组调用的那些函数。接着，该胖类就可以继承所有特定于客户程序的接口，并实现他们。这就解除了客户程序和它们没有调用的方法间的依赖关系，并使客户程序之间互不依赖。