第 8 章：下拉复杂度
系列：软件设计的哲学 · 第 8/22 章
全书导读：00-overview.md
一句话总结
把复杂度从接口拉进实现——特例、分支、性能权衡应由模块内部消化，而非甩给每个调用方。
核心观点浓缩
- 下拉（pull down）：若某知识只对一个模块真正重要，就不该出现在接口上
- 接口上的
if/flag常意味着复杂度上浮，每个调用方都要懂分支 - 实现可以复杂，只要常见路径对调用方简单
- 与深模块、信息隐藏同源：简单接口是设计选择，非能力不够
- 例外：调用方确实需要控制时，才应暴露选项——且应用默认值覆盖 90% 场景
关键概念 / 金句
| 上浮信号 | 下拉做法 |
|---|---|
调用方传 retryCount | 模块内建重试策略 |
| 调用方处理半开连接 | 连接池内部恢复 |
| 枚举 12 种错误码给 UI | 映射为「可重试 / 致命」两类 |
「接口上的每一个参数，都是调用方的永久负担。」
本章在全书中的位置
第 8 章是深模块的操作手册：具体判断「这个复杂度该留哪一层」。紧接第 9 章横向拆合，完成模块设计核心篇（第 4–9 章）。
个人思考与启发
云上传失败若要求 UI 判断 HTTP 状态码、OSS 错误 XML，复杂度在上浮。应在 CloudUploadService 内下拉为 UploadResult::Retryable / Fatal，UI 只决定提示文案。
与《程序员修炼之道》对照
- 曳光弹端到端跑通后，用下拉复杂度收口临时散落在 UI 的分支
- 「维护与复用」：可复用性来自接口稳定，来自内部吞掉变化
- 配置数据外置（修炼之道）是下拉的一种：把变体从代码挪到数据
重点与注意
重点：默认把特例往里收，直到有明确理由才暴露。
重点：接口参数少 ≠ 功能少；往往相反。
注意：下拉后实现变复杂，需测试与注释支撑（第 12–15 章）。
注意：性能敏感路径若必须暴露控制，用分层接口（简单默认 + 高级可选）。
导航：第 7 章 不同层不同抽象 · 下一篇：第 9 章 拆还是合