读前：这一章要回答什么

第 2 章把复杂性拆成三种症状：改一处要动很多地方（变更放大）、要记住的东西太多（认知负担）、不知道自己不知道什么（未知的未知）。从这一章开始，书转向"怎么办"，而第一个、也是全书最核心的工具就是模块化设计：用接口把实现的复杂性挡在模块内部。

这一章的全部内容可以压缩成一个比喻和一个判断标准：把模块想成一个矩形，顶边是接口，面积是功能。顶边越短、面积越大，模块越"深"，越值得存在。后面几章（信息隐藏、通用模块、分层、把复杂性往下拉）讲的其实都是"怎样把模块做深"。

核心观点

心智模型：把模块画成矩形

先用书里的比喻建立直觉：把一个模块画成矩形，顶边长度代表接口的复杂度（使用者要学多少东西），面积代表它实现的功能（替使用者扛下了多少复杂性）。

"接口复杂度"不是签名的字符数，而是使用者为了正确使用必须知道的条目数，包括那些只写在文档里的约束。下面这个小工具把几个模块的接口逐条列出来，按条目数画顶边、按实现规模画高度，右侧列出被藏起来的关注点。切换预设，然后打开"只看常见用法"，观察顶边怎么变化。

矩形高度按实现规模的对数画（规模跨了好几个数量级）；条目数和规模都是本站为了比较而做的粗略估计，用来建立直觉，不是精确度量。真正重要的问题是：这个模块替使用者藏起来的东西，是否远多于它要求使用者学的东西？

接口远不止签名

书中强调：只要使用者必须知道某个信息才能正确使用模块，这个信息就属于接口，不管它有没有出现在签名里。C 标准库里有一个很好的反面教材：

char *strtok(char *str, const char *delim);

签名只有两个参数，但想正确使用它，你还得知道：

1. 第一次调用传字符串，之后要传 NULL 才是"继续切同一个字符串"；
2. 它会把原字符串里的分隔符改写成 '\0'，所以不能传字符串字面量；
3. 它用一个隐藏的静态变量记位置，所以不能嵌套切两个字符串，也不能在多线程里用；
4. 连续的分隔符会被当成一个，空字段会被跳过。

四条非正式接口，每一条都曾让很多人踩坑。后来 POSIX 增加了 strtok_r，把隐藏状态变成显式参数，第 3 条就从"必须记住的约束"变成了"签名里看得见的参数"。非正式接口仍然是接口，只是编译器帮不了你。所以第 12、13 章会花很大篇幅讲接口注释。

一个原创例子：类炎与深类

下面的场景在业务代码里很常见：读取 INI 配置。左边按"每个类只做一件事"拆成了 5 个类；右边只有一个类。先只看调用方的代码，体会使用者要学多少东西。

auto text  = FileLoader().load("app.ini");
auto lines = LineSplitter().split(text);
auto clean = CommentStripper('#', ';').strip(lines);  // 注释符号由调用者决定？
auto pairs = KeyValueParser('=').parse(clean);
auto table = SectionGrouper().group(pairs);
int port = std::stoi(table["server"]["port"]);        // 不存在时？非数字时？

// 一份已解析的配置。load 失败（文件不存在、语法错误）时抛 ConfigError，
// 错误信息里带文件名和行号。
class Config {
public:
    static Config load(const std::string& path);
    std::string getString(std::string_view key, std::string_view def = "") const;
    int  getInt(std::string_view key, int def) const;   // 值不是整数时抛 ConfigError
    bool getBool(std::string_view key, bool def) const; // 接受 true/false/yes/no/1/0
};

auto cfg = Config::load("app.ini");
int port = cfg.getInt("server.port", 8080);

注意"改之后"的实现并不比"改之前"简单，可能更长。深模块的意思不是"代码少"，而是"使用者需要知道的少"。这一点第 8 章会推得更远：宁可实现复杂，也要让接口简单。

浅类与浅方法：没有收益的接口

浅的可以是一个方法，也可以是整个类。书里（4.5 节）举的是学生项目中一个只有一行的私有方法。下面这个类的每个方法都是这样的浅方法，合起来就是一个浅类。它常见于"不许直接用标准容器，要包一层有业务含义的类型"的规范：

// 订单里的商品列表
class ItemList {
public:
    void addItem(const Item& item)      { items_.push_back(item); }
    void removeLastItem()               { items_.pop_back(); }
    size_t getItemCount() const         { return items_.size(); }
    const Item& getItem(size_t i) const { return items_[i]; }
private:
    std::vector<Item> items_;
};

四个方法各自把 std::vector 的一个操作换了个名字。使用者要多学一套名字，可 vector 的规矩一条也没少：空列表上调用 removeLastItem 是未定义行为，getItem 不检查越界，这些照样得知道；原本现成的迭代器、范围 for 和标准算法反而用不了了。它增加了一个要学的接口，却没有替谁隐藏任何东西。要么直接用 std::vector<Item>，要么让这个类真正承担职责（比如合并同一商品的数量、维护"每单最多 100 件"的约束），它才值得存在。

这和下文"链表天生就浅"不是一回事：链表自己提供了基本功能，只是杠杆小；ItemList 是在一个现成的接口外面又包了一层，自己没有添加任何功能。

边界与反方：什么时候别生搬硬套

练一练

下面三道题来自训练场。先自己判断再看解析，答题记录会进入间隔复习。

再加两道，取材于读者讨论组（对应上面"边界与反方"里的"讨论组"一栏）：

动手：项目任务

本站的 minikv 是一个能跑、有测试、但按"战术式"风格写成的 C++ 键值存储。读完本章和第 5 章后，去做任务 m01：在它的日志读写代码里找出一串浅类、一个参数过多的 open，以及被好几个类同时知道的记录格式，把它们重构成更深的模块，测试保持全绿。

cd project/minikv && make test

自测题

小结与读后一句话

• 模块化的目标是减少模块间的依赖；接口就是"别人用你时必须知道的一切"，非正式部分往往比签名大。
• 好的抽象只省略不重要的细节；漏掉重要细节会得到虚假的抽象。
• 深模块用简单的接口提供强大的功能；浅模块（接口≈实现）是红旗。
• "类和方法越小越好"会导致类炎；该追求的是深度，不是小。
• 让常见用法最简单：罕用功能可以有，但不要挡在常用路径上。

接下来的第 5 章回答一个自然的问题：怎样才能把模块做深？答案是信息隐藏。同时它也会给出一个和深度密切相关的红旗：信息泄漏。

读后一句话：用你自己的话写下这一章最重要的一个观点，最好结合你写过的某段代码。