第 6 章：通用模块更深
系列：软件设计的哲学 · 第 6/22 章
全书导读：00-overview.md
一句话总结
在合理范围内，更通用的模块往往更深——专用逻辑应在上层组合，而非写死在底层。
核心观点浓缩
- 通用模块：接口表达概念（读文件、发请求），非单一业务场景
- 专用模块常把业务规则塞进底层，接口却为特例膨胀，又浅又脆
- 通用性↑ 通常带来复用与更简单接口；但过度通用会模糊语义
- 第 2 版强调：在「太窄」与「太宽」间找平衡，红旗是调用方仍要懂很多
- 专用代码应靠近最了解需求变化的层（通常上层），非堆在基础设施里
关键概念 / 金句
| 倾向 | 结果 |
|---|---|
| 合理通用 | read(offset, len) 服务多种调用模式 |
| 过度专用 | readUserProfileForLoginPage() 难以复用 |
| 过度通用 | execute(Operation op) 调用方不知能传什么 |
本章在全书中的位置
第 6 章深化第 4 章「深模块」：为何有些接口天然更深——因抽象层次更高。与第 7 章分层、第 8 章下拉复杂度共同构成模块设计三角。
个人思考与启发
文件 IO 插件若只为 STL 写死路径规则，OBJ 来了就复制粘贴改。更早抽象成「网格导出器」接口，专用格式只做 serializer，深度与扩展性同时改善。
与《程序员修炼之道》对照
- 元程序设计（用数据/配置驱动）是通用化的一种，减少硬编码特例
- 「易于改编」要求接口对未来变化留余地，与合理通用同源
- 避免过早抽象：通用性应由第二、第三个用例验证，非臆想（见修炼之道「你不需要它」）
重点与注意
重点：通用性服务于接口简单 + 实现强大，不是炫技。
重点：业务特例往上层推，基础设施往下沉。
注意：三个用例前别大抽象；与 YAGNI 不矛盾。
注意：过度通用的「万能参数对象」是浅模块的新马甲。
导航：第 5 章 信息隐藏与泄漏 · 下一篇：第 7 章 不同层不同抽象