第 4 章：模块应深
系列：软件设计的哲学 · 第 4/22 章
全书导读：00-overview.md
一句话总结
深模块用极简接口封装强大实现；浅模块让调用方仍要懂大量细节——后者是复杂度的主要来源之一。
核心观点浓缩
- 模块深度 = 接口简单 vs 实现强大 的对比，非代码行数
- 浅模块：接口信息量 ≈ 实现信息量，拆分反而增加调用编排成本
- classitis：为「类要小」机械拆分，制造大量浅接口
- 深模块降低认知负荷：调用方只记少量概念即可正确使用
- 判断标准：常见用法是否简单？难的部分是否藏在模块内？
关键概念 / 金句
| 类型 | 特征 |
|---|---|
| 深模块 | open() 背后处理权限、缓存、重试 |
| 浅模块 | 五个 setter + init() 才完成一件事 |
| Classitis | 拆类 KPI 导致接口泛滥 |
本章在全书中的位置
第 4 章是全书心脏概念，第 5–8 章都是「如何做到更深」的展开。读懂深/浅，后文信息隐藏、通用模块、下拉复杂度才有锚点。
个人思考与启发
评审时把「这个 public 方法调用方必须懂什么？」写在 PR 描述里。若答案超过三句，考虑把编排收进模块内。VTK 管线里对应用层暴露逐步 Filter 组合，往往是浅模块；封装成 ReconstructAndExport() 一类入口则更深。
与《程序员修炼之道》对照
- 「解耦与得墨忒耳律」追求低耦合，但过度拆分类会制造浅模块——耦合低了，复杂度却高了
- 可组合性重要，但组合应在深接口之上，而非强迫业务层拼零件
- tracer bullets 验证端到端后，应用战略式把管线收成深模块
重点与注意
重点：深模块是全书第一设计目标；行数、类数都不是 KPI。
重点：用「调用方需知多少」衡量接口，而非 UML 美观度。
注意：深 ≠ 巨型上帝类；靠信息隐藏（第 5 章）维持边界清晰。
注意：测试友好与深度不矛盾——可测内部实现，但公共 API 仍应简洁。
导航：第 3 章 能跑还不够 · 下一篇：第 5 章 信息隐藏与泄漏