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

1、定义

有两种定义：

• 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只要存在依赖，都称之为接口。

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

2、优势与限制

（一）优势

• 提升可维护性 由于针对接口的修改只须要关注一个模块
• 提升设计灵活性 多接口比臃肿接口更灵活

（二）限制

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

3、建议

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