定义
先来明确一下接口的概念，这里分为两种接口
1、实例接口
实例化一个类对象后，对应的类就是关于这个对象的接口
2、类接口
Java中利用interface关键字定义的接口
接口隔离原则（ISP， Interface Segregation Principle）有两层定义
1、Clients should not be forced to depend upon interface that they don’t use.（客户端不应该依赖它不需要的接口）
2、The dependency of one class to another one should depend on the smallest possible interface.（类间依赖应尽可能的建立在最小的接口上）
简单理解为：接口中的方法尽量少，能细化则细化。
注意这里和SRP是不一样的，他们的度量角度不同，一个是业务角度；一个是方法数量的角度。
示例
秦小波老师在这里举了“美女”的例子来说明这么一个原则。
美女的标准是什么？面容姣好、魔鬼身材、气质出众？三者都要了！
那可能会有一个接口包含三个方法，如下：
interface IBeauty{
//好面容
public void goodLooking();
//好身材
public void niceFigure();
//好气质
public void greatTemperament();
}
那问题来了，每个人判断美女的标准是不一样的。可能有的人面容一般、身材一般，但气质出众，这也能被称之为美女呢。假设我们还有星探类。那在代码中又如何实现呢？接口已经限定美女的判断维度了，再写个美女类对接口对应方法进行重写？那好像也不太好，这是不是会影响星探类的代码呢？
我们发现，在上述例子中，美女的判断维度分为了两层，一个内在（气质），一个是外在（面容、身材）。那我们是不是可以针对这两层维度进行一个接口细分设计呢？就比如说我们现在将原有的接口拆分为两个接口：一个提供身材和容貌的判断，一个提供气质的判断。
interface IFitBody{
//好面容
public void goodLooking();
//好身材
public void niceFigure();
}
interface ITemperament{
//好气质
public void greatTemperament();
}
这样在进行不同标准进行判断类实现时就可以按需实现不同的接口了。
思考
其实这里涉及到一个问题。为什么不将这里的外在接口进一步细化为面容判断、身材判断两个粒度更小的接口呢？这样对于后期的扩展性不是会更好吗？首先我们要知道接口隔离的前提是基于单一职责，同时我们要知道接口的细化是要根据实际业务需求去进行粒度把握的，如果无限度的考虑后期的扩展性，导致接口数量的暴涨，对于项目的开发也是灾难！
接口隔离也就是保证接口的纯洁性，有如下几条可行原则。
1、接口要尽可能的小
过于复杂的接口会带来臃肿的设计，而定义粒度过小又会导致接口数量的不必要增加，进而增大了项目开发的难度。那怎么做呢？注意在进行接口细分时，首先必须要遵循单一职责原则。如此可以更好的把握接口拆分的粒度。
2、接口要高内聚
提高接口、类、模块的处理能力，减少对外的交互。也就是对于接口使用者来说，并不需要关注接口下对应的具体实现。在此情况下，需要尽量减少对外开放（public），接口是对外开放的承诺；就像是前面说的契约。对外开放的方法越多意味着要给用户做更多的承诺，带来的变更风险就会越大。
3、定制服务
针对不同权限的用户尽量分别定制接口，不要混用。就比如说在web运用中，后台管理员查询书籍信息的接口以及公网用户查询书籍信息接口是需要分开的，尤其在高并发查询的情况下，分别定制接口可以避免公网流量影响到内部的正常运作。
4、接口设计是有限度的
这个原则和第一条可以说是交相呼应。接口的设计粒度越小，系统也就越灵活。而这也无疑增大了系统的复杂度，增加了开发维护的成本。如何把握接口设计的纯洁性与系统复杂度之间的平衡需要在实践中进行探索，根据实际的情况综合考虑。
最佳实践
1、一个接口只服务于一个子模块或业务逻辑
2、注意public方法数量的限制；提供了太多对外的公共服务并非好事
3、已被污染的接口尽量去修改，若变更风险太大可采用适配器模式进行转换处理
4、根据自己实际的业务场景灵活设计自己的模式结构，拒绝照搬盲从。
参考文献
秦小波《设计模式之禅 》第二版
