谈谈过度设计：因噎废食的陷阱

写软件和造楼房一样需要设计，但是和建筑行业严谨客观的设计规范不同，软件设计常常很主观，且容易引发争论。

引言

设计模式的缺陷

“过度设计” 这个词也不是空穴来风，首先，互联 软件的迭代比传统软件快很多，传统软件，比如银行系统，可能一年只有两个迭代，而 站的后台可能每周都在发布更新，所以互联 非常注重软件修改的便捷性。其次，设计模式的 “分模块”，“开闭原则” 等主张，天然地易于拓展而不利于修改，和互联 软件频繁迭代产生了一定的冲突。

开闭原则的缺陷

开闭原则：软件中对象应该对扩展开放，对修改关闭。

基于开闭原则，诞生了很多中台系统。应用通过插件的方式，可以在满足自身定制业务需求的同时，复用中台的能力。

当业务需求满足中台的主体流程和规范时，一切看上去都很顺利。一旦需求发生变更，不再符合中台的规范了，往往需要中台进行伤筋动骨的改造，之前看到一篇文章吐嘈 “本来业务上一周就能搞定的需求，提给中台需要8个月”。

所以基于中台无法进行深度的创新，深度创新在软件上必然也会有深度的修改，而中台所满足的开闭原则是不利于修改的。

最小知识原则的缺陷

最小知识原则：一个对象对于其他对象的了解越少越好。

最小知识原则又称为 “迪米特法则”，基于迪米特法则，我们会把软件设计成一个个 “模块”，然后对每个 “模块” 只传递需要的参数。

在过程式编码中，代码片段是拥有上下文的全部信息的，比如下面的薪资计算代码：

// 绩效int performance = 4;// 职级int level = 2;String job = "engineer";switch (job) {    case "engineer":        // 虽然计算薪资时只使用了 绩效 作为参数, 但是从上下文中都是很容易获取的        return 100 + 200 * performance;    case "pm":        // .... 其余代码省略}

而如果我们将代码改造成策略模式，为了满足迪米特法则，我们只传递需要的参数：

// 绩效int performance = 4;// 职级int level = 2;String job = "engineer";// 只传递了需要 performance 参数Context context = new Context();context.setPerformance(performance);strategyMap.get(job).eval(context);

需求一旦变成 “根据绩效和职级计算薪资”，过程式代码只需要直接取用上下文的参数，而策略模式中需要分三步，首先在 Context 中增加该参数，然后在策略入口处设置参数，最后才能在业务代码中使用增加的参数。

这个例子尚且比较简单，互联 的快速迭代会让现实情况更加复杂化，比如多个串联在一起模块，每个模块都需要增加参数，修改成本成倍增加。

可理解性的缺陷

设计模式一般都会应用比较高级的语言特性：

这些大大增加了设计模式代码的理解成本。而过程式编码只需要会基本语法就可以写了，不需要理解这么多高级特性。

小结

这三点缺陷造成了设计模式和互联 快速迭代之间的冲突，这也是应用设计模式时难以避免的成本。过程式编码相比设计模式，虽然有着简单，易于修改的优点，但是却有永远无法回避的本质缺陷。

过程式编码的本质缺陷

上文中分析，过程式编码的优点就是 “简单，好理解，易于修改”。这些有点乍看之下挺对的，但是仔细想想都很值得怀疑：

软件复杂度

软件工程著作 《人月神话》 中认为软件复杂度包括本质复杂度和偶然复杂度。

本质复杂度是指业务本身的复杂度，而偶然复杂度一般是因为方法不对或者技术原因引入的复杂度，比如拆分服务导致的分布式事务问题，就是偶然复杂度。

如果一段业务逻辑本来就很复杂，即本质复杂度很高，相关模块的代码必然是复杂难以理解的，无论是采用设计模式还是过程式编码。“用过程式编码就会更简单” 的想法在这种情况下显然是荒谬的，相反，根据经验，很多一直在采用过程式编码的复杂模块，最后都会变得逻辑混乱，缺乏测试用例，想重构时已经积重难返。

那么设计模式会增加偶然复杂度吗？阅读有设计模式的代码，除了要理解业务外，还要理解设计模式，看起来是增加了偶然复杂度，但是下文中我们会讨论，从长期的角度来看，这不完全正确。

理解单一问题 vs 理解一类问题

开头提到，设计模式是软件设计的“规范”，和建筑业的设计规范类似，规范能够帮助不同背景的人们理解工程师的设计，比如，当工人们看到三角形的结构时，就知道这是建筑师设计的支撑框架。

过程式代码一般都是针对当前问题的某个特殊解决方法，不包含任何的 “模式”，虽然表面上减少了 “模式”的学习成本，但是每个维护者/调用者都要去理解一遍这段代码的特殊写法，特殊调用方式，无形中反而增加了成本。

以数据结构的遍历为例，如果全部采用过程式编码，比如二叉树打印的代码是：

public void printTree(TreeNode root) {    if (root != null) {        System.out.println(root.getVal());        preOrderTraverse1(root.getLeft());        preOrderTraverse1(root.getRight);    }}

图的节点计数代码是：

public int countNode(GraphNode root) {    int sum = 0;    Queue<Node> queue = new LinkedList<>();    queue.offer(root);    root.setMarked(true);    while(!queue.isEmpty()){        Node o = queue.poll();        sum++;        List<Node> list = g.getAdj(o);        for (Node n : list) {            if (!n.isMarked()) {                queue.add(n);                n.setMarked(true);            }        }    }    return sum;}

这些代码本质上都是在做数据结构的遍历，但是每次读到这样的代码片段时，你都要将它读到底才发现它其实就是一个遍历逻辑。幸好这里的业务逻辑还比较简单，就是一个打印或者计数，在实际工作中往往和更复杂的业务逻辑耦合在一起，更难发现其中的遍历逻辑。

而如果我们使用迭代器模式，二叉树的打印代码就变成：

public void printTree(TreeNode root) {    Iterator<TreeNode> iterator = root.iterator();    while (iterator.hasNext()) {        TreeNode node = iterator.next();        System.out.println(node);    }}

图的节点计数代码变成：

public int countNode(GraphNode root) {    int sum = 0;    Iterator<TreeNode> iterator = root.iterator();    while (iterator.hasNext()) {        iterator.next();        sum++;    }    return sum;}

这两段代码虽然有区别，但是它们满足一样的 ”模式“，即 “迭代器模式”，看到 Iterator 我们就知道是在进行遍历，甚至都不需要关心不同数据结构具体实现上的区别，这是所有遍历统一的解决方案。虽然在第一次阅读这个模式的代码时需要付出点成本学习 Iterator，但是之后类似代码的理解成本却会大幅度降低。

设计模式中类似上面的例子还有很多：

是面对具体问题 case by case 的学习，还是掌握一个通用原理理解一类问题？肯定是学习后者更有效率。

“过程式代码更加好理解”往往只是针对某个代码片段的，当我们将范围扩大到一个模块，甚至整个系统时，其中会包含大量的代码片段，如果这些代码片段全部是无模式的过程代码，理解成本会成倍增加，相似的模式则能大大降低理解成本，越大的代码库从中的收益也就越大。

新人学习过程式编码和设计模式的学习曲线如下图：

过程式编码虽然刚开始时没有任何学习压力，但是不会有任何积累。设计模式虽然刚开始时很难懂，但是随着学习和应用，理解会越来越深刻。

点击查看原文，获取更多福利！

https://developer.aliyun.com/article/1092076?utm_content=g_1000365272