Skip to content

第 7 章:不同层不同抽象

系列:软件设计的哲学 · 第 7/22 章
全书导读:00-overview.md


一句话总结

相邻层应提供不同抽象级别;若一层只是下一层的透传,该层就在浪费复杂度预算。


核心观点浓缩

  • 分层目的:上层用更高层概念工作,不必了解下层细节
  • 透传方法(pass-through):接口几乎原样转发,是浅层红旗
  • 相邻层应可区分:读两层 API,能否说出各自职责?
  • 层间依赖应向下;下层不应知上层业务语义
  • 好分层像楼梯:每踏抬高一级抽象,而非平行复制

关键概念 / 金句

红旗含义
Pass-throughService.save() 仅调用 Dao.save(),无新语义
模糊边界UI 与业务都操作同一 DTO 字段,分不清谁负责校验
下沉泄漏底层 API 出现「订单」「患者」等业务词汇

本章在全书中的位置

第 7 章把模块思想扩展到架构纵向切分。与第 5 章信息隐藏、第 9 章拆合共同回答「系统应长成什么形状」。


个人思考与启发

UI → Session → VTK 三层若都直接操作 vtkPolyData 顶点,等于没有渲染抽象层。应在 Session 暴露「扫描结果」「导出网格」等领域对象,VTK 细节留在 JMRender。


与《程序员修炼之道》对照

  • 分而治之与分层同源;修炼之道偏问题分解,本书强调抽象级差
  • 「黑板架构」各 agent 通过高层协议协作,是不同抽象共存的范例
  • 避免双向依赖:与得墨忒耳律、层间单向依赖一致

重点与注意

重点:每层回答不同层次的问题;两层答同一问题则合并或重新定义。
重点:消灭无增值的透传层
注意:分层不是文件目录 KPI;同一 repo 内也可逻辑分层。
注意:跨层调试需要追踪 ID / 关联上下文,勿用「全员访问全局单例」偷懒。


导航第 6 章 通用模块更深 · 下一篇:第 8 章 下拉复杂度

基于 VitePress 强力驱动 | 记录技术与生活