从 OOP 继承到 Rust 组合式多态：comprehensive-rust 课程中的继承替代方案实战指南

本文以 Google Android 团队 Rust 课程（comprehensive-rust）中 "From OOP to Rust" 章节为蓝本，系统对比面向对象语言（C++、Java）中的继承机制与 Rust 基于 trait 的多态方案。文章先复盘继承的定义与典型代码，再逐一剖析 Rust 拒绝继承的原因（数据与行为分离、组合优于继承、supertrait、密封 trait、dyn Trait 动态分发），最后给出从继承式思维迁移到 trait 式思维的问题拆解方法论。读完本文，你将能熟练把 C++/Java 的继承层级重构为 Rust 的组合结构 + trait 约束，并正确取舍泛型、trait 对象与枚举三种多态手段。

继承是什么：OOP 世界里的既有共识

在进入 Rust 之前，先明确继承在传统 OOP 语言中的定义。课程文档 inheritance.md 用一段 C++ 代码给出了最直观的演示：一个基类 Vehicle，一个通过 : public 继承它的 Car 子类。

// Base class
class Vehicle {
public:
    void accelerate() { }
    void brake() { }
};

// Inheriting class
class Car : public Vehicle {
public:
    void honk() { }
};

int main() {
    Car myCar;                  // Create a Car object
    myCar.accelerate();         // Inherited method
    myCar.honk();               // Car's own method
    myCar.brake();              // Inherited method
    return 0;
}

这段代码演示了继承的三个核心特性：

• 字段与方法的下传：继承是一种让"子类型"获得其"父类型"字段和方法的机制。Car 没有自己定义 accelerate() 和 brake()，却可以直接调用——因为它们从 Vehicle 继承而来。
• 方法覆写（override）：继承类型可以根据需要覆写从父类继承来的方法，改变默认行为。
• super 调用：子类方法可以通过 super 关键字调用被覆写前的父类实现。

对已经熟悉 OOP 的读者，这段代码几乎不需要解释；但正是这些"理所当然"的便利，构成了从 Rust 视角审视时的核心矛盾点。

为什么 Rust 没有继承：三个层面的代价

课程的 why-no-inheritance.md 用一段编译失败的 Rust 代码直观展示了 Rust 对继承的拒绝——pub struct Data: Id { ... } 这样的继承语法在 Rust 中是不存在的，编译器直接报错。紧随其后给出了推荐的替代写法：把 id 作为字段组合进结构体。文档总结了继承带来的三个结构性缺点：

1. 默认异构，丢失具体类型信息

类继承隐式地允许不同类型互换使用，却无法指定具体类型，也无法判定某个类型是否与另一个类型相同。在相等性（equality）或比较（comparison）这类操作上，这种异构性可能导致抛出错误或直接 panic。

2. 数据结构与行为的"多重真相源"

一个类型的字段被继承层级遮蔽（obscured），你无法一眼看出结构体到底由哪些字段构成；一个方法可能覆写了父类型、也可能被子类型覆写。在由多方维护的复杂代码库中，很难确定一个类型的真实行为。这是继承在大型工程中维护成本飙升的根源。

3. 默认动态分发带来的 vtable 开销

为了让动态分发工作，运行时必须在某个地方存储"该调用哪个方法"等信息，这个存储就是值的 vtable。方法调用会比编译期已知类型的方法调用多出若干次解引用（dereference）。也就是说，继承把动态分发作为默认选项，而你无法选择退出，无论你是否真的需要它。

需要强调的是，Rust 并非全盘否定动态分发——它只是把动态分发从"默认"降级为"按需选择"（即后文介绍的 dyn Trait）。

Rust 视角下的继承：数据与行为被"搅拌"在一起

课程 switch-perspective.md 提供了一个从 Rust 立场反观继承的视角。Rust 中概念被严格区分为三类：

// Data
pub struct Data {
    id: usize,
    name: String,
}

// Concrete behavior
impl Data {
    fn new(id: usize, name: impl Into<String>) -> Self {
        Self { id, name: name.into() }
    }
}

// Abstract behavior
trait Named {
    fn name(&self) -> &str;
}

// Instanced behavior
impl Named for Data {
    fn name(&self) -> &str {
        &self.name
    }
}

• 类型（type） 是具体的数据及其关联行为；
• trait 是必须由类型实现的抽象行为；
• 类（class） 则是数据、行为、行为覆写的三者混合体。

从 Rust 的角度看，一个可继承的类看起来就像是"既是类型又是 trait"的东西。这并非优点——因为它让"具体类型"失去了可推理性。OOP 把泛化行为与具体细节绑定在一起，导致难以区分"这段代码依赖的是通用行为还是具体实现"。文档给出的结论是：扁平字段访问与类型定义 DRY（Don't Repeat Yourself）带来的便利，不值得用"行为与数据无法划清界限"来交换。

核心替代方案一：组合优于继承（Composition over Inheritance）

课程 composition.md 给出了 Rust 的标准做法：不搞 mixin 或继承，而是通过创建不同字段类型来组合出新的类型。

pub struct Uuid([u8; 16]);

pub struct Address {
    street: String,
    city_or_province: String,
    code: String,
    country: String,
}

pub struct User {
    id: Uuid,
    address: Address,
}

组合的代价主要在字段访问的便利性上（访问 user.address.street 比访问 user.street 啰嗦），但它换来了两大收益：

• 控制力与清晰度：开发者对"这个类型是什么、它拥有什么"拥有完全的控制和清晰的认知；
• 字段可见性：结构体字段不再被继承层级遮蔽，数据结构的构成一目了然。

文档还特别提醒一个派生（derive）陷阱：当对结构体或枚举变体派生 trait 时，要确保所有组成字段类型（或枚举变体类型）都实现了该 trait。派生宏通常假设组成新类型的所有类型已经实现了对应 trait——如果 Uuid 或 Address 没有实现 Debug/Clone 等，#[derive(Debug)] 作用于 User 时会直接编译失败。

关于组合的"代码复用"能力，一个常见误解是组合会丢失方法复用。实际上在 Rust 中你依然可以定义固有方法（inherent methods）或为组合结构实现 trait 来暴露内部类型的行为，只是这些行为不再被自动"继承"。

核心替代方案二：Supertrait——最接近"继承"的 trait 机制

课程 supertraits.md 展示了 Rust 中最接近继承的语法：trait 可以依赖其他 trait。

pub trait SuperTrait {}

pub trait Trait: SuperTrait {}

这里 Trait 以 SuperTrait 为 supertrait，表面上与继承有几分相似，但本质不同：

• 只继承行为，不继承数据：trait 不暴露字段，只暴露方法和关联类型（associated types）/关联常量。数据与行为被彻底分离，行为保持在容易推理的状态。
• 让"多重继承"更容易实现：我们只关心"在需要某种行为的地方（用 trait 约束泛型时）声明该类型具备这种能力"。通过在泛型上指定多个 trait，就能确定该类型同时拥有所有这些 trait 的方法——这比 C++ 中多重继承带来的菱形问题（diamond problem）要简单得多。

课程 methods-and-traits/traits/supertraits.md 对 supertrait 的约束传播与 where 子句写法有更完整的展开，可作为进阶阅读。

多态的两种实现：泛型 vs dyn Trait

继承默认携带动态分发，而 Rust 让你显式选择。课程的 dyn-vs-generics.md 对比了两种写法：

fn print_display<T: std::fmt::Display>(t: &T) {
    println!("{}", t);
}

fn print_display_dyn(t: &dyn std::fmt::Display) {
    println!("{}", t);
}

fn main() {
    let int = 42i32;
    // Monomorphized to a unique function for i32 inputs.
    print_display(&int);
    // One per
    print_display_dyn(&int);
}

• 泛型参数（单态化，monomorphization）：对每个替换参数的具体类型，编译器会生成一份该函数的新版本。代价是二进制体积增加，收益是更强的优化能力（可以内联、可以静态分发）。泛型约束还要求类型同质——所有 T 的实例必须是同一类型。
• trait 对象（dyn Trait）：最终二进制中只存在一个版本的函数（不算内联）。代价是每次调用经过 vtable 间接跳转。

课程的 dyn-trait.md 进一步解释了 trait 对象的本质：

• 动态分发在 OOP 语言中往往是隐式的、无法退出的过程；Rust 中 dyn Trait 是显式选择加入的动态分发。
• 对任何"dyn 兼容"（dyn compatible）的 trait，都可以把指向值的引用强制转换为 dyn Trait 值，即 trait 对象。trait 对象的具体类型在编译期未知，但其行为已知——就是 trait 本身定义的那部分。
• 当确实需要 OOP 风格的异构数据结构时，可以使用 Box<dyn Trait>；但应优先保持同质、基于泛型的设计。

pub trait Trait {}

impl Trait for i32 {}
impl Trait for String {}

fn main() {
    let int: &dyn Trait = &42i32;
    let string: &dyn Trait = &String::from("Hello dyn!");;
}

关于 dyn 兼容性的边界（哪些 trait 可以变成 trait 对象、哪些不行），可参阅 dynamic-dispatch/dyn-compatible.md 与 dynamic-dispatch/limits.md。

异构集合：dyn Trait 的典型用武之地

继承常被用于构建异构集合（一个装满了不同子类的容器）。Rust 中这对应 heterogeneous.md 展示的模式：

use std::fmt::Display;

pub struct Lambda;

impl Display for Lambda {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "λ")
    }
}

fn main() {
    let heterogeneous: Vec<Box<dyn Display>> = vec![
        Box::new(42u32),
        Box::new(String::from("Woah")),
        Box::new(Lambda),
    ];
    for item in heterogeneous {
        // We know "item" implements Display, but we know nothing else!
        println!("Display output: {}", item);
    }
}

关键洞察在于：向量里存储的 u32、String、自定义的 Lambda 三个类型各不相同，但迭代时我们唯一知道的就是"它们都实现了 Display"——这正是继承语境下"按基类引用子类对象"的 Rust 等价物，只是被明确标注、按需启用。动态分发相关概念的完整脉络（trait 对象、dyn 兼容性、陷阱等）可参见 dynamic-dispatch/ 目录。

控制"谁可以扩展"：开放 trait 与密封 trait

继承中的 virtual/abstract 语义让子类可以扩展父类行为。Rust 用两类 trait 分别对应"允许用户扩展"与"禁止用户扩展"两种策略。

开放 trait：用户可扩展的多态

sticking-with-traits.md 指出：只要 trait 在 crate 中是公开暴露的，依赖该 crate 的用户就可以为自己定义的类型实现它。

// Crate A
pub trait Trait {
    fn use_trait(&self) {}
}

// Crate B, depends on A
pub struct Data(u8);

impl Trait for Data {}

fn main() {
    let data = Data(7u8);
    data.use_trait();
}

这种可扩展性是许多领域的关键能力，从序列化（如 serde 的 Serialize/Deserialize）、硬件的抽象表示，到类型安全的线性代数，都依赖"用户实现 API 所要求的行为"这一机制。

密封 trait：用户不可扩展的多态

sealed-traits.md 则回答了"如何在 crate 内部使用 trait 驱动代码，同时阻止下游项目实现该 trait"的问题。实现机制是把 supertrait 放在私有模块中，下游用户因无法访问该模块而无从实现。

// crate can access the "sealed" module and its trait, but projects that
// depend on it cannot.
mod sealed {
    pub trait Sealed {}
    impl Sealed for String {}
    impl Sealed for Vec<u8> {}
    //...
}

pub trait APITrait: sealed::Sealed {
    /* methods */
}
impl APITrait for String {}
impl APITrait for Vec<u8> {}

密封的动机有两类：

• trait 目前对下游实现而言尚不稳定，需要预留演进空间；
• 领域对"naive 实现"风险极高（例如密码学），必须限制实现者。

文档还比较了"为什么不用枚举替代密封 trait"：

• 枚举会暴露实现细节——"它只对这些类型有效"；
• 用户必须使用枚举的变体构造器来使用 API；
• 用户代码把枚举当作类型使用时，一旦枚举变更，下游代码必须同步修改；
• 枚举要求对变体做分支（branching），而密封 trait 能让编译器为每种类型生成单态化的专用函数。

"枚举密封"的另一种互补形态见 sealing-with-enums.md，两者共同构成了 Rust 中"有限实现集"（类似 OOP 中封闭继承层级）的两种主流做法。

迁移方法论：从继承式思维到 trait 式思维

课程的 problem-solving.md 用 15 分钟的示例讲解了如何把 OOP 问题拆解为 Rust 方案，核心是重组解题顺序：先用"泛型 + trait"或"枚举"尝试解决，而不是默认创建类层级。

示例问题是设计一个 GUI 绘图 API。第一步问："一个绘图 API 的最小可用行为是什么？"——得到一个最小 trait：

// Problem: implementing a GUI API

// Question: What's the minimum useful behavior for a drawing API?
pub trait DrawApi {
    fn arc(&self, center: [f32; 2], radius: f32, start_angle: f32, end_angle: f32);
    fn line(&self, start: [f32; 2], end: [f32; 2]);
}

pub struct TextDraw;

impl DrawApi for TextDraw {
    fn arc(&self, center: [f32; 2], radius: f32, start_angle: f32, end_angle: f32) {
        println!("arc of radius ")
    }

    fn line(&self, start: [f32; 2], end: [f32; 2]) { /* ... */
    }
}

第二步问："对用户友好的 API 是什么样？"——trait 之间相互组合，Draw trait 通过泛型约束消费 DrawApi：

// Question: What's a good API for users?

pub trait Draw {
    fn draw<T: DrawApi>(&self, surface: &mut T);
}

pub struct Rect {
    start: [f32; 2],
    end: [f32; 2],
}

impl Draw for Rect {
    fn draw<T: DrawApi>(&self, surface: &mut T) {
        surface.line([self.start[0], self.start[1]], [self.end[0], self.start[1]]);
        surface.line([self.end[0], self.start[1]], [self.end[0], self.end[1]]);
        surface.line([self.end[0], self.end[1]], [self.start[0], self.end[1]]);
        surface.line([self.start[0], self.end[1]], [self.start[0], self.start[1]]);
    }
}

文档给出的决策流程可以总结为三条：

1. 先问类型集合是否固定：如果问题需要一组确定的类型，枚举（enum）可能是最干净的方案；
2. 再问关心的是类型细节还是行为：如果问题不关心具体类型、只关心能力，就用 trait；
3. 最后才考虑异构集合：如果确实需要异构集合（如插件系统、事件总线），Box<dyn Trait> 是存在的工具，可以放心使用。

同时要警惕 XY 问题：某个问题看起来用某个方案最容易解决，但它可能没有触及根本原因，反而在未来引入更难的新问题。使用 trait 对象（动态分发）之前，确认它是你真正需要的；使用 trait 之前，同样确认这一点。

本章在课程中的位置与延伸阅读

本主题属于课程 Idiomatic Rust 部分（idiomatic/polymorphism/from-oop-to-rust.md）的核心内容，官方建议课时约 5 分钟讲解继承、10 分钟讲"为什么没有继承"。该章节完整覆盖了从 OOP 到 Rust 多态的思维迁移，包括本主题未展开的 dynamic-dispatch/any-trait.md、dynamic-dispatch/pitfalls.md 等进阶话题。

如果你希望进一步夯实基础，可配合阅读课程中以下关联章节：

• methods-and-traits/traits.md：trait 的基础语法与实现；
• methods-and-traits/traits/supertraits.md：supertrait 约束的完整写法；
• generics/trait-bounds.md：泛型约束的进阶使用；
• smart-pointers/trait-objects.md：Box<dyn Trait> 与 trait 对象的内存模型。

小结

从 OOP 的继承到 Rust 的多态，本质是一次"把数据与行为解耦"的重构：组合（composition）取代字段与方法的自动下传，trait 与 supertrait 取代方法覆写与抽象基类，泛型与 dyn Trait 取代隐式动态分发，枚举与密封 trait 取代封闭继承层级。这套体系放弃了继承带来的书写便利，换来了可推理的具体类型、明确的扩展边界与按需启用的运行时开销——这正是 comprehensive-rust 课程"From OOP to Rust"章节希望传递给每一位从 C++/Java 迁移而来的开发者的核心心智模型。