设计模式六大原则（一）-- 接口隔离原则（ISP）

设计图和源代码请访问我的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.了解自己的现状和面临的问题，不要盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的你就照抄。环境不同，接口拆分的标准就不同。深入了解业务逻辑，针对特定场景设计的接口才是最适合的。

写完这六大原则之后，每一个原则都会举一个具体的例子对应着来解释