接口隔离原则
定义：
1、客户端不应该依赖它不需要的接口。
2、类间的依赖关系应该建立在最小的接口上。
概括的说：建立单一的接口，不要建立臃肿的庞大的接口。
与单一原则的区别：
单一职责要求的是类和接口单一，注重的是职责，这是业务逻辑上的划分。而接口隔离原则要求接口的方法尽量少。
举例：
一个星探找美女的过程（美女的条件：身材、容貌、气质）
这个过程的UML图
定义了一个IPettyGirl接口，声明所有的美女都应该有GoodLooking、NiceFigure和GreatTemperament，然后定义了一个抽象类AbstractSearcher,其作用就是搜索美女然后展示信息，只要美女都是按照这个标准定义。
但是我们随着时间的变化，星探的标准变化了，只要有气质。这样的话我们要改Sercher接口，还需要改PettyGirl类。这样的设计是有缺陷的，IPettyGirl设计的过于臃肿。
改进后的ＵＭＬ图
把原IPettyGirl 接口拆分成两个接口，一种是IgoodBodyGirl，一种是IGreatTemperamentGirl.我们从一个比较臃肿的接口拆分成了两个专门的接口，灵活性提高了，可维护性也增加了，不管以后需要外形美的还是有气质的都可以通过PEttyGirl轻松定义了。
通过这样的改造以后，不管以后是要气质美女还是要外形好看的，都可以保持接口的稳定。当让你可能要说了，以后可能审美观点发生改变，只有脸蛋好看的就是美女，那这个IGoodBody接口还是要修改呀，确实是，但是设计是有限度的。不能无限的考虑未来的变更情况，否则就会陷入设计的泥潭中而不能自拔。
以上把一个臃肿的接口变更成为两个独立的接口依赖的就是接口隔离原则。让AbstractSearcher依赖两个专用的接口比依赖一个综合的接口要灵活。接口是我们设计时对外提供的契约，通过分散定义多个接口，可以预防未来变更的扩展，提高系统的灵活性和可维护性。
含义：
接口尽量要小（根据接口隔离原则拆分接口时必须首先满足单一职责原则）
接口要高内聚
接口设计是有限度的
一个接口只服务于一个子模块或者业务逻辑
已经被污染的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理