设计原则 — I 接口隔离原则

含义

Robert Martin 是这样定义的：“Clients should not be forced to depend upon interfaces that they do not use。”

此原则较好理解，翻译一下就是客户端不应强迫依赖它不需要的接口，是从使用者的角度，提出不要把我不关心的东西告诉我。

优点

更多的是避免因依赖不需要的东西而引发的不可预知的问题。

原因：依赖的东西越多，自然会产生问题的概率会增加，那既然不需要，又何必引入制造不必要的麻烦呢？

且任何层次的软件设计如果依赖了它不需要的东西，都会带来意料之外的麻烦。

比如：

1. 不必要的重新编译和重新部署(目前 maven 管理 jar 包，若版本不升级问题倒也不大，可能更多的影响是早期系统？)

2. 导致代码运行出错(大家应该会深有体会的就是外部引入的 jar 包冲突问题)

如何做

原则为接口提供方提供了一个思路：设计接口时，站在调用方的角度来思考，如果我是调用方，需要这些功能吗？如果不需要，可以刨除。

但平常的开发中似乎无法做到完全的接口隔离。

通常接口提供方给的是大而全的一类接口，尽管某些方法调用方并不需要。更多考虑的不是接口或方法调用方是否需要使用，而是调用方是否有权限使用。

这样做的原因，似乎是对于提供方来说更为简便，而对于调用方来说依赖了无关类或方法的影响好像也不是特别大。

所以我认为这条原则对于接口提供方来说，更多的是一种警示，谨慎引入调用方不需要的功能，实践的话可以转化为：

1. 调用方无权限使用的类或方法绝不要给出去(但将接口权限和提供与否放在一起考虑是否合适也存疑)

2. 调用方不可能使用的类或方法(即内部逻辑)绝不要给出去

3. 调用方可能用到的类或方法可以考虑放入(这会稍微违反一些接口隔离原则)

不过此三条纯属个人观点，仅供参考…

《设计模式之美》—— 王争(极客时间)

《架构整洁之道》—— Robert C. Martin