参考书籍：设计模式之禅--秦小波
上篇回顾：上篇讲到了依赖倒置原则(DIP),讲的不好还请见谅。上篇文末留下了一个问题：“抽象不能依据具体，这样的说法会在哪些例子里被反驳呢？”对待这个问题我们先回顾下，为什么说抽象不能依赖具体？抽象即我们说的接口，具体即我们说的实体类，博主爱祖国的大好河山，所以就以山为例，我们先抽象出“山”，再看，黄山有松，庐山有雾，昆仑山有雪，这些具体的山拥有的特性并不是每座山都具有的通性，所以接口山并不能依据某一座具体的山的特点来设计，所以说抽象不能依赖具体。但同时抽象又来自于具体，归根结底，山的特性是从所有具体山里提取的。还记得“鸵鸟不是鸟”吗？当我们说鸟会飞的时候，就要结合具体情况具体分析，因为并不是所有的鸟都会飞。大家可能会说，这怎么办呢？如果接口提取出来后，随着应用范围的扩大，发现并不具有普适性，一些特例开始出现，奈若何？这个时候接口隔离原则就发挥作用了。
接口隔离原则：
定义：接口隔离原则(ISP)，英文全称：Interface Segregation Principle。如何理解该原则呢？只要把“隔离”这个词说明白了，这个原则就豁然开朗了。首先看看他拗口的定义：
- Clients should not be forced to depend upon interfaces that they don't use.
- The dependency of one class to another one should depend on the smallest possible interface.
简单的说就是：把接口功能尽量细分，尽量让接口变得单纯且简洁，需要什么接口就继承什么接口，并且去继承最原子，最小的接口。大家会觉得这个道理很明显啊，不需要的接口我怎么会用呢？确实如此，难点在，如何细分接口来让他变得单纯。
下面我们举个例子看看ISP的运用。以楼主的毕业设计“大学科研成果管理系统”为例，学生上传科研成果，老师对科研成果统一管理，老师除了具有基本的增删改查的权限外，还需审批学生上传的科研成果是否符合规范，是否合法：
interface IManage(){
boolean delete(){}
boolean add(){}
boolean approve(){} //审批
......
}后来随着业务的扩展，任务量的增加，审批的流程被提出来交给专门的管理员处理,审批管理员只负责审核科研项目，并不具备其他的权限，尤其是增删这些危险操作权限。这时如果让审批管理员也继承IManage接口，那么除了审批相关的以外的方法都成了摆设，没必要实现，这种浪费显然是不合理的。怎么办？我们意识到IManage的职责需要被细分！虽然这些操作都是管理方面的操作，符合SRP原则，但是这些操作太过臃肿，那么拆分：
interface IApproval{
boolean aprove(){}//审批
......
}这样，审批管理员继承IApproval,就实现了功能的独立。从这里我们可以看出来，接口隔离原则和单一职责原则好像有些关系，是的！他们都是为了让职责细分，从而让程序具有扩展性，面对业务的扩展，最小最自由的扩展代码。同时他们又有区别，单一职责原则着眼于业务层面的职责的划分，也就是一类的职责都可以放在一起。而接口隔离原则是针对接口的具体使用，它致力于将可能出现差别的方法再次进行隔离，从而保证代码的扩展性。
现在我们来说下接口“隔离”的含义：尽量将接口的功能细分成最小元。这个最小的标准是什么？拆分到多详细才是合理的？答案是，没有标准！完全根据业务的需要和经验的积累，保持接口隔离的意识即可。接口过于细小，反而增加了系统的复杂性，只有多花些时间去思考和筹划，才能准确地实践这一原则。
建议：如何衡量接口的原子性，下面给出秦小波给出的几点建议：
- 一个接口只服务于一个子模块或业务逻辑；
- 通过业务逻辑压缩接口中的public方法，接口时常去回顾，不断让方法变得精炼。
- 如果发现接口需要拆分，那么尽量去拆分，如果拆分代价太大，就采用适配器的方式做中转。
- 不必完全按照别的的划分方式，根据自己的业务逻辑来，只要心中有原则，你的设计就是最优秀的设计。
- 多重继承分离，通过接口多继承来实现客户端需求。
最后，每篇一问：
我们知道接口隔离原则和单一职责原则具有关联性，立足的角度却有不同。如果接口隔离原则和单一职责原则发生了冲突，鱼和熊掌如何取舍？