设计图和源代码请访问作者的github：https://github.com/yangsheng20080808/DesignModel
From Now On，Let us begin Design Patterns。
接口隔离原则 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.
我们可以把这两个定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。
提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。
接口是我们设计时对外提供的契约，通过分散定义多个接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。（下一篇文章举例子具体说明问题）
接口隔离原则是对接口进行规范约束，其包含以下4层含义
接口要尽量小
这是接口隔离原则的核心定义，不出现臃肿的接口（FatInterface），但是“小”是有限度的，首先就是不能违反单一职责原则。（单一职责原则下一篇文章说）
接口要高内聚
什么是高内聚？高内聚就是提高接口、类、模块的处理能力，减少对外的交互。具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。
定制服务
一个系统或系统内的模块之间必然会有耦合，有耦合就要有相互访问的接口，我们设计时就需要为各个访问者（即客户端）定制服务，什么是定制服务？定制服务就是单独为一个个体提供优良的服务。采用定制服务就必然有一个要求：只提供访问者需要的方法。
接口设计是有限度的
接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低。
衡量的标准
接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。但是，这个原子该怎么划分是设计模式中的一大难题，在实践中可以根据以下几个规则来衡量：
1. 一个接口只服务于一个子模块或业务逻辑
2. 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口中的方法简单紧凑，不要放过多的方法规范，这样会造成污染。
3.已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理
4.了解自己的现状和面临的问题，不要盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的你就照抄。环境不同，接口拆分的标准就不同。深入了解业务逻辑，针对特定场景设计的接口才是最适合的。
写完这六大原则之后，每一个原则都会举一个具体的例子对应着来解释
---------------------
作者：yabay2208
来源：CSDN
原文：https://blog.csdn.net/yabay2208/article/details/73481127
版权声明：本文为博主原创文章，转载请附上博文链接！