软件架构基础 3: 什么是好的模块化代码？高内聚、低耦合如何衡量？

0. 写在前面

什么是好的代码？好的代码应该模块化。

王垠在其《编程的智慧》中也提到，要“写模块化的代码”。(不对人做评价，这篇文章写得是非常好的。)

如果你读过《代码大全》和《代码整洁之道》等书，一定对 “高内聚、低耦合” 不陌生。

好的模块化代码就是要高内聚、低耦合。

事实上，内聚和耦合是 1972 年就提出的概念，由于耦合不好具体的衡量，Meilir Page-Jones 在 1992 年提出了 共生性（Connascence） 。本章重点就是介绍如何评估模块化架构，以及引入共生性这一概念来帮助更好的模块化。

1. 模块化

不同的平台、语言为代码提供了不同的复用机制，将相关代码组合成模块。

理解模块对于架构师来说非常重要，因为用来分析架构的工具（可视化等）常常都依赖于模块化的概念。 如果一个架构师在设计一个系统时，没有注意到各个部分是如何连接在一起的，那么他们最终创建的系统会带来无数的问题。

架构师必须保持良好的结构，这不会偶然发生。

模块的代码到底是什么？我们用模块化来描述相关代码中的逻辑分组，这些模块可以用来构造一个更复杂的结构。

现代的语言有各种各样的封装机制，例如，许多语言可以在函数/方法、类、包/命名空间中定义行为，每个包都有不同的可见性和范围规则。（这有时候也会让开发人员选择困难）

架构师必须意识到开发者是如何组织包的，如果几个包紧密的耦合在一起，那么重用其中一个包就变得非常困难。

鉴于模块化的重要性，研究人员提供了各种语言无关的标准来衡量，我们专注于三个关键概念：

• 内聚（Cohesion）

• 耦合（Coupling）

• 共生性（Connascence） （注：参考 《UML面向对象设计基础》 的翻译）

2. 内聚（Cohesion）

内聚性是指子程序中各种操作之间联系的紧密程度，我们的目标是让每一个模块只做好一件事，不去做其他事情。

试图分割一个内聚的模块只会导致耦合性增加和可读性降低。（Attempting to divide a cohesive module would only result in increased coupling and decreased readability.） —— Larry Constantine



计算机科学家们已经定义了一系列的内聚的衡量标准，从最好到最坏列出如下：

• 功能性内聚（Functional cohesion）： 模块内所有元素都为完成同一个功能而存在，共同完成一个单一的功能，模块已不可再分，具有最高的内聚 ；

• 顺序内聚（Sequential cohesion）：模块必须顺序执行；

• 通信内聚（Communicational cohesion）：两个不同操作的模块使用同样的数据。例如，在数据库中添加一条记录，并根据该信息生成一封邮件；

• 过程内聚（Procedural cohesion）：两个模块必须以特定的次序执行；

• 时间内聚（Temporal cohesion）：把需要同时执行的动作组合在一起形成的模块。

• 逻辑内聚（Logical cohesion）：这种模块把几种相关的功能组合在一起， 每次被调用时，由传送给模块参数来确定该模块应完成哪一种功能。

• 巧合内聚（Coincidental cohesion）：模块内的各个元素之间没有任何联系，只是偶然地被凑到一起；内聚程度最低。



内聚不容易考量，特定的模块需要架构师来具体决定，例如，考虑一个模块定义了：

Customer：

• add customer

• update customer

• get customer

• notify customer

• get customer orders

• cancel customer orders

或者可以说将后两个函数剥离出来，分成两个模块：

Customer：

• add customer

• update customer

• get customer

• notify customer

Order：

• get customer orders

• cancel customer orders

哪个更好？一如既往，这要看情况：

• 订单只有这两个操作吗？如果是这样，将这些操作放在客户包中维护可能是有意义的；

• 客户包按预期是否会变得更大？

• 订单是否需要如此多的客户信息？

这些问题代表了软件架构师工作核心的权衡分析。

由于内聚非常主观，计算机科学家制定了一个标准来衡量内聚性，其中 LCOM(Lack of Cohesion in Methods) 为著名。这里涉及到的数学公式平时很少用到，在此不再展开，只需要知道有这么一个公式，在需要的时候可以再查询拿出来用。想进一步了解的读者可以查看：https://en.wikipedia.org/wiki/Programming_complexity

3. 耦合（Coupling）

我们常常谈到要“解耦”，弱耦合是系统可维护的关键。

耦合其实也有多种类型，但在此不再介绍，因为它们已经被共生性（Connascence）所取代。

4. 共生性（Connascence）

1996 年 Meilir Page-Jones 发表了

《What Every Programmer Should Know About Object-Oriented Design》

，完善了耦合的度量，并命名为：Connascence。

他是这样定义的：

如果一个组件的改变会要求另一个组件进行修改，才能保持系统的整体正确性，那么这两个组件就是共生的。—— Meilir Page-Jones

共生性分为静态的和动态的。我们将分别介绍各种类型的共生性，对于部分重要的、不易理解的，我将补充一些代码案例，作为具体的参考来帮助理解。

静态共生性：

4.1 名称共生性（Connascence of Name, CoN）

methodA() 改名为  methodB() 时,调用  methodA() 的地方都要改名，这是代码库中最常见的耦合方式，现代的 IDE 的检索功能使修改代码的名称变得很容易，这是最理想的耦合方式；



4.2 类型共生性（Connascence of Type, CoT)

如果一个变量从值 100 变成了一个很大的数，变量的类型可能要从 int 改成 BigInteger

4.3 意义共生性（Connascence of Meaning, CoM）

例如，在很多语言中，通常会把大于 0 的数字认为是 True，0 认为是 False。下面是 Java 中的一个具体例子：

a.compareTo(b)
// 如果 a = b，则返回值 0；
// 如果 a > b，则返回大于 0 的值；
// 如果 a < b，则返回小于 0 的值。

4.4 位置共生性（Connascence of Position, CoP）

函数的参数的位置顺序或个数耦合，例如下面的函数增加一个参数后，函数调用将会出错。

针对这个例子，我们可以通过下面的办法，将位置共生性转为名称共生性来降低耦合性：

class User { FirstName, LastName, Address }
void SaveUser(User);

myrepo.SaveUser(new User{
        FirstName = "bob",
        LastName = "Marley",
        Address = "Jamaica"});

4.5 算法共生性（Connascence of Algorithm, CoA）

多个组件必须就一个特定的算法达成一致。例如：客户端和服务端用相同的算法验证用户身份。这代表一种较高的耦合形式——如果算法细节改变，验证将不再有效。

动态共生性：

4.6 执行共生性（Connascence of Execution, CoE）

代码的执行顺序上的耦合。例如下面的代码，在设置主题之前就发送了，明显在顺序上有问题。

email = new Email();
email.setRecipient("foo@example.com");
email.setSender("me@me.com");
email.send();
email.setSubject("whoops");

4.7 时间共生性（Connascence of Timing, CoT）

常见情况是两个线程同时执行造成的竞赛条件。

这里我们可以看一个有趣的例子，发生在 bootstrap 的一个 issue：https://github.com/twbs/bootstrap/issues/3902

// using bootstrap modal
$(element).modal('hide')
$(element).modal('show') // Error!

// 隐藏一个 modal 大约需要 500ms 的动画，
// 如果你在这时候直接调用了 'show'，将会发生异常

// 我们必须这样做
$(element).modal('hide')
$(element).on('hidden.bs.modal', ()=>{
    $(element).modal('show') // ok
})

4.8 值共生性（Connascence of Values, CoV）

常见的情况在分布式事务中，例如需要在多个独立的数据库中做分布式事务。

4.9 身份共生性（Connascence of Identity, CoI）

两个独立的模块需要共享和更新同一个数据结构，例如：分布式队列。

5. 共生性的属性

5.1 强度（Strength）

Page-Jones 指出，共生性有明确的强弱谱系，如下图所示，按强度递增排序。identity 具有最强的共生性，name 具有最弱的共生性。——也就是说用 name 的方式耦合则为最弱的耦合方式。



架构师应该倾向于静态共生性而不是动态共生性，因为开发人员可以通过现代的 IDE 来很快地确定它。

5.2 局部性（Locality）

局部性指两个模块的之间的远近程度。

通常情况下，在同一模块中、距离较近的类比在不同模块中、距离距离较远的类具有更高的共生性。换句话说，随着两个模块在代码中的距离增加，共生性会减弱。

5.3 程度（Degree）

共生性的程度与模块的影响大小有关——它影响了几个类还是几十个类？影响较小的共生性对代码库的损坏就较小。

6. 如何通过共生性来提高系统模块化

讲了这么多，我们到底如何实践共生性呢？

Page-Jones 提供了三个使用共生性来提高系统模块化的指南：

1.通过将系统拆分成封装的元素，使得整体的共生性达到最弱

2.最大限度地减少任何跨越封装边界的共生性

3.最大限度地提高封装边界的共生性

Jim Weirich （传奇的软件架构创新者，Ruby 社区活跃人士）简化了上面较为抽象的指导，提供了两个更具体的建议：

• 程度法则（Rule of Degree）：将强共生性转化为弱共生性。

• 局部性规则（Rule of Locality）：随着软件元素之间距离的增加，应使用较弱的共生性。

7. 耦合性和共生性

从架构师的角度来看，耦合和共生是有所重叠的，这是不同时代的产物，下图列出两者重叠的部分：



共生性提供了更精细化的考量，例如左边的数据耦合，在右边的静态共生性提供了更具体的建议。

8. 局限性

尽管如此，架构师在应用这些指标来分析和设计系统时，存在几个问题：

• 这些度量从代码层面考察细节，关注代码质量，而不一定是架构。架构师更关注模块如何耦合，而不是耦合程度，例如，架构师关心的是同步或异步通信，而不关心如何实现。

• 共生性并没有真正解决许多现代架构师必须做出的一个基本决定–在分布式架构（例如：微服务）中，使用同步还是异步通信？在后面会介绍新的方法来思考现代的共生性。

虽然对模块化进行了大量的介绍和思考， 开发人员和架构师在实际实施过程中，还是会遇到很多的困难。

纸上得来终觉浅，绝知此事要躬行。

设计良好的架构，并非易事！

欢迎关注我的公众号：