0. 写在前面

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

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

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

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

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

1. 模块化

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

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

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

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

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

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

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

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 中的一个具体例子:

1
2
3
4
a.compareTo(b)
// 如果 a = b,则返回值 0;
// 如果 a > b,则返回大于 0 的值;
// 如果 a < b,则返回小于 0 的值。

4.4 位置共生性(Connascence of Position, CoP)

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

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

1
2
3
4
5
6
7
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)

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

1
2
3
4
5
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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
// 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. 局限性

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

  • 这些度量从代码层面考察细节,关注代码质量,而不一定是架构。架构师更关注模块如何耦合,而不是耦合程度,例如,架构师关心的是同步或异步通信,而不关心如何实现。
  • 共生性并没有真正解决许多现代架构师必须做出的一个基本决定–在分布式架构(例如:微服务)中,使用同步还是异步通信?在后面会介绍新的方法来思考现代的共生性。

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

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

设计良好的架构,并非易事!