Item 32：确定 public 继承塑造出 is-a 关系

从“正方形当然是长方形”开始质疑

在数学分类中，Square 是 Rectangle；在 C++ 类型系统中，public inheritance 会让所有 Square*/Square& 自动可用于需要 Rectangle*/Rectangle& 的地方。

Item 32 的原则是 Make sure public inheritance models is-a（确定 public 继承塑模 is-a）。这里 is-a 不是日常语言的“看起来属于”，而是程序行为的严格承诺。

如果 Square 不能满足 Rectangle 的全部可观察操作，它就不应 public inherit Rectangle，即使两者共享 width/height 数据。

public 继承向客户承诺什么

base 的每个 public operation 都成为 derived 的契约。derived 可以实现得更快、返回更具体类型或加强结果，但不能让原本合法的 base 客户失效。

Liskov substitution（里氏替换）可具体化为：

• derived 不应加强 precondition。
• derived 不应削弱 postcondition。
• derived 应保持 base invariant。
• derived 不应引入 base 客户无法处理的新失败语义。
• derived 的 lifetime/ownership 行为不能让 base 用法悬空或泄漏。

这些名称不是为了形式主义，而是给 code review 可检查的清单。

Rectangle 客户的合法假设

定义一个可独立修改宽高的 Rectangle：

class Rectangle {
public:
    virtual ~Rectangle() = default;
    virtual void setWidth(int value);
    virtual void setHeight(int value);
    int width() const noexcept;
    int height() const noexcept;
};

setWidth 的自然后置条件是 width 变为 value，height 保持原值。

void makeWider(Rectangle& value) {
    const int oldHeight = value.height();
    value.setWidth(value.width() + 10);
    assert(value.height() == oldHeight);
}

这个函数对 Rectangle contract 是正确的，不属于“客户不该这样写”。

Square 无法同时满足两个契约

Square invariant 要求 width 始终等于 height：

class Square : public Rectangle {
public:
    void setWidth(int value) override {
        Rectangle::setWidth(value);
        Rectangle::setHeight(value);
    }
 
    void setHeight(int value) override {
        Rectangle::setWidth(value);
        Rectangle::setHeight(value);
    }
};

为了保持自身 invariant，Square::setWidth 必须改变 height；这削弱了 Rectangle::setWidth 的“height unchanged”后置条件。传给 makeWider 后 assertion 失败。

“抛异常表示不支持”也不满足 is-a

Square 可以让 setWidth 抛 UnsupportedOperation，但 Rectangle 客户原本可合法调用；derived 增强了 precondition 或引入新失败。

void Square::setWidth(int) {
    throw UnsupportedOperation{};
}

这不恢复 substitutability，只把静默违约改为运行期违约。

若 operation 对某 subtype 没有意义，base abstraction 过宽或继承关系错误。

现实分类不等于软件行为模型

Penguin 在生物分类上是 Bird，但如果 Bird API 声明 fly()，Penguin 无法替换 Flying Bird。

错误设计：

class Bird {
public:
    virtual void fly() = 0;
};
 
class Penguin : public Bird {
public:
    void fly() override; // throw/no-op 都违背 contract
};

软件模型应服务客户操作，而不是复制百科分类树。

拆分可选能力

若只有部分 birds 会飞，fly 不应属于所有 Bird：

class Bird {
public:
    virtual ~Bird() = default;
    virtual void eat() = 0;
};
 
class Flyable {
public:
    virtual ~Flyable() = default;
    virtual void fly() = 0;
};
 
class Sparrow : public Bird, public Flyable { /* ... */ };
class Penguin : public Bird { /* ... */ };

调用 fly 的客户依赖 Flyable，而非 Bird；类型系统拒绝 Penguin。

这样错误从 runtime throw 提前到 compile-time mismatch。

Square 与 Rectangle 可共享更小抽象

可以建只读 Shape/Bounds 接口，或让二者成为独立 value types：

class RectBounds {
public:
    int width() const noexcept;
    int height() const noexcept;
};
 
class Rectangle {
    RectBounds bounds_;
};
 
class Square {
    int side_;
};

需要统一绘制时，两者可实现只读 Drawable/Shape，不暴露独立 setWidth/setHeight。

共享代码应通过 helper/composition，不必伪造 public is-a。

代码复用不是 public 继承的理由

“Derived 想复用 Base implementation”只说明实现关系，不说明客户可替换。

优先 composition；private inheritance 适用于少数需要 protected access/empty-base optimization 的实现关系，Item 39 会深入。

public inheritance 必须从 base client contract 出发证明，而不是从 derived 写代码方便出发。

前置条件不能变严格

若 base send(Message) 接受任意合法 Message，derived 只接受 size < 1KB，就拒绝了 base 客户可传的合法值。

可让 base contract 本来就声明 limit，或把 restricted sender 作为不同类型/策略，不应隐藏在 override。

参数类型相同不证明 semantic domain 相同，测试要覆盖边界值。

后置条件和错误模型不能变弱

base save() 承诺成功后 durable，derived 只写 memory cache 却返回成功，削弱 postcondition。

base no-throw operation 被 override 改成可能抛也会破坏客户；C++ noexcept override rules 能检查部分情况，但业务错误语义仍需测试。

性能复杂度若属于 public promise，也不能从 O(1) 悄然变 O(n) 并让实时客户失效。

public inheritance 也包含 lifetime 契约

若 base 有 virtual destructor、copy/clone、ownership 和 thread-safety promise，derived 必须保持。

例如 base clone 承诺独立 deep copy，derived 不能返回共享 mutable state；base thread-safe const query，derived 不能使用 unsynchronized mutable cache。

is-a 不只检查函数名字和返回值。

用 base contract suite 验证每个 derived

为 base 写参数化契约测试，并对每个 concrete derived 运行：

template<class Factory>
void rectangleContract(Factory makeRectangle) {
    auto value = makeRectangle();
    const int oldHeight = value->height();
    value->setWidth(value->width() + 10);
    CHECK(value->height() == oldHeight);
}

compile checks 只能证明可转换，contract suite 才证明行为。

评审继承关系的证据矩阵

先预测每个 base operation 对候选 derived 的合法输入、结果和 invariant，再验证：

• 列出 base public/virtual/non-virtual operations 与 documented pre/postconditions。
• 对每个 derived 标记是否加强 precondition、削弱 postcondition或新增失败。
• property tests 覆盖 Square/Rectangle width-height 状态空间。
• base contract suite 对每个 factory/derived 重跑。
• ownership tests 覆盖 virtual destruction、clone、copy/move 和 borrowed handles。
• concurrency/complexity tests 覆盖 base 承诺的非功能属性。
• 客户代码不包含 derived type checks 或 “except subtype X” 分支。
• 只复用 implementation 的候选改成 composition 后比较 API 清晰度。

任何一行需要“derived 例外”都应重新审查 public inheritance。

小结

• public inheritance models is-a 意味 derived 可替换 base，不只是现实分类或字段相似
• derived 不能加强 precondition、削弱 postcondition、破坏 base invariant 或错误模型
• Square 为保持边长相等必须改变 Rectangle setWidth 语义，因此不能满足该 base contract
• Penguin–Bird 问题应拆分 Flyable capability，让不支持的操作从 base interface 消失
• 只为 implementation reuse 应选择 composition/helper，而不是 public inheritance
• base contract suite 与 inheritance substitution matrix 提供逐 derived 的行为证据