读前：这一章要回答什么

第 4～6 章从"一个模块"的角度讨论深度：接口要短、要藏住知识、要通用一些。第 7 章换个角度，看上下相邻的模块：软件是一层叠一层搭起来的，高层用低层提供的设施。作者的判断标准很简单：在设计良好的系统里，沿着一次操作往下走，每经过一次方法调用，抽象就换一次。如果相邻两层说的是同一套话，这一层多半没有挣回它自己的成本。

这一章列出了"抽象没换"的几种具体表现：透传方法、浅装饰器、照搬内部表示的接口、透传变量，并给出对应的改法。它也是第 9 章"合在一起还是分开"的前奏：本章讨论的是上下两层之间的边界，第 9 章讨论的是任意两段代码之间的边界。

核心观点

心智模型：顺着一次调用往下走

判断分层好不好，最直接的办法是挑一个操作，沿着调用栈往下走，在每一层问一句：这一层用什么"词汇"描述这件事？下面两条调用链做的是同一件事（保存一个键值对），左边每层都换了说法，右边四层说的是同一句话。

书中用文件系统（文件 → 块缓存 → 设备驱动）和 TCP（可靠字节流 → 尽力而为的有界数据包）说明左边这种情况。注意右边的问题不在于"层多"，而在于层与层之间没有任何东西被藏起来。如果 service 那一层负责鉴权和事务，它就有了自己的抽象，不再是传话筒。

透传方法：职责没分清的信号

透传方法（pass-through method）的问题有三层：它给类增加了接口却没增加功能，所以类变浅；它和下层方法签名绑在一起，下层一改它就得跟着改；最重要的是，它说明两个类的职责有重叠，没人说得清某项功能到底归谁。作者给出的判断原则是：

the interface to a piece of functionality should be in the same class that implements the functionality.— 第 7.1 节

书中的例子是学生编辑器项目里的一个文档类，15 个公开方法里 13 个是透传（7.1 节）。下面换一个服务端的例子：一个支持断点续传的上传会话，内部用一个临时文件存数据。切换标签看现状和三种改法：

// 一次上传会话
class UploadSession {
public:
    void append(ByteView data)     { file_.append(data); }
    void sync()                    { file_.sync(); }
    uint64_t size() const          { return file_.size(); }
    std::string path() const       { return file_.path(); }
    bool expired(TimePoint now) const { return now > deadline_; }
private:
    TempFile file_;
    TimePoint deadline_;
};

// 调用方：断点续传的逻辑散在 HTTP 处理函数里
if (req.offset != s.size()) return resp.conflict(s.size());
s.append(req.body);
if (s.size() - lastSynced > (8u << 20)) { s.sync(); lastSynced = s.size(); }

struct UploadSession {
    TempFile& file();              // 调用者直接对文件读写
    bool expired(TimePoint now) const;
};

s.file().append(req.body);

// 一次可续传的上传。内部用临时文件，调用方看不到。
class UploadSession {
public:
    // 接收一段数据。offset 必须等于已收到的字节数，否则不写入，
    // 返回已收到的字节数，供客户端从那里重发。每 8MiB 自动落盘一次。
    std::optional<uint64_t> receive(uint64_t offset, ByteView data);
    // 收完：校验摘要，原子地移动到 finalPath。失败抛 UploadError。
    void finish(const Digest& expected, const std::string& finalPath);
    bool expired(TimePoint now) const;
private:
    TempFile file_;
    // ……
};

// TempFile 只被上传会话使用，两者分不开时干脆合成一个类
class Upload {
public:
    std::optional<uint64_t> receive(uint64_t offset, ByteView data);
    void finish(const Digest& expected, const std::string& finalPath);
private:
    int fd_;
    std::string tmpPath_;
    uint64_t received_ = 0, synced_ = 0;
};

三种改法的共同点：改完以后，每个类都有一组不同且自洽的职责，类之间不再需要互相转交。选哪一种，取决于上层有没有属于它自己的、和下层不同的抽象可以提供。

签名相同什么时候没问题

作者在 7.2 节划了一条清楚的线：签名相同不要紧，要紧的是每个方法都贡献了有用且不同的功能。两类常见的合理情况：

• 分派器（dispatcher）：根据参数选择交给哪个方法处理，然后把参数转过去。签名和目标方法一样，但"选择"本身就是功能，有时还相当复杂（例如 Web 服务器按一组规则匹配 URL）。
• 同一接口的多种实现：比如各种磁盘驱动。它们处在同一层、彼此不调用，学会一个就会用其他的，反而降低了认知负担。

装饰器：最容易制造透传的模式

装饰器（decorator，也叫 wrapper）接过一个已有对象，提供相同或相近的 API，在转交时顺便加点功能。它的初衷是把特殊扩展和通用核心分开，但作者认为装饰器类往往很浅：为一点新功能写一大堆转交，用多了就是一堆浅类（第 4 章的 Java I/O 就是这么来的）。写装饰器之前，用自己的话记住这四个替代方案：

1. 直接加进底层类：新功能比较通用、和底层逻辑相关、或者大多数使用者都会用时。
2. 和用途放在一起：新功能只服务某个具体场景时，放进那个场景的代码里。
3. 并入已有的装饰器：一个深一点的包装，好过好几个浅包装。
4. 独立实现：它真的需要包住原对象的全部功能吗？书中的例子是滚动条，多半可以和窗口分开实现。

作者承认包装器偶尔有用：系统要用一个改不了接口的外部类，又要求它符合系统自己的接口，这时用一层包装来翻译。但也说这种情况很少见。

接口不该照抄内部表示

"不同层，不同抽象"在单个类内部也成立：接口的抽象应该和内部表示不同。如果接口只是把存储结构原样暴露出去，类就不会深，原本该由类处理的逻辑会散落到每个调用方。书中的例子是编辑器的文本类：内部按行存储，接口却应该按字符和任意范围来插入、删除（7.4 节，第 6、8 章也反复用到它）。下面是一个服务端常见的版本：

class TokenBucket {
public:
    double tokens() const;           void setTokens(double t);
    TimePoint lastRefill() const;    void setLastRefill(TimePoint t);
    double ratePerSec() const;
    double capacity() const;
};

// 每个需要限流的地方都有一份这样的代码
auto now = Clock::now();
double dt = std::chrono::duration<double>(now - tb.lastRefill()).count();
tb.setTokens(std::min(tb.capacity(), tb.tokens() + dt * tb.ratePerSec()));
tb.setLastRefill(now);
if (tb.tokens() < 1) return reject(req);
tb.setTokens(tb.tokens() - 1);

// 令牌桶限流器，线程安全。
class RateLimiter {
public:
    RateLimiter(double ratePerSec, double burst);
    // 有足够令牌时扣除 cost 个并返回 true；否则不扣除，返回 false。
    bool tryAcquire(double cost = 1);
};

if (!limiter.tryAcquire()) return reject(req);

透传变量：一个值穿过整条调用链

透传方法是"方法在层之间重复"，透传变量（pass-through variable）是"参数在层之间重复"：一个值从入口一路往下传，路径上的大多数函数都用不到它，却都得在签名里写上它。后果是两个：中间每一层都被迫知道它的存在；以后再加一个这样的变量，整条路径上的签名都要改一遍。

书中的例子是一个数据中心服务的证书参数（7.5 节，图 7.2）。下面换成一个键值存储：只有最底层的 LogWriter 关心 fsync 策略，但它是从 main 里解析出来的。切换四种做法，再打开"再加一个变量"，看看每种做法要改多少地方。

作者最常用的是 context 对象，但对它的评价相当克制：context 里的变量仍有全局变量的大部分缺点（看不出某个字段为什么在、在哪里被用），不加约束会变成制造隐蔽依赖的杂物袋，还可能有线程安全问题（最好让字段不可变）。然后作者说：

Unfortunately, I haven't found a better solution than contexts.— 第 7.5 节

把本章收拢成一张账：净收益

7.6 节把整章归结为一句话：每个设计元素（接口、参数、函数、类、定义）都要让开发者多学一样东西，它必须消除比这更多的复杂性才划算。透传方法、浅装饰器、透传变量的共同问题，都是"让人学了，却没替人藏住什么"。拿本页出现过的例子记一笔账：

这张表的用法：下次你想加一层包装、一个 Manager、一个"为了以后扩展"的接口时，先在脑子里把这一行填出来。第三列写不出东西，就别加。

边界与反方

练一练

下面三道题来自训练场：一道识别透传、一道"看起来像透传其实不是"、一道透传变量的取舍。

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

动手：项目任务

minikv 里有一个典型的"传话层"：存储引擎外面套了一层几乎只做转交的类，还有一个写入选项从命令处理层一路穿过好几层方法的签名，只在最底层的日志写入处才被用到。这个任务要你先用本章的问题判断那一层有没有自己的职责，选一种改法消除透传方法，再决定透传变量用哪种方式处理，并说出你接受了什么代价。

cd project/minikv && make test

自测题

小结与读后一句话

• 好的分层里，每过一层抽象就换一次；相邻层抽象相似是警告。
• 透传方法让类变浅、制造依赖、暴露职责不清；改法：让调用者直接用下层、重新分配职责、或合并。
• 签名相同本身没问题，只要每个方法都贡献了不同的功能（分派器、多种实现）。
• 装饰器容易浅：先考虑加进底层、放进用途、并入已有包装、独立实现。
• 接口不该照抄内部表示，两者的差别就是类的价值。
• 透传变量可以用共享对象、全局变量、context 对象消除；context 最常用，但并不理想。
• 一切都归结为净收益：每个设计元素都要消除比它带来的更多的复杂性。

第 8 章接着回答一个相关的问题：当复杂性无法消除时，该由哪一层来承担？作者的回答是"往下拉"：宁可让模块的实现复杂，也别把问题推给上层。

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