在讲接口隔离原则之前，先明确一下接口，这里据说的接口分为两种： １. 实例接口（Object Interface),就是声明一个类，然后用 new 关键字产生一个实例，它是对一个类型事物的描述，这是一种接口。
2. 类接口（Classs Interface) ，就是指用 Interface 关键字定义的接口。
接口隔离包含两层意思：
1.客户端不应该依赖于它不需要的接口
2.类间的依赖关系应该建立在最小的接口上。
针对1就是指客户端应该依赖于它需要的接口，通俗地说就是： 客户端需要什么接口就提供什么接口，把不需要的接口删除掉，那就要对接口进行细化，保证其简洁性。
针对2，指的是它标示是最小的接口，也是要求接口细化，和第一层的意思相同。
可以把这两个定义概括成一句话： 建立单一接口，不要建立臃肿庞大的接口，再通俗一点就是：接口尽量细化，同时接口中的方法尽量少。
接口隔离原则与单一职责原则是不同的，因为两者的审视角度是不同的。单一职责要求的是类和接口的职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少，提供给每个模块的都应该是单一接口。
根据接口隔离原则拆分接口时，首先必须满足单一职责原则。 接口设计原则： 1.接口要高内聚 高内聚就是提高接口、类、模块的处理能力，减少对外的交互。
2. 定制服务
一个系统或系统骨的模块之间必然会有耦合，有耦合就要有相互的接口（不一定是定义的 Interface ，也可能是一个类或单纯的数据交换），我们在设计时就需要为各个 访问者（即客户端）定制服务，定制服务已经单独为一个个体提供优良的服务。采用定制服务就必然有一个要求：只提供访问者需要的方法。
3.接口设计是有限度的
接口设计的粒度越小，系统越灵活，月平均不争的事实。但是，的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目 或产品所期望看到的，所以接口设计一定要注意适度，这个度如何来判断呢？根据经验和常识判断，没有一个固化或可测量的标准。
最佳实践： 接口隔离原则紧接口的定义，同时也是对类的定义。接口和类尽量使用原子接口或原子类来组装。但是，这个原子该 怎么划分是设计模式中的一大难题，在实战中根据以下几个规则来衡量：
1. 一个接口只服务于一个模块或业务逻辑
2. 通过业务逻辑压缩接口上的 public 方法，接口时常去回顾，尽量让接口达到 “满身筋骨肉”，而不是‘肥嘟嘟“的一大堆方法
3. 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器的模式时行转化处理。
4.了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同，深入了解业务逻辑。
接口隔离原则和其它设计原则一样，都需要花费较多的时间和精力来进行设计和筹划，但是它带来了设计的灵活性，如果接口太大，灵活性降低，无法提供定定制服务，给整体项目带来无法预料的风险。