6大设计原则之4--接口隔离原则

接口分为两种：实例接口（Object Interface）和类接口（Class Interface）

隔离也有两种定义

•     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. （类间的依赖关系应该创建在最小的接口上。）

咱们能够把这两个定义归纳为一句话：创建单一接口，不要创建臃肿庞大的接口。再通 俗一点讲：接口尽可能细化，同时接口中的方法尽可能少。看到这里你们有可能要疑惑了，这与 单一职责原则不是相同的吗？错，接口隔离原则与单一职责的审视角度是不相同的，单一职 责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要 求接口的方法尽可能少。例如一个接口的职责可能包含10个方法，这10个方法都放在一个接口 中，而且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外经过文档约 束“不使用的方法不要访问”，按照单一职责原则是容许的，按照接口隔离原则是不容许的， 由于它要求“尽可能使用多个专门的接口”。专门的接口指什么？就是指提供给每一个模块的都应 该是单一接口，提供给几个模块就应该有几个接口，而不是创建一个庞大的臃肿的接口，容 纳全部的客户端访问。

接口隔离原则是对接口进行规范约束，其包含如下4层含义： 

• 接口要尽可能小：这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），可是“小”是有限度 的，首先就是不能违反单一职责原则

• 接口要高内聚：什么是高内聚？高内聚就是提升接口、类、模块的处理能力，减小对外的交互。具体到接口隔离原则就是，要求在接口中尽可能 少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变动的风险也就越 少，同时也有利于下降成本。

• 定制服务：一个系统或系统内的模块之间必然会有耦合，有耦合就要有相互访问的接口（并不必定 就是Java中定义的Interface，也多是一个类或单纯的数据交换），咱们设计时就须要为各 个访问者（即客户端）定制服务，什么是定制服务？定制服务就是单独为一个个体提供优良 的服务。咱们在作系统设计时也须要考虑对系统之间或模块之间的接口采用定制服务。采用 定制服务就必然有一个要求：只提供访问者须要的方法，

• 接口设计是有限度的：接口的设计粒度越小，系统越灵活，这是不争的事实。可是，灵活的同时也带来告终构 的复杂化，开发难度增长，可维护性下降，这不是一个项目或产品所指望看到的，因此接口 设计必定要注意适度，这个“度”如何来判断呢？根据经验和常识判断，没有一个固化或可测 量的标准。

最佳实践

接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽可能使用原子接口或原 子类来组装。可是，这个原子该怎么划分是设计模式中的一大难题，在实践中能够根据如下 几个规则来衡量： 

• 一个接口只服务于一个子模块或业务逻辑；

• 经过业务逻辑压缩接口中的public方法，接口时常去回顾，尽可能让接口达到“满身筋骨 肉”，而不是“肥嘟嘟”的一大堆方法；

• 已经被污染了的接口，尽可能去修改，若变动的风险较大，则采用适配器模式进行转化 处理；

• 了解环境，拒绝盲从。每一个项目或产品都有特定的环境因素，别看到大师是这样作的 你就照抄。千万别，环境不一样，接口拆分的标准就不一样。深刻了解业务逻辑，最好的接口设 计就出自你的手中！