组合真的比更好继承吗？为什么 Rust 和 Go 都拥抱组合舍弃继承？

先叠个甲，我并不认同组合一定比更好继承这种太过于绝对化的观点。只要你对继承和组合这两者都有过思考的话。两者不存在孰优孰劣，只是组合更适合当下的开发模式。不过，

你是否在为大量重复代码而头疼？

在面向对象编程发展的早期，程序员面临一个非常现实的问题：大量重复的代码。每次新增一种动物，都要手动拷贝呼吸、进食等实现。

class Dog {
void breath { System.out.println;}
void eat { System.out.println;}
}
class Cat {
void breath { System.out.println;}
void eat { System.out.println;}
}

这就是继承最初要解决的问题：消除重复代码，实现代码复用。

继承解决的问题：代码复用

经典的例子是 Animal 与 DogDog 是 Animal 的一种，属于 is-a 关系。

class Animal {
void breath { System.out.println;}
void eat { System.out.println;}
}
class Dog extends Animal {
void bark { System.out.println;}
}

通过让 Dog 继承 Animal公共逻辑得以复用。代码量减少，结构层次清晰。那时的开发者几乎把继承视为常用方法。

你是否在项目迭代中被“父类脆弱”所困扰？

进入二十一世纪，软件交付从“一次性发布、长期维护”转向“敏捷迭代、快速试错”。老实说，需求频繁变更、迭代周期缩短。使得父类的任何微小改动都可能导致子类故障或意外行为。这正是很多团队在实际项目中踩过的坑：

// 父类
class Animal {
void fly {}
void swim {}
void run {}
}
// 子类
class Fish extends Animal {}

Fish 被迫拥有对它毫无意义的 fly/run) 方法。 只能抛异常或留空实现，导致代码臃肿且难以维护。话说回来，

继承最大的敌人：变化与 困难

因为业务模型变得更加复杂。继承树自然会变深，每一次需求变更都可能迫使我们：

• 重构已有的父子关系；
• 复制粘贴代码以规避不合适的父类；
• Add new abstract layers，引入更多抽象层级。

# 初始模型
Animal
├── Dog
└── Cat
# 多轮迭代后
Animal
└── Mammal
└── Pet
├── Cat
└── Dog
└── PoliceDog
└── MilitaryPoliceDog

A police dog 现在既是 “宠物” 又是 “执法犬”，修改 inheritance 关系会带来巨大的破坏性风险——这正是许多团队在实际业务演进中感受到的痛点。

至于组合的出场，用能力而不是身份复用代码

组合把多个独立组件拼装成新对象。新对象通过持有其他组件实例来复用功能，而不是直接继承其实现。

- 典型案例：汽车拥有引擎、车轮、仪表盘…*

import Input from "./Input";import SearchIcon from "./SearchIcon";import InputWithIcon from "./InputWithIcon";export default function CustomizedInput {
return (
}>

);}

The relationship here is a has‑a b 。not a is‑a b . 通过组合，可以随时替换、增加或删除部件，而不必担心“基类脆弱”导致全局崩溃。

使用者痛点映射表

何时选组合，何时仍保留继承？

因为时代的发展，程序员面对的主要挑战已经从“如何复用代码”转向“如何让代码适应变化”。在大多数现代项目中——特别是微服务、前端 UI、还有像 Rust、Go 这样的程序语言——组合比继承更能抵御频繁变更带来的风险。

当然这并不代表着继承彻底退出历史舞台。其实，传统领域的大型 ERP、银行主要程序等领域模型已经沉淀数十年，业务规则高度固化且变更频率极低。此时使用深度 inheritance 能够快速表达领域概念并保持一致性。

**没有绝对的优劣**；只有在特定业务环境和团队需求下选择最合适的复用手段才是关键。若你的项目经常面对需求波动、需要快速迭代，那么请大胆拥抱"组合";若你处在一个相对稳定且领域模型明确的大型程序，则可以适度保留"inheritance".