设计模式六大设计原则（四）：接口隔离原则

一、定义

有两种定义：

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

注意：这里的接口不是JAVA意义上的Interface，而是广义的程序中的不管是Class还是Interface只要存在依赖，都称之为接口。

与单一职责原则相区分，单一职责是根据业务上划分出的职责的维度进行划分的，而接口隔离原则是进一步在接口依赖关系关系上进一步划分，单一职责原则是强调我们在定义接口时考虑这个接口在整个系统提供的职责单一，而接口隔离原则强调的是根据模块依赖接口的方法范围存在不同，他们调用该接口需要隔离，如我们在单一职责原则基础之上定义接口时如果预期会被多模块调用了，且多个模块对依赖该接口的方法范围存在区别，那么需要将此接口拆分得再小一点，以复合每个模块访问的接口都是尽量小的，从而隔离各个模块。

二、优点与限制

（一）优点

• 提高可维护性 因为针对接口的修改只需要关注一个模块
• 提高设计灵活性 多接口比臃肿接口更灵活

（二）限制

• 过于追求接口隔离，单一职责将接口设计的粒度太小也会使系统结构更为复杂

三、建议

• 在业务接口中，避免接口被多个模块调用。这里和Util类区分，因为util虽然是服务于多个模块的，但是在设计上，多个模块对其的访问范围并不存在什么不同，所以没必要进一步隔离
• 根据业务逻辑压缩接口中的方法，避免因为一个预期不会改变的业务逻辑多次调用不同的public方法
• 已经被污染了的接口（被多个不同的模块调用），考虑进行修改，如不能考虑使用适配器模式

转载于:https://my.oschina.net/u/4101481/blog/3032941