解耦设计手法小结

比眉伴天荒 2023-03-01 14:56 13阅读 0赞

设计是一个平衡的产物，需要在各个约束条件下（组织目标，业务目标，开发流程，技术能力，学习及维护成本等）不断地进行演进。 我们虽然不提倡做大而全的设计，但会坚持进行基础性设计，以保证我们的设计一直在正确的方向上演进。

设计演进的过程既可以是自上而下的，也可以是自下而上的。

# 基本设计原则 #

业界普遍被接受的设计原则不再赘述。这里特别针对基于开源项目的软件，其总体主旋律将是：跟随，扩展，贡献，其中跟随将是一个基本能力,反观深度定制的方式会遭遇越来越多的尴尬。落实在设计上，其最核心的设计原则:隔离自有业务。相较于模块化的低耦合、高内聚的原则，这里的要求会更高。

先从模块上考虑应用的层次，依次考虑：

*  应用层
 *  开源项目本身的定制或移植机制
 *  新增的接口层
 *  新增的适配层或业务层
 *  既有的接口层
 *  既有的实现

设计本身还要保证业务的完整性，以及对性能、系统开销、卡顿和稳定性的要求。

# 解耦的设计实践 #

以下为关于解耦的设计方法总结，以及应用要点便于在设计时评估。

解耦是隔离变化和降低复杂度的重要手段，这里以解耦代言隔离变化，其思想就是以分工协作代替全面控制，接口的定义大于业务逻辑的定义。其思考路径是:分不分？如何分？如何分是具体形式的问题，下面详述。分不分则取决于功能需求, 常见分离的需求有:

*  功能强内聚  
    这没什么好说的, 最常见的理由。
 *  功能的整合和转换  
    就是为了整合某些功能或者达到某种切换的目的，向上提供一个更为标准统计的接口。内部可能会进行一些业务逻辑处理，数据、状态转换之类的操作。如编译器分出前后端也是这样的概念。
 *  降低复杂度  
    接口的定义至关重要，接口本身不能绑定业务约束或者流程。整体交互上是面向无状态的接口，而不是面向过程。过程的合理性，即业务流程则由不同的单元内部保障，再通过接口交互。**而向约束的编程也是在函数内进行约束的判断，间接达到带状态接口。**

在手法上可以概括为从宏观到微观的四个层次:

*  进程 也可以是物理空间上的分离
 *  库 模块化/分层
 *  代码 如下图:  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neGluMDk_size_16_color_FFFFFF_t_70]

## 进程 ##

以分进程的方法来进行协作是 Unix 世界的传统，即 KISS 原则。Unix 下有各式小工具，这些工具之间通过管道连结起来达到强大的功能。另外以服务的方式隔离业务也很常见。如 Windows 中 COM+ 的架构，甚至是 HTTP Server 等。

分进程的特点在于不同进程间的功能高度独立，并行处理的情况较多，服务提供者能够按需布署，存在一对多的情况，或有额外的安全性考虑。而挑战在于性能、系统开销，需要熟悉 IPC 以及共享内存的知识。

## 分库 ##

这是一个重要的模块化手法，主要是以动态库和脚本的形式, 甚至是独立的程序提供扩展。其核心思想是以插件的形式完成功能组装，以物理分离的形式提供出来。  
插件本身实现一套标准的接口，包括:参数配置，接收输入，状态输出，数据输出等。如 Windows 的核心驱动模块，Photoshop/GIMP 中的图像处理功能，Matlab 以及 R 语言中的函数库等等，不胜枚举。以静态库形式提供出来的模块，更接近于代码级或者分层级别的体现，无法直接达到按需布署的能力。

分库要求各个独立库的接口层比较单一，特别适用于业务逻辑强内聚的场景。同时插件的功能将直接影响主程序的稳定性。

## 分层 ##

就是将某一类功能的类和代码集中起来，向外提供特定接口或若干接口类，这个逻辑上的集合，就是层(layer)或者模块(module)，也有叫 unit 或者 API 之类的。与分库、分进程本质区别就在于它是一个逻辑集合，优势在于可以更灵活的与不同模块交互，因为接口可以多样化（支持代码级的交互），这也同样是它的劣势，有时导致它形同虚设，丧失了解耦的能力。

所以分层成功与否，关键在于接口(含接口类)的定义和控制。常见的一些手法，如MVC, 胶合层(glue),适配层(port),WebKit 和 Chrome 中也有应用。

## 代码 ##

这是一个最为微观，最为复杂的层次。但是到了这层，并不表示必然存在耦合问题。如果一些架构在设定上考虑到了扩展和适配的需求，在这个级别进行解耦反而最为自然。

### WebKit 的 port 方案 ###

以 Image 类为例，它的一个函数与平台相关，于是类的实现被放在了三个文件中 Image.cpp, ImageMac.mm 和 ImageWin.cpp中。Image.cpp 中实现了公共的部分，而 ImageMac.mm 中实现了 Mac OS版本，而ImageWin.cpp 则实现了 Windows 版本。  
![在这里插入图片描述][20200727151255461.png]  
另一种实现方式，如多媒体元素的播放控件。首先是 MediaPlayer 提供了一部分公共的逻辑，对于与平台相关实现的部分，定义了一个 MediaPlayerPrivateInterface，各平台继承自这个接口实现各自的逻辑。  
![在这里插入图片描述][20200727151246842.png]  
当我们解决了架构上的解耦后，在模块内部引入一定的耦合度就不是问题了。可供选择的方法就太多了。

### Helper Class ###

Helper Class 已经为一个类添加一个友类，执行一些差异化的业务。Helper Class 可以使用类似 WebKit Port 的机制为不同的系统提供不同的实现，也可以配合工厂模式，实现更为弹性的选择。  
![在这里插入图片描述][20200727151237991.png]分散的逻辑判断就可以转为函数调用。  
![在这里插入图片描述][20200727151220978.png]关于 helper 的使用一直是有争议，网上也有很多避免使用 helper class 的讨论。 主要论调在于认为 helper class 是过程化的产物，思考时是考虑的是流程上的逻辑补充。

# \[OOD\] 为什么单一职责原则(SRP)是最难运用的 #

单一职责原则(SRP)已经几乎是每一个程序员都知道的设计原则。最早由 Robert C. Martin 在《敏捷软件开发 — 原则、模式与实践》中正式提出。书中作者在结论中提到:

> SRP是所有设计原则最简单的，但也是最难运用的。（中文翻译有之一，略去了)

现实工作中，关于一个类是否符合 SRP，或者是否有必要符合 SRP 的讨论是经常发生的。争论的关键在于职责的定义，但我理解 SRP 真正的核心是关注于变化。这并不是我的新见解，全是来自 Martin 大叔的解释：

>  *  首先职责的定义是: 引起变化的原因，不是由分类所决定的。如果存在相对的变化，才要考虑分离。
>  *  其次，关于引起变化的因素，不要空想。一定确信有变化的可能，才会加以考虑。

他的提醒是非常中肯的。实践中正是常常基于功能的分类来定义职责的。举个例子，假如我们要开发一个学校的教职员工管理系统。需要定义一个教师员工的类(炒菜的师傅先就不考虑了)，考虑到老师和班主任两个角色，通常会认为他有两类职责:

*  教师 (班主任很可能会带课)
 *  班级的管理 (组织班委，整治一下早恋之类的)

![在这里插入图片描述][20200727151750106.png]  
这时你拿着设计到了一个寄宿学校，校长可能会告诉你，他们这里的教师会轮流值班，兼做保育员，照看住校的学生。又是一个新的职责，怎么办?

如果遵守单一职责的原则，我们应该增加一个接口:  
![在这里插入图片描述][20200727151800465.png]  
果真要如此吗? 注意，如果是在一般的学校，保育员不是老师的本职工作，可在这所寄宿学校里，却是教师的本职工作，是和老师一起变化的。校长的反馈是:

> “我们学校的教师必须担任保育工作，我并不认为这会是什么新职责。作为教师，要么接受，要么离开。至于班主任工作，确实还是其特殊的地方，不然也不会给担任班主任的老师多一点津贴了。”

请再体会一下，关于保育员职责的讨论。**如果两个职责/角色不是同时变化的，才考虑分离。** 如果确定同时变化，就没有必要分离。除非有一天，某个劳动部门到该寄宿学校检查，认为他们这样不符合某个法律规定，强制规定老师可以选择是否担当保育员。如此一来，两个职责就又变成独立变化的了，就可以考虑分离职责。

再进一步，如果是针对一个只有一个支教教师的小学，极为偏僻。这里的校长会告诉你:

> ”这个学校里的每一个教师，唯一的一个，既是校长，也是老师。我不认为还需要明确班主任做什么，教师做什么，在这里，只要学生需要的都要做。并且这里很穷，五年内都不见得再有新老师来。”

这个感人的故事告诉我们，在这所学校里， 他不在了，这所学校也就不在了，**完全没有什么相对的变化，也没有什么可以确认的变化**。所以在这里的管理系统里，教职员工只有一个单实例类,:  
![在这里插入图片描述][2020072715190268.png]  
聊到这里，不知道我说清楚了没有！设计要跟着需求走，不能生硬的套理论。欢迎拍砖!

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neGluMDk_size_16_color_FFFFFF_t_70]: /images/20230208/8c668c4b5c39410fb30b22cc08f62b3e.png
[20200727151255461.png]: /images/20230208/079cbaf85ff349088155415b5e3a3a8f.png
[20200727151246842.png]: https://img-blog.csdnimg.cn/20200727151246842.png
[20200727151237991.png]: https://img-blog.csdnimg.cn/20200727151237991.png
[20200727151220978.png]: https://img-blog.csdnimg.cn/20200727151220978.png
[20200727151750106.png]: https://img-blog.csdnimg.cn/20200727151750106.png
[20200727151800465.png]: https://img-blog.csdnimg.cn/20200727151800465.png
[2020072715190268.png]: https://img-blog.csdnimg.cn/2020072715190268.png