整洁架构SOLID-接口隔离原则(ISP)

文章目录

定义

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

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

这个问题可以通过将不同的操作隔离成接口来解决 ,具体如下图所示:

同样,我们也假设这个例子是用Java这种静态类型语言来实现的,那么现在User1的源代码会依赖于U1Ops和op1,但不会依赖于OPS。这样一来,我们之后对OPS做的修改只要不影响到User1的功能,就不需要重新编译和部署User1了。

ISP与编程语言

很明显,上述例子很大程度上也依赖于我们所采用的编程语言。对于Java这样的静态类型语言来说,它们需要程序员显式地import、use或者include其实现功能所需要的源代码。而正是这些语句带来了源代码之间的依赖关系,这也就导致了某些模块需要被重新编译和重新部署。

而对于Ruby和Python这样的动态类型语言来说,源代码中就不存在这样的声明,它们所用对象的类型会在运行时被推演出来 ,所以也就不存在强制重新编译和重新部署的必要性。这就是动态类型语言要比静态类型语言更灵活、耦合度更松的原因。

如果认为ISP只是一个与编程语言的选择紧密相关的设计原则,而非软件架构问题,这就错了。

ISP与软件架构

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

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

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

小结

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

参考内容来源于:《架构整洁之道》

相关推荐
数据智能老司机1 小时前
CockroachDB权威指南——CockroachDB SQL
数据库·分布式·架构
数据智能老司机1 小时前
CockroachDB权威指南——开始使用
数据库·分布式·架构
c无序2 小时前
【Docker-7】Docker是什么+Docker版本+Docker架构+Docker生态
docker·容器·架构
数据智能老司机2 小时前
CockroachDB权威指南——CockroachDB 架构
数据库·分布式·架构
矿渣渣2 小时前
RM Cortex-A7 架构中“SEV”汇编指令解析
汇编·架构
uhakadotcom3 小时前
Flutter入门指南:快速构建高性能移动应用
面试·架构·github
月阳羊4 小时前
【无人机】无人机PX4飞控系统高级软件架构
嵌入式硬件·架构·系统架构·无人机
uhakadotcom4 小时前
MVC 和 MVVM 架构模式:基础知识与实践
后端·面试·架构
uhakadotcom5 小时前
SwiftUI 入门指南:快速构建跨平台应用
面试·架构·github
久违の欢喜6 小时前
《云端变革:云计算重塑现代企业架构的实践之路》
架构·云计算