背景介绍
这是我的《架构整洁之道》系列的第九篇，这一篇我们将一起学习 ISP 接口隔离原则～
《架构整洁之道》系列：
ISP 接口隔离原则
我们先一起看下图的这种软件结构：
有多个用户需要操作 OPS 类。现在，我们假设这里的 User1 只需要使用 op1, User2 只需要使 op2, User3 只需要使用 op3。
很明显，User1 虽然不需要调用 op2、op3，但在源代码层次上也与它们形成依赖关系。这种依赖、意味着我们对 OPS 代码中 op2 所做的任何修改，即使不会影响到 User1 的功能，也会导致它需要被重新编译和部署。
这个问题可以通过将不同的操作隔离成接口来解决：
现在 User1 的源代码会依赖于 U1Ops 和 op1，但不会依赖于 OPS。这样一来，我们之后对 OPS 做的修改只要不影响到 User1 的功能，就不需要重新编译和部署 User1 了。
在一般情况下，任何层次的软件设计如果依赖于不需要的东西，都会是有害的。从源代码层次来说，这样的依赖关系会导致不必要的重新编译和重新部署，对更高层次的软件架构设计来说，问题也是类似的。现在我们举一个例子：
我们假设某位软件架构师在设计系统 S 时，想要在该系统中引入某个框架F。这时候，假设框架F的作者又将其捆绑在一个特定的数据库D上，那么就形成了S依赖于F, F又依赖于D的关系。
在这种情况下，如果 D 中包含了 F 不需要的功能，那么这些功能同样也会是 S 不需要的。而我们对 D 中这些功能的修改将会导致 F 需要被重新部署，后者又会导致 S 的重新部署。更糟糕的是，D 中一个无关功能的错误也可能会导致 F 和 S 运行出错。
结束语
任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦。
最后
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
少年向来不识天高地厚
放眼处皆自负才高八斗
虽是自命风流
倒也坦诚无忧
我爱这样的少年
谦和而狂妄
骄傲又坦然☀️
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
