第5章：软件构建中的设计

为什么设计从问题开始

软件设计面对的不是一张静止的蓝图，而是在约束不完整、需求会变化、实现细节会反过来暴露问题的条件下，持续决定“谁负责什么”。本章把 本质复杂度 与实现方式带来的负担分开：前者要被模型表达，后者要被边界、接口和工具压低。

先预测一个变化：如果“订单状态新增待审核”只改变 Order 的内部规则，理想设计应只影响一个边界；如果 Pricing 和 Payment 也必须直接读写同一状态，变化就会扩散。下面的图先把目录节点收束为证据产物，再用实验观察两种设计选择的差异。

第5章 软件构建中的设计

本章的中心判断是：设计不是在编码前完成的一份文档，而是一组可以被实现、反例和同伴复核持续修正的假设。好的设计不承诺永远不变；它承诺变化会先经过清晰的边界，失败会停在可定位的位置，决定会留下足够证据供下一位读者重放。

5.1 设计中的挑战

“5.1 设计中的挑战”先把设计看成面对不完整信息的判断工作：目标、约束、风险和可接受结果会一起变化，因此必须把假设写出来，再用反馈确认哪些问题值得继续投入。

设计是一个险恶的问题

“险恶”不是说问题无法解决，而是目标、约束和可接受结果可能同时变化。设计者要先声明当前输入、输出、不可接受行为和观察窗口；否则一个看似合理的结构会把未说出口的假设藏进代码。

设计是个了无章法的过程（即使它能得出清爽的成果）

最终的类图或模块图常常很整齐，但得到它的过程可能包含类比、试错、删减和回退。复盘时不要把最后的形状伪装成唯一推导路径，应记录哪些假设被验证、哪些被放弃，以及哪一次实验改变了方向。

设计就是确定取舍和调整顺序的过程

设计决定既要比较方案，也要决定先消除哪一种风险。把数据格式、外部依赖和状态迁移等高代价决定提前做小实验，把低风险的命名和局部整理留到反馈之后，通常比追求一次性完整更有价值。

设计受到诸多限制

性能、团队技能、既有接口、部署环境、法规和交付时间都会限制候选方案。约束不是设计的敌人；把它们显式写出来，才能区分“原则上漂亮”与“在当前系统中可交付”。

设计是不确定的

需求语言可能含糊，运行时负载可能未知，第三方行为可能无法完全控制。与其假装确定，不如给每个高风险假设配一个最小验证动作，并约定什么结果会触发重审。

设计是一个启发式过程

启发式是经验规则，不是定理。它可以帮助我们提出“把变化封装起来”“优先组合”这样的候选方向，但必须同时写适用条件、反例和退出条件，避免团队把口诀当成证明。

设计是自然而然形成的

设计确实会从代码、测试、反馈和协作中逐步长出来，但“自然形成”不等于“无需负责”。每轮实现都应让某个假设变得更清楚；如果代码只增加复杂度而没有增加信息，就应该停下来整理边界。

5.2 关键的设计概念

“5.2 关键的设计概念”把评审焦点收束到复杂度、职责、层次和变化边界：不是追求抽象数量，而是让读者能从结构判断谁负责什么，以及哪种变化会被挡在边界之外。

软件的首要技术任务：管理复杂度

管理复杂度的第一步是识别来源。领域规则属于本质复杂度，重复转换、隐藏状态、过宽接口和不必要的依赖则常常属于 意外复杂度。设计不是消灭领域难题，而是不要让实现噪声遮住真正的难题。

理想的设计特征

理想设计让每个模块的责任容易说清，让变化只穿过必要的接口，让状态保持合法，让读者能从名称和结构推断意图。它不等同于抽象层越多越好：一层如果只增加跳转而没有保护合同，就在制造新的理解成本。

设计的层次

可以从系统边界、子系统、模块、类型、操作和局部算法逐层观察设计。上层决定职责与协作，下层决定表示与实现；跨层直接读写会让变化绕过中间合同，因此需要把越界路径当作审查信号。

5.3 设计构造块：启发式方法

“5.3 设计构造块：启发式方法”提供的是可检验的候选规则，而不是必须服从的口号；每条启发式都要绑定适用条件、反例、观察证据和退出条件，才不会制造新的仪式成本。

寻找现实世界中的对象

领域名词可以帮助发现候选对象，但不是每个名词都应变成类。先问它是否拥有状态、行为、身份或需要被单独验证，再决定它是对象、值、服务还是一条规则；这样可以减少把动词和临时标签硬塞进对象模型。

形成一致的抽象

抽象应在相似场景下保持相同的命名、输入和失败语义。若两个调用者都需要理解同一段隐藏转换，说明抽象没有真正收敛；把转换放回一个有明确合同的边界，读者才不必从每个调用点重新推理。

封装实现细节

封装不是把字段改成私有就结束，而是让对象通过构造和操作守住不变量。调用者只需要知道“能做什么、失败怎样表示、成功后保证什么”，不应依赖存储布局、缓存时机或内部步骤。

当继承能简化设计时就继承

继承适合表达稳定的“是一个”关系，并且子类型能遵守父类型的行为合同。如果子类必须关闭父类功能、暴露内部状态或覆盖大量实现才能工作，组合通常更容易隔离变化；选择继承前应先写一个可失败的替代方案。

隐藏秘密（信息隐藏）

信息隐藏 保护的不是神秘感，而是变化半径。接口暴露得越多，调用者越容易把偶然细节当成承诺；因此每个公开成员都应能回答“谁需要它、改变它会影响谁”。

找出容易改变的区域

变化热点可能来自业务政策、外部协议、数据格式、算法和部署配置。把热点包在边界里，再让稳定部分依赖抽象合同，变化就不必沿着所有调用路径传播。热点清单也应随新证据更新，而不是设计初稿写完就封存。

保持松散耦合

松散耦合 不是让模块互不相识，而是让依赖方向和数据责任可见。可以用参数对象、事件或端口减少直接依赖，但每种间接方式也要有明确的失败语义，不能只把耦合藏到框架配置里。

查阅常用的设计模式

模式是经过命名的解决方案形状，适合用来交流候选结构和权衡。先说明问题与约束，再问模式是否减少了当前风险；如果只是为了让代码看起来“像某个模式”而增加层次，模式本身就成了意外复杂度。

其他的启发式方法

其他启发式可以包括优先使用清晰的数据结构、让错误尽早出现、让状态迁移集中、让接口面保持小，以及让测试从公开行为进入。它们之间可能冲突，所以应在具体约束下比较，而不是把所有规则同时绝对化。

关于设计启发的总结

启发式的共同作用是缩小搜索空间：先给出一个可解释的候选，再用输入、边界和故障让候选承担预测责任。它们的价值来自减少返工和误解，而不是来自被背得更熟。

使用启发式方法的原则

使用启发式时写四件事：当前问题、采用的规则、可观察证据、退出条件。先预测改变哪个条件会影响哪个边界，再运行最小样本；如果规则不能产生可检查的差异，就暂时不要把它升级为团队标准。

5.4 设计实践

“5.4 设计实践”把抽象原则转成可以复核的工作回路：迭代、分解、上下而下与自下而上、原型、合作和记录共同把未知风险变成下一轮可以观察的证据。

迭代

迭代不是无计划地反复修改，而是每轮只扩大一小块可观察能力。每轮结束时回答“哪一个设计假设被确认、哪一个仍未知、下一轮要避免什么”，这样实现就成为设计反馈而不是设计的替代品。

分而治之

分解的目标是让每一块拥有清晰责任和可独立验证的边界，而不是把一个问题切成许多互相传递内部状态的小函数。分解后要检查组合成本：如果协调代码比领域规则还复杂，说明分法需要重新考虑。

自上而下和自下而上的设计方法

自上而下适合先建立职责和协作轮廓，自下而上适合从真实数据、协议或运行约束中发现不可忽略的细节。两者可以交替：用上层提出结构，用下层原型验证结构是否与现实相容，再回到上层调整边界。

建立试验性原型

试验性原型 应该有问题、输入、成功信号和停止条件。原型若没有明确的学习目标，就会悄悄变成另一条未经审查的生产路径。

合作设计

合作设计不是把决定交给投票，而是让不同读者分别指出职责、边界、失败路径和维护成本。让一位没有参与实现的人复述设计，如果他能指出状态所有者和重审条件，说明设计表达已经超过作者脑内上下文。

要做多少设计才够？

够不够取决于风险，而不是文档页数。不可逆的数据库、外部合同和安全边界需要更早更具体的设计证据；低风险局部实现可以在短反馈中形成。停止设计讨论的条件应是关键假设已有验证路径，而不是图画得足够漂亮。

记录你的设计成果

记录成果至少包含问题、候选方案、取舍、证据、未决假设、所有者和重审触发器。记录不是把每次思考都保存，而是让未来的维护者知道“当时为什么这样选，以及什么新事实会让它失效”。

5.5 对流行的设计方法的评论

“5.5 对流行的设计方法的评论”提醒我们比较方法的结果而不是崇拜名称：方法只有在更早暴露风险、缩短反馈或澄清边界时才有价值，否则新增的会议和产物也会成为意外复杂度。

流行方法可以提供共同语言、活动顺序和审查节奏，但方法名称不能替代对当前系统的理解。比较方法时看它是否让风险更早暴露、边界更清楚、反馈更便宜；若只增加会议和产物，却没有改变决策质量，就需要减少仪式。

更多资源

本章的资料边界由公开目录和出版者书目信息限定；现代工程资料只用于解释“如何验证边界”这一迁移问题，不把它们倒写成原书的具体论断。可继续查阅 Microsoft Press 官方书页、C++ Core Guidelines 与 OWASP Code Review Guide。

软件设计，一般性问题

一般性设计问题可以压缩为几个可回答的问题：对象是谁，谁拥有状态，哪些关系必须保持，什么最容易变化，失败如何被观察。问题越具体，候选结构越容易被小实验裁决。

软件设计理论

理论提供概念和比较框架，却不能替系统做决定。把理论中的原则翻译成当前输入、接口和验收例，再用一个边界样本检验；能改变行动的理论才真正进入设计工作。

设计模式

模式值得用于命名反复出现的结构，但模式名不是性能、可维护性或正确性的保证。采用模式后仍要检查依赖方向、异常传播、测试入口和删除成本，并保留不采用它的理由。

广义的设计

广义设计还包括数据迁移、部署、日志、权限、测试和协作方式。只画运行时模块而不写这些边界，系统仍可能在发布或维护时暴露未设计的部分。

标准

标准把“应该怎样做”变成可重复检查的约束，但标准也有适用范围、版本和例外。采用标准前记录它解决的风险与留下的成本；不能用“符合标准”代替对具体输入的验证。

关键点

设计的关键点是把复杂度留在必须理解的地方，把偶然复杂度挡在边界之外；用启发式生成候选，用原型与反例验证，用合作复核暴露假设，用记录保留决定与退出条件。最后点击实验的重置按钮，确认同一输入还能回到同一基线，这也是可重放性的最低检查。

故障诊断与误区

最小可重放实现

baseline = record(problem, constraints, owner, observation_window)
candidate = choose_boundary_and_heuristic(baseline)
evidence = run(normal_case, boundary_case, one_fault)
accept(candidate) only if evidence_and_reset_are_reproducible

这段伪代码表达本章的工作合同：先把问题和所有权说清楚，再让候选设计面对输入与故障，最后检查复位是否回到相同基线。它不是生产代码，也不替代针对具体系统的测试。

本章小结

设计是确定边界、管理复杂度和安排反馈的持续过程。把本质复杂度留给领域模型，把意外复杂度交给封装、抽象和简洁的接口；用启发式生成候选，用迭代、分解、原型和合作复核让候选承担证据；用记录保存决定与重审条件。完成本章后，你应能解释一个变化为什么停在某个边界，也能指出什么故障会迫使它重新设计。

练习与答案

资料边界

本章依据 《代码大全（第2版）》2006 年中文公开试读目录 核对本章正式单元与 41 个目录节点；Microsoft Press 官方页面 用于核对英文书目信息与出版范围；C++ Core Guidelines 与 OWASP Code Review Guide 只用于解释现代工程中的边界、审查和验证迁移。公开目录不能证明未公开正文的具体措辞、案例或作者判断，本页为独立重写的教学结构。