如何把系统拆成模块 · 信息隐藏

一句话

Parnas 指出：把系统拆成模块，不该按「处理步骤 / 流程图」来切，而应按信息隐藏（information hiding）——先列出「最可能改变的设计决定」，让每个模块各藏一个这样的「秘密」，只通过一个尽量少暴露内部的接口与外界打交道。这样改动被局限在单个模块内、团队能独立开发、模块也各自可独立理解。这篇短文是封装、抽象数据类型、面向对象、乃至现代 API / 微服务边界的思想源头。

Glossary · 术语表

坐标

作者 David Parnas，写于卡内基梅隆大学，发表在 1972 年 12 月的《ACM 通讯》（CACM）。它上承 1960 年代对「结构化编程」「模块化」的讨论（Dijkstra 的《Go To 有害》正是同一波思潮），却把「模块化」从一句口号变成一条可操作的判定准则；下启 1970 年代的抽象数据类型（Liskov 等）、1980 年代的面向对象，以及 Parnas 本人后续的「uses 层次」（1979）与「程序族」思想。它常被列为软件工程被引最多、影响最深的文章之一。

问题与动机

到 1970 年代初，「把大程序拆成模块」已被公认是好事——能分工、能各自编译调试、能替换。但当时人们说的「模块化」只到「切成几块」为止，几乎没人回答「按什么标准切」。而 Parnas 敏锐地看到：拆法不同，收益天差地别。同样是拆成模块，一种拆法让系统好改好分工，另一种拆法让它处处掣肘。

他用一个小系统（KWIC 索引）当靶子，摆出两种都「看起来合理」的拆法，逐条比较它们在可改性、可分工、可理解上的表现，从而逼出真正该用的准则。他要反对的，正是当时最流行、最「自然」的那种拆法——按流程图的处理步骤切。

核心思想 / 方法

靶子：KWIC 索引系统

任务很简单：给一堆文字行，输出它们所有循环移位、并按字母序排列。比如「the quick fox」会生成「quick fox the」「fox the quick」等，全部行的所有移位混在一起排序输出。麻雀虽小，够用来对照两种拆法。

拆法一：按处理步骤切（大多数人的做法）

照着数据的流动，一步一个模块：①输入（读入并存进内存）→ ②循环移位（生成所有移位）→ ③字母排序 → ④输出 → 外加一个 ⑤主控 管调度。干净、直观、和流程图一一对应。

但有个隐患：这五块都直接读写同一份内存里的数据，都得知道「行、字、字符到底怎么存」。输入模块决定了把字符打包存（比如四个字符塞一个机器字省内存），那么移位、排序、输出模块全都得照这个格式去读。存储格式这个决定，被五个模块共享着。

拆法二：按「秘密」切（信息隐藏）

Parnas 的替代方案，起点完全不同——不看流程，先列「难做的、或以后最可能改的设计决定」，每个决定单独封进一个模块，对其余模块隐藏起来。于是同一个 KWIC 拆成：

• 行存储模块：藏「行、字、字符究竟怎么存」。对外只给 取第 i 行第 j 字第 k 个字符 之类的函数——别人取字符，不知道也不关心它是打包存还是一字一格。
• 循环移位器：藏「所有移位是预先算好存起来，还是用到时现算」。对外只给「第 i 个移位的第 j 个字」这样的函数。
• 字母排序器：藏「用什么排序算法、是一次性全排还是按需找」。对外只给「有序序列里的第 i 项」。
• 输入 / 输出 / 主控：各藏外部数据格式与调度细节。

关键差别一句话：拆法一的模块之间靠「共享一份数据结构」联系，接口把内部表示暴露无遗；拆法二的模块之间只靠「一组函数」联系，接口尽量不透露里面是怎么做的。每个模块都是一个黑盒，外面看得见的只有窗口。

为什么第二种更好：三条判据

① 可改性（changeability）。想换存储格式？拆法一里四个模块全得动；拆法二里改动只落在「行存储模块」内部，接口不变，别人无感。同理，想把「移位预先全算好」改成「用到时现算」以省内存，拆法二里只动循环移位器一家。把「会变的决定」和「依赖它的代码」隔开，是这条准则的全部要害。

② 可独立开发（independent development）。拆法二里模块之间只需事先约定接口（函数长什么样、行为如何），各队就能关起门各写各的实现，几乎不用互相打听内部；拆法一里大家共享数据结构，任何一方改动内部都要惊动别人，协作成本高。

③ 可理解性（comprehensibility）。拆法二里每个模块能被单独读懂、单独验证，因为它的行为由接口完整描述，不必先搞懂别的模块的内部。

Parnas 特别澄清两点，都很反直觉：其一，「模块」不是「流程图上的一步」，而是一份「职责的分派」——是「谁来负责保守哪个秘密」。其二，该被隐藏的往往不是「细枝末节」，而恰恰是那些「难的、或早晚要变的核心设计决定」；接口要设计得尽量少暴露内部，暴露越少，日后越自由。

关键结果

这是一篇论证性（而非实验）的论文，它的「结果」是那张对照表：同一个 KWIC 系统，两种拆法在可改性、可分工、可理解三项上高下立判——按步骤切的版本，一个存储决定的改动会波及全部模块；按秘密切的版本，同样的改动被关在单个模块里。结论掷地有声：决定模块化好坏的，不是「切了没有」，而是「按什么标准切」；正确的标准是信息隐藏，而不是流程图。他也正面回应了效率顾虑——隐藏实现看似要多绕一层函数调用，但接口是设计约定、不等于必须用低效的子程序调用实现，完全可以在保持隐藏的前提下高效落地。

为什么重要 / 影响

这篇短文把「模块化」从口号变成方法论，几乎定义了此后半个世纪的软件结构思想：

• 封装与抽象数据类型：把数据和操作它的函数打包、藏起内部表示——正是信息隐藏的直接落地，1970 年代经 Liskov 等发展成抽象数据类型。
• 面向对象：class 用 private 字段 + public 方法把「表示」锁在里面，就是信息隐藏的语言级实现；「针对接口编程，而非实现」是它的口头禅版本。
• 现代边界无处不在：库的 API、微服务的接口契约、操作系统的系统调用、硬件的指令集——凡是「稳定接口 + 可替换实现」的地方，用的都是同一条准则。
• 它也开启了 Parnas 本人的后续经典：「uses 层次」（怎么组织模块间的依赖）与「程序族」（为「会变」而设计一整族程序）。

局限与批评

• 要「猜对什么会变」：整条准则的成败押在「预判哪些决定会变」上。猜错了——把其实稳定的东西藏起来、或漏掉真正会变的——就白费甚至有害；这与「别过度设计、YAGNI」的告诫存在张力。
• 可能带来开销与过度抽象：多一层接口/间接调用有性能与复杂度成本（现代内联/编译优化已大幅缓解，但设计上仍可能为「万一」堆出过多抽象层）。
• 只给了单个准则，没给整体结构：如何组织众多模块之间的依赖关系、避免环、分层，本文未答——Parnas 自己后来用「uses 关系」「程序族」补上。
• 抽象会泄漏：接口再干净，性能特征、错误行为等仍可能「漏」出实现细节，使用者被迫了解内部；信息隐藏是理想，现实中难做到绝对。
• KWIC 是玩具例子：用一个小系统说清了原理，但把准则用在超大系统上，还需要额外的组织手段（分层、依赖管理、团队边界）配合。

要点