接口隔离原则(ISP)
设计应用程序的时候，如果一个模块包含多个子模块，那么我们应该小心对模块做出抽象。设想该模块由一个类实现，我们可以把系统抽象成一个接口。但是要添加一个新的模块扩展程序时，如果要添加的模块只包含原系统中的一些子模块，那么系统就会强迫我们实现接口中的所有方法，并且清寒要编写一些哑方法。这样的接口被称为肚胖接口或者被污染的接口，使用这样的接口将会给系统引入一些不当的行为，这些不当的行为可能导致不正确的结果，也可能导入资源浪费。
1.接口隔离
接口隔离原则（Interface Segregation Principle, ISP）表明客户端不应该被强迫实现一些他们不会使用的接口，应该把胖接口中的方法分组，然后用多个接口替代它，每个接口服务于一个子模块。简单地说，就是使用多个专门的接口比使用单个接口要好很多。
ISP 的主要观点如下：
1）一个类对另外一个类的依赖性应当是建立在最小的接口上的。
ISP 可以达到不强迫客户（接口的使用方法）依赖于他们不用的方法，接口的实现类应该只呈现为单一职责的角色（遵循 SRP 原则） ISP 还可以降低客户之间的相互影响---当某个客户要求提供新的职责（需要变化）而迫使接口发生改变时，影响到其他客户程序的可能性最小。
2）客户端程序不应该依赖它不需要的接口方法（功能）。
客户端程序就应该依赖于它不需要的接口方法（功能），那依赖于什么？依赖它所需要的接口。客户端需要什么接口就是提供什么接口，把不需要的接口剔除，这就要求对接口进行细化，保证其纯洁性。
比如在继承时，由于子类将继承父类中的所有可用方法；而父类中的某些方法，在子类中可能并不需要。例如，普通员工和经理都继承自雇员这个接口，员工需要每天写工作日志，而经理不需要。因此不能用工作日志来卡经理，也就是经理不应该依赖于提交工作日志这个方法。
可以看出，ISP和SRP在概念上是有一定交叉的。事实上，很多设计模式在概念上都有交叉，甚至你很难判断一段代码属于哪一种设计模式。
ISP强调的是接口对客户端的承诺越少越好，并且要做到专一。当某个客户程序的要求发生变化，而迫使接口发生改变时，影响到其他客户程序的可能性小。这实际上就是接口污染的问题。
2.对接口的污染
过于臃肿的接口设计是对接口的污染。所谓的接口污染就是为接口添加不必要的职责，如果开发人员在接口中增加一个新功能的目的只是减少接口实现类的数目，则此设计将导致接口被不断地“污染”并“变胖”。
“接口隔离”其实就是定制化服务设计的原则。使用接口的多重继承实现对不同的接口的组合，从而对外提供组合功能---达到“按需提供服务”。 接口即要拆，但也不能拆得太细，这就得有个标准，这就是高内聚。接口应该具备一些基本的功能，能独一完成一个基本的任务。
在实际应用中，会遇到如下问题：比如，我需要一个能适配多种类型数据库的 DAO 实现，那么首先应实现一个数据库操作的接口，其中规定一些数据库操作的基本方法，比如连接数据库、增删改查、关闭数据库等。这是一个最少功能的接口。对于一些 MySQL 中特有的而其他数据库里并不存在的或性质不同的方法，如 PHP 里可能用到的 MySQL 的 pconnect 方法，其他数据库里并不存在和这个方法相同的概念，这个方法也就不应该出现在这个基本的接口里，那这个基本的接口应该有哪些基本的方法呢？PDO已经告诉你了。
PDO 是一个抽象的数据库接口层，它告诉我们一个基本的数据库操作接口应该实现哪些基本的方法。接口是一个高层次的抽象，所以接口里的方法都应该是通用的、基本的、不易变化的。
还有一个问题，那些特有的方法应该怎么实现？根据ISP原则，这些方法可以在别一个接口中存在，让这个“异类”同时实现这两个接口。
对于接口的污染，可以考虑这两条处理方式：
- 利用委托分离接口。
- 利用多继承分离接口。
委托模式中，有两个对象参与处理同一个请求，接受请求的对象将请求委托给另一个对象来处理，如策略模式、代理模式等中都应用到了委托的概念。
