Item 31：将文件间的编译依赖降至最低

猜一猜：只把 Address 的一个 private 字段移到 PersonImpl，三种边界中哪些 translation units 会重新编译？先选一个方案，再用下面的证据核对。

从 Address 私有字段导致全库重编译开始

Person header 直接包含所有字段类型：

#include "address.hpp"
#include "date.hpp"
#include <string>
 
class Person {
public:
    Person(std::string name, Date birthday, Address address);
 
private:
    std::string name_;
    Date birthday_;
    Address address_;
};

Address 只增加一个 private cache，却会改变 address.hpp；person.hpp 包含它，所有包含 Person 的 translation units 都可能重编译。

Item 31 的原则是 Minimize compilation dependencies between files（将文件间的编译依赖降至最低）。目标不是让 include 数量好看，而是让 implementation change 不沿 public interface 扩散。

interface 与 implementation 应分离

Person 用户需要知道可调用 operations，不一定需要知道 name/address/date 怎样存储。

public header 泄漏 private by-value members 时，C++ access control 隐藏访问权限，却没有隐藏 layout/compile dependency。

需要额外间接层把 storage 从 public class layout 移走。

forward declaration 能声明 incomplete type

class Date;
class Address;
class PersonImpl;

compiler 可声明 pointer/reference 和只涉及它们的函数：

void printAddress(const Address& value);
Address* findAddress(PersonId id);

函数 definition 解引用、访问 member 或构造 Address 时仍需 include 完整定义。

何时必须完整类型

by-value data member 需要 sizeof/alignment，base class 必须完整，inline body 若调用 member 也需要 definition。

class Address;
 
class InvalidPerson {
    Address address_; // 错误：layout 需要完整 Address
};

pointer/reference 自身大小已知，因此可指向 incomplete type。

pimpl 建立 handle class

public Person 只保存 implementation owner：

// person.hpp
#pragma once
#include <memory>
#include <string_view>
 
class PersonImpl;
 
class Person {
public:
    Person(std::string_view name, const Date& birthday, const Address& address);
    ~Person();
 
    Person(Person&&) noexcept;
    Person& operator=(Person&&) noexcept;
 
    std::string name() const;
 
private:
    std::unique_ptr<PersonImpl> pImpl_;
};

Person layout 只包含固定大小 unique owner；Address/Date/container changes 不再改变 public layout。

unique owner 的 destructor 要放在完整类型可见处

unique_ptr<PersonImpl> 可以声明时指向 incomplete type，但默认 deleter 真正 delete 时需要 PersonImpl 完整。

// person.cpp
#include "person.hpp"
#include "person_impl.hpp"
 
Person::~Person() = default;
Person::Person(Person&&) noexcept = default;
Person& Person::operator=(Person&&) noexcept = default;

将 destructor inline/defaulted 在 header 可能过早实例化 delete 路径。move/copy operations 也应按 compiler/library 行为放在 source 并测试。

handle class 要明确 value 与 ownership 语义

unique pimpl 默认让 Person 不可复制。若 Person 应是 value type，需要实现 deep copy：

Person::Person(const Person& rhs)
    : pImpl_(std::make_unique<PersonImpl>(*rhs.pImpl_)) {}
 
Person& Person::operator=(Person rhs) {
    swap(rhs);
    return *this;
}

若应共享 identity，可用 shared owner，但要明确 thread safety、copy-on-write 与 cycle。不能让 pointer 选择偶然决定 public semantics。

copy-and-swap 还能提供 strong assignment guarantee，但成本需测量。

inline forwarding 会重新引入实现依赖

Person operations 通常在 source 中转交：

std::string Person::name() const {
    return pImpl_->name();
}

若把 body 写进 header，compiler 需要看见 PersonImpl member declarations，pimpl 边界被打穿。

LTO 可在构建时跨 source 优化 forwarding，不必为内联永久泄漏 header dependency。

interface class 隐藏全部 concrete representation

另一策略是 pure abstract interface：

class Person {
public:
    virtual ~Person() = default;
    virtual std::string name() const = 0;
    virtual Date birthday() const = 0;
 
    static std::unique_ptr<Person> create(
        std::string_view name,
        const Date& birthday,
        const Address& address);
};

factory 在 source 中构造 concrete implementation，客户只依赖 abstract API。

它适合 runtime replaceability/plugin，但引入 virtual dispatch、heap allocation 和 pointer ownership。

handle class 与 interface class 的取舍

handle class 保留普通 value-like syntax、固定 public layout 和非 virtual API；interface class 支持多个 implementations 和 runtime polymorphism。

不要为了减少 rebuild 把所有小 value types 都 heap/polymorphic 化；间接访问、allocation、cache locality 与复杂 ownership 是真实成本。

标准库类型不要自行前置声明

不能在 namespace std 手写 class string;；标准类型可能是 template specialization/alias，实现声明由标准 header 负责。

可在 public API 使用 string_view/span 等轻量 vocabulary types，但仍 include 对应标准 header。

前置声明仅用于自己控制且声明形式稳定的 user types。

include what you use 与最小依赖并不冲突

header 必须 self-contained：单独 include 时能编译；不应依赖客户先包含某个文件。

最小依赖指移除不必要完整定义，不是制造隐式 include order。

source file 仍应显式 include implementation 真正使用的 headers。

modules 减少文本解析但不取消语义依赖

C++ modules 可把 exported interface 与 private implementation partitions 分开，避免每个 TU 重复预处理相同 headers。

但 exported by-value field/layout、inline/template body 和 ABI 变化仍会使 importers 语义依赖；module cache 也需重建。

pimpl/interface separation 在 modules 时代仍用于 ABI 和变化隔离，不只是加速 parser。

ABI 稳定需要定义可变范围

pimpl 让 Person public sizeof/alignment 稳定，新增 Impl fields 不改变客户 layout。它不能自动保证 vtable、exception ABI、allocator 和 semantic compatibility。

版本测试要同时检查 ABI diff 和 behavior contract。

用 include graph 与触碰实验验收

先预测修改 PersonImpl 一个 private field 会重编译哪些 translation units，再执行验证：

• include graph/-ftime-trace 找出 public header 重依赖和解析热点。
• touch Address implementation/header，统计增量重编译 targets。
• header isolation tests 验证每个 public header 自包含。
• compile-negative tests 确认 public header 不能访问 incomplete Impl members。
• pimpl destructor/copy/move 在只 include person.hpp 的客户 TU 编译链接运行。
• ABI checker 比较 Person sizeof/alignment/symbols 在 Impl 修改前后稳定。
• interface factory tests 覆盖 create failure、virtual destruction 和多个 implementations。
• runtime benchmark 测量 allocation、indirection、virtual dispatch 与 cache locality 成本。
• modules on/off 构建比较 parser 时间，同时验证 semantic dependency 未被误判为消失。

重构成功的证据是实现变化只重编译拥有实现的少量 targets，而不是 include 数量下降。

小结

• public header 包含 implementation definitions 会让小改动沿 include graph 形成 rebuild blast radius
• forward declaration 只提供 incomplete type 名称；by-value layout、inheritance 和 member access 需要 complete type
• pimpl handle class 以固定大小 owner 隔离表示，destructor/copy/move 应在完整 Impl 可见处定义
• interface class 加 polymorphic factory 完全隐藏 concrete representation，代价是 virtual/heap/ownership
• self-contained header 与最小依赖并不冲突；标准库类型必须包含标准 header
• modules 减少 textual parsing，但 layout、template、inline 和 ABI 的 semantic dependency 仍存在