设计原则(五):ISP 接口隔离原则

3,545 阅读3分钟

大家好,我是寒草😈,一只工作一年出头的草系码猿🐒
如果喜欢我的文章,可以关注 ➕ 点赞,与我一同成长吧~
加我微信:hancao97,邀你进群,一起学习交流,成为更优秀的工程师~

「这是我参与2022首次更文挑战的第11天,活动详情查看:2022首次更文挑战」。

背景介绍

这是我的《架构整洁之道》系列的第九篇,这一篇我们将一起学习 ISP 接口隔离原则~

《架构整洁之道》系列:

ISP 接口隔离原则

我们先一起看下图的这种软件结构:

image.png

有多个用户需要操作 OPS 类。现在,我们假设这里的 User1 只需要使用 op1, User2 只需要使 op2, User3 只需要使用 op3。

很明显,User1 虽然不需要调用 op2、op3,但在源代码层次上也与它们形成依赖关系。这种依赖、意味着我们对 OPS 代码中 op2 所做的任何修改,即使不会影响到 User1 的功能,也会导致它需要被重新编译和部署。

这个问题可以通过将不同的操作隔离成接口来解决:

image.png

现在 User1 的源代码会依赖于 U1Ops 和 op1,但不会依赖于 OPS。这样一来,我们之后对 OPS 做的修改只要不影响到 User1 的功能,就不需要重新编译和部署 User1 了。

在一般情况下,任何层次的软件设计如果依赖于不需要的东西,都会是有害的。从源代码层次来说,这样的依赖关系会导致不必要的重新编译和重新部署,对更高层次的软件架构设计来说,问题也是类似的。现在我们举一个例子:

我们假设某位软件架构师在设计系统 S 时,想要在该系统中引入某个框架F。这时候,假设框架F的作者又将其捆绑在一个特定的数据库D上,那么就形成了S依赖于F, F又依赖于D的关系。

image.png

在这种情况下,如果 D 中包含了 F 不需要的功能,那么这些功能同样也会是 S 不需要的。而我们对 D 中这些功能的修改将会导致 F 需要被重新部署,后者又会导致 S 的重新部署。更糟糕的是,D 中一个无关功能的错误也可能会导致 F 和 S 运行出错。

结束语

image.png

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

最后

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

少年向来不识天高地厚
放眼处皆自负才高八斗
虽是自命风流
倒也坦诚无忧
我爱这样的少年
谦和而狂妄
骄傲又坦然☀️

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

各位的点赞与关注是我源源不断的动力,可以加我微信:hancao97,邀你进群,一起学习交流,成为更优秀的前端工程师~