C++正交设计笔记3 - 变化驱动：正交设计

---

原文: https://www.jianshu.com/p/d127b8afc8cb

一个出发点

当谈起软件设计的目的时，能够获得所有人认同的答案只有一个：功能实现。 因为这是一个软件存在的根本原因。

而在计算机软件发展的初期，这一点也正是所有人做软件设计的唯一动机。因而，很自然的，整个软件都被放在单一过程中，然后用到处存在的goto语句控制流程。

尽管理论上讲，任意复杂的系统都可以被放入同一个函数里。但随着软件越来复杂，即便是智商最为发达的程序员也发现，单一过程的复杂度已经超出他的掌控极限。这逼迫人们必须对大问题进行分解，分而治之。

时至今日，尽管超大函数，上帝类依然并不罕见，但当大到一定程度，上帝类的创造者最终也会发现自己终究没有上帝般的掌控力。因而，哪怕是软件设计素养为负值的开发者，或多或少也会对一个复杂系统进行一定程度的拆分。

这就是模块化设计的最初动机。

两个问题

一旦人们开始进行进行模块化拆分，就必须解决如下两个问题:

• 究竟软件模块该怎样划分才是合理的?
• 将一个大单元划分为多个小单元之后，它们之间必然要通过衔接点进行合作。如果我们把这些衔接点看作API，那么问题就变为：怎样定义API才是合理的?

更简单的说：怎么分？然后再怎么合(设计API)？

而这两个问题的答案，正是现代软件设计的核心关注点。

三方关系

为了找到这两个问题的答案，我们需要重新回到最初的问题：为何要做软件设计?

Kent Beck给出的答案是：软件设计是为了让软件在长期范围内容易应对变化。

在这个精炼的定义中，包含着三个关键词：长期，容易，变化。这意味着:

• 越是需要长期维护的项目，变化更多，也更难预测变化的方式;
• 软件设计，事关成本;
• 如何在难以预测的千变万化中，保持低廉的变更成本，正是软件设计要解决的问题。

对此，Kent Beck提出了一个更为精炼的原则：局部化影响。意思是说：我们希望，任何一个变化，对于我们当前的软件设计影响范围都可以控制在一个尽量小的局部。

这当然是所有严肃的软件从业者都梦寐以求的。可问题在于，如何才能做到?

内聚与耦合

每个读过基础软件工程教程的人都知道：一个易于应对变化的软件设计应该遵从高内聚，低耦合原则。

• 所谓内聚性，关注的是一个软件单位内部的关联紧密程度。因而高内聚追求的是关联紧密的事物应该被放在一起，并且只有关联紧密的事物才应该被放在一起。简单说，就是Unix的设计哲学：Do One Thing, Do It Well。
• 而耦合性，则是强调两个或多个软件单位之间的关联紧密程度。因而低耦合追求的是，软件单位之间尽可能不要相互影响。

这样的解释，对于很多人而言，依然会感到过于抽象。但如果我们进一步思考，就会意识到：看似神秘的内聚与耦合，正好对应最初的两个问题:

• 如何分? 当我们划分模块时，要让每个模块都尽可能高内聚;
• 如何合? 而当我们定义模块之间的API时，需要让双方尽可能低耦合。

如果用图来展现，就是下面的过程与关系:

这幅图揭示了模块化设计的全部：

• 首先将一个低内聚的模块首先拆分为多个高内聚的模块；然后再考虑这多个模块之间的API设计，以降低这些高内聚的软件单元之间的耦合度。
• 除了内聚与耦合之外，上面这幅图还揭示了另外一种关系：正交。具备正交关系的两个模块，可以做到一方的变化不会影响另外一方的变化。换句话说，双方各自独自变化，互不影响。
• 而这幅图的右侧，正是我们模块化的目标。它描述了永恒的三方关系࿱