为什么接口比继承更适合实现多态

接口比继

承更适合实现多态，因其解耦行为契约与实现细节，支持多维度能力组合、编译期类型安全、隐式实现及细粒度正交设计。

接口比继承更适合实现多态，根本原因在于它解耦了「行为契约」和「实现细节」——你不需要让类在继承树里站队，只要承诺能做某件事，就能参与多态调度。

Java 中 interface 与 extends 在多态中的角色差异

Java 不支持多继承，但一个类可以实现多个 interface。这意味着你可以让 Dog 同时具备 Runnable、Barkable、Serializable 等不同维度的能力，而这些能力在运行时都能通过统一的引用类型触发多态行为：

Runnable r = new Dog();
Barkable b = new Dog();
r.run(); // 多态调用
b.bark(); // 多态调用

如果全靠 extends，Dog 就只能继承自 Animal（或别的单一父类），无法再“同时是”Machine 或 NetworkNode —— 但现实中，一个无人机对象完全可能既是 Drivable 又是 Flyable 又是 Loggable。

ClassCastException 和空方法体是继承式多态的常见陷阱

为强行复用而设计的抽象父类，常导致子类被迫实现无意义的方法，或者在运行时因类型强转失败抛出 ClassCastException：

• 抽象类 Vehicle 定义了 fly()，但 Car 子类只能抛 UnsupportedOperationException
• 调用方写 ((Airplane) vehicle).fly()，一旦传入 Car 实例就崩溃
• 而用 Flyable 接口，只有真正实现了它的类才能被赋值给 Flyable 引用，编译期就过滤掉了不合法组合

Go 的接口隐式实现进一步说明问题本质

Go 根本没有 implements 关键字，只要结构体有对应方法签名，就自动满足接口。这反向印证：多态的关键不是“我声明我要继承谁”，而是“我恰好能响应这个消息”。例如：

type Speaker interface {
    Speak() string
}

type Person struct{}
func (p Person) Speak() string { return "Hello" }

type Robot struct{}
func (r Robot) Speak() string { return "Beep boop" }

// 无需显式声明，Person 和 Robot 都可直接用于 []Speaker

这种设计把多态的决定权从定义侧（类声明时）移到使用侧（函数参数、切片类型），更贴近“按需组合”的真实需求。

真正容易被忽略的是：接口定义的粒度。一个叫 Service 的大接口，和拆成 Reader、Writer、Closer，对多态的灵活性影响极大——越小、越正交的接口，越容易被不同类独立实现，也越不容易逼人写出 throw new UnsupportedOperationException()。