Item 40：审慎使用 multiple inheritance

从一个无法决定的 checkOut 开始

class BorrowableItem {
public:
    void checkOut();
};
 
class ElectronicGadget {
private:
    bool checkOut() const;
};
 
class MP3Player : public BorrowableItem, public ElectronicGadget {};

MP3Player player;
// player.checkOut(); // ambiguous

即使 ElectronicGadget::checkOut 是 private，调用仍歧义。C++ 名字查找先找到两个 base scope 中的候选，再判断访问性；编译器不会因为一个候选不可访问就替程序选择另一个。

Item 40 的原则是 Use multiple inheritance judiciously（审慎使用多重继承）。

先预测：把 Gadget 的 checkOut 改成 protected 或 public，是否能消除 ambiguity？答案是否改变，为什么？

用限定名表达选择，而不是依赖猜测

player.BorrowableItem::checkOut();

限定调用最直接，但会让客户知道继承结构。若业务语义是“借出播放器”，更好的 API 是在 derived 中提供意图 wrapper。

class MP3Player : public BorrowableItem, public ElectronicGadget {
public:
    void borrow() { BorrowableItem::checkOut(); }
};

using BorrowableItem::checkOut 也能把一个名字引入 derived scope，但应确认是否真的想公开原始 base contract。wrapper 更适合改名、校验参数和维护 derived invariant。

多重继承首先是多个独立身份

若一个类型 public 继承两个 interface classes，它向客户同时承诺两个 is-a 关系。

class Printable {
public:
    virtual ~Printable() = default;
    virtual void print(std::ostream&) const = 0;
};
 
class Serializable {
public:
    virtual ~Serializable() = default;
    virtual Bytes serialize() const = 0;
};
 
class Invoice final : public Printable, public Serializable {
    // both contracts implemented
};

这种多继承可能合理：Printable 和 Serializable 是正交 capabilities，通常没有 data，也不共享共同 stateful root。客户分别经不同 interface 使用 Invoice。

但若两个 bases 都拥有生命周期状态、copy 规则和同名操作，derived 要同时维护的交叉不变量会迅速增多。

diamond：共同祖先出现两次

class File { /* path and metadata */ };
class InputFile : public File {};
class OutputFile : public File {};
class IOFile : public InputFile, public OutputFile {};

IOFile 含两个 File subobjects：一个经 InputFile 路径，一个经 OutputFile 路径。IOFile 转成 File& 会歧义，path 也有两份。

IOFile file;
File& inputSide = static_cast<InputFile&>(file);
File& outputSide = static_cast<OutputFile&>(file);

两份 File state 可能各自持有不同 path，这到底是需求还是模型错误必须明确回答。

virtual inheritance 共享共同 base

class InputFile : virtual public File {};
class OutputFile : virtual public File {};
class IOFile : public InputFile, public OutputFile {
public:
    explicit IOFile(Path path) : File(std::move(path)) {}
};

virtual 在这里描述 base subobject 共享，与 virtual function 是不同机制。InputFile 和 OutputFile 都声明 virtual inheritance 后，IOFile 中只有一个 File。

most-derived type 负责构造 virtual base

virtual base 由最终完整对象直接初始化，而不是由中间 bases 最终决定。

class File {
public:
    explicit File(Path path);
};
 
class IOFile : public InputFile, public OutputFile {
public:
    explicit IOFile(Path path)
        : File(path), InputFile(), OutputFile() {}
};

当未来再派生 EncryptedIOFile，它才是 most-derived，并负责 File 初始化。这个责任穿过中间层，增加构造知识和演进耦合。

virtual inheritance 的成本模型

共享 base identity 不是免费抽象。实现通常需要额外指针或 offset metadata 来定位 virtual base；访问可能多一次间接计算；对象更大；初始化规则更复杂；cast 和 debugger layout 也更难读。

Item 40 的审慎建议是：非必要不要使用 virtual bases；若必须使用，尽量避免在 virtual base 放 data。纯接口或极小稳定状态更容易管理。

可辩护形态：public interface + private implementation

Item 40 给出一种现实可用的组合：一个 public base 表达公开接口身份，另一个 private base 提供实现和 virtual hooks。

class IPerson {
public:
    virtual ~IPerson() = default;
    virtual std::string name() const = 0;
};
 
class PersonInfo {
public:
    explicit PersonInfo(DatabaseId id) : id_(id) {}
 
    std::string theName() const {
        return nameDelimOpen() + readName(id_) + nameDelimClose();
    }
 
private:
    virtual std::string nameDelimOpen() const { return "["; }
    virtual std::string nameDelimClose() const { return "]"; }
    DatabaseId id_;
};
 
class CPerson final : public IPerson, private PersonInfo {
public:
    explicit CPerson(DatabaseId id) : PersonInfo(id) {}
    std::string name() const override { return theName(); }
 
private:
    std::string nameDelimOpen() const override { return {}; }
    std::string nameDelimClose() const override { return {}; }
};

CPerson public 继承 IPerson，因为 CPerson is-an IPerson；private 继承 PersonInfo，因为 CPerson 根据 PersonInfo 实现，并需要重定义其 delimiters。两条继承边分别有不同、可说明的语义。

为什么不直接 composition PersonInfo

若 CPerson 只调用 PersonInfo::theName，composition 更好；但示例还需要 override PersonInfo 的 virtual delimiters。普通 member 不能 override 其所属类型的 virtual functions。

可以像 Item 39 那样设计 nested adapter 或修改 PersonInfo 接受 strategy/callback。若 PersonInfo 是不可修改的既有实现，private inheritance 可能是局部成本最低的办法。

class CPerson final : public IPerson {
private:
    class InfoAdapter final : public PersonInfo {
        // overrides and calls owner if needed
    };
 
    InfoAdapter info_;
};

adapter composition 能让 CPerson 的继承图更简单，但增加一个辅助类型与 back-reference。应比较实际依赖，不要机械套规则。

审查多重继承的六张表

1. 身份表：每条 public edge 是否真是 is-a，能否独立做 substitutability test。
2. 名字表：base public/protected/private names 是否冲突，客户如何消歧。
3. 状态表：共同祖先应有一份还是多份 state，谁维护交叉 invariant。
4. 布局表：是否出现 virtual base、额外 offset、size/alignment 与 ABI 影响。
5. 构造表：谁初始化 virtual base，constructor failure 如何展开。
6. 演进表：任一 base 新增 overload、data 或 virtual 是否破坏 derived。

先预测后编译：分别给两个 bases 新增同名 nonvirtual function，观察现有 derived call sites 是否从唯一解析变为 ambiguity。多继承的风险不仅在今天，也在 base 独立演进后。

小结

• multiple inheritance 同时引入多个 base scopes、身份、状态和构造协议
• 名字查找的 ambiguity 先于 access checking，private 候选也会参与冲突
• 普通 diamond 包含多份共同 base；virtual inheritance 可共享一份但有布局与初始化成本
• most-derived type 负责直接初始化 virtual bases
• 多个正交纯接口可以合理 public 继承，但每个 contract 都要独立验证
• public interface base 加 private implementation base 是可辩护形态，前提是每条边语义明确