英文名称：貌似没有好的翻译
中文名称：接口隔离原则
作 用：仔细分析业务流程，划分合适的粒度，为系统的灵活性以及可维护性有较大的提高，避免肥嘟嘟的接口类，避免臃肿庞大，一般如
果接口封装过头，就会将一些可变因素封装进去，这种封装过度了会导致今后的维护度大大增加。
真 言：
1、客户端不应该依赖于它不需要的接口
2、类的依赖关系应该建立在最小的接口上
3、接口要尽量小，在拆分接口时，首先必须要满足单一职责原则
4、接口要高内聚，要尽量减少与外面的交互
5、粒度的划分要根据实际业务需求，不宜过小，也不宜过大
深刻理解：看了这个接口隔离原则，心中很是难过，原来现在的系统设计接口设计的是多么的臃肿，是多么的经受不起未来需求的调整，在
接口的设计中，一定要遵循一个轻装上阵，用毛泽东的游记战术，化整为0的思想来指导接口的设计与划分。
理论实践：
先用一个星探找美女的案例来说明问题，对于美女的标准可以定义为：身材好，脸蛋漂亮，有气质，星探则根据这种情况去寻找美女，如是便有了如下的设计，上UML图如下：
这种设计的结果就是必须要满足身材好，脸蛋漂亮，有气质的才能够成为美女，但是很多情况下，非常有气质的大家看来也是美女，身材好，脸蛋漂亮，气质稍微差点的也算是美女，那么这个类明显就不满足需求了，将众多的接口信息放入一起，不仅仅造成的是臃肿，而且还是逻辑上的错误，如果再来一个以胖为美的美女，那么这个类就无法处理了，因为和身材好完全是互相冲突的，这种情况采用接口分离原则，经过分析将接口分成如下图所示：很明显，这种方式很容易扩充，无论是气质型美女，胖嘟嘟类型的美女，星探可以根据各种人的口味来寻找各种类型的美女，兄弟们这下有福气了，哈哈！,其实我个人欣赏的美女标准为：腿一定要细长，皮肤要白，脸要可爱型，脾气要温顺点的，我估计星探得气死，为什么，因为他根本就不知道怎么去找，没有接口啊，如果采用下图的方式，一点问题没有，重新加一个IloveBeautyGirl,将腿细长，皮肤嫩白，脸型可爱，脾气温顺作为标准，一切解决！
我不有自主的就联想到我系统现在的设计模式，我很不好意思将现在系统这种蹩脚的设计模式拿出来献丑，但是为了加深印象，决定把蹩脚设计拿出来，设计如下：这个模块主要是负责列表的加载，查询条件的加载，查询历史记录的加载。知道吗？我这个可继承的类肚吞天下，处理了图像的加载，处理了首页的加载，处理了复杂多层数据列表以及单层的数据列表，全部用一个类来解决，所以导致每增加一个类，都必须要增加一个特殊的方法，不可想像，如果我现在要在一个页面中增加图形+数据的显示，我这个类我该如何设计啊，这么继续增加下去，我估计我会彻底的崩溃。
经过到现在为止领悟的四招设计模式：第一招，单一职责原则，第二招，里氏替换原则，第三招，依赖倒置原则，再加上这招，接口隔离原则，处理完毕，上图如下，有了这种设计结构，不仅仅减轻了现在的重复代码，而且还增强了可扩充性，没有必要实现的方法我就不用再实现了，看起来舒服，写代码写起来也舒服，何乐而不为？
这个接口的定义绝对的是没有固定的标准，决定没有一成不变的规律，而是需要看你对相关项目业务的熟悉程度，如何划分企业粒度，这个接口的定义可能会一直处理不断的改进中，有时候你觉得这个设计模式差不多了，可是等新的需求一出来，你就又要重新设计，所以这个设计过程在整个开发过程中所占的重要性非常之高，一定要坚持先设计后开发，否则给后期带来的工程量那是无法估计的！在公司，项目经理一定要顶住老大们的压力啊，那些老大不会看你设计的图稿，唯一会看的，就是你每天的进度如何？他们看进度的唯一方式就是看系统的功能怎么样了，项目经理一定要灵活抉择~~~
