组合比继承更灵活，因其不受继承层级和final限制，适用于非“is-a”关系、需运行时替换依赖、父类设计不支持继承或需mock测试等场景；推荐private final字段+构造器注入。
组合比继承更灵活，不是因为它“更高级”，而是因为你在修改行为、替换依赖、控制生命周期时，不用受制于类的继承层级和 final 限制。
什么时候该用组合而不是继承
当你想复用某个类的功能，但又不希望子类暴露父类的全部接口、或不满足“is-a”关系时，组合是更自然的选择。比如：Car 不是 Engine 的一种，但它“有”一个 Engine；OrderProcessor 不是 PaymentService，但它需要调用它的 process() 方法。
- 父类方法太多、太重，子类只用其中一两个 → 组合可精确引用所需能力
- 需要在运行时切换行为（如换支付方式、换日志实现）→ 组合支持依赖注入或 setter 替换
- 父类设计未考虑被继承（没写
protected、方法没加@Override友好注释、甚至用了final）→ 继承可能直接走不通 - 要测试某个类，但它的父类依赖数据库或网络 → 组合让你轻松 mock 掉依赖
private final 字段 + 构造器注入是最稳妥的组合写法
避免把组合对象设为 public 或 protected，也不要在类里裸写 new Engine()。构造器注入能保证依赖不为空，且便于单元测试传入模拟对象。
public class Car {
private final Engine engine;
private final Transmission transmission;
public Car(Engine engine, Transmission transmission) {
this.engine = Objects.requireNonNull(engine);
this.transmission = Objects.requireNonNull(transmission);
}
public void start() {
engine.ignite();
transmission.shiftTo(DRIVE);
}
}
- 字段用
private final：防止外部篡改，也明确表达“该依赖不可变” - 构造器参数做
Objects.requireNonNull()：提前报错，不等到start()才空指针 - 不提供
setEngine()：除非你真需要运行时替换，否则开放 setter 会破坏封装和线程安全
组合不是“不用继承”，而是让继承回归语义本质
Java 中仍需要继承的典型场景：共享模板逻辑（如 AbstractList）、统一回调契约（如 HttpServlet）、或框架强制要求（如 Spring 的 ApplicationRunner）。但这些继承关系应窄而深，不是宽而浅。
立即学习“Java免费学习笔记（深入）”；
- 继承适合定义“可扩展的骨架”，组合适合组装“可替换的零件”
- 一个类同时有继承和组合？可以，但优先确保继承解决的是“类型契约”，组合解决的是“能力装配”
- 别为了“避免继承”而硬套组合——如果两个类天然存在清晰的 is-a 关系，且父类设计良好，继承反而更简洁
真正容易被忽略的点是：组合带来的间接层会让调试多跳一次，比如 car.start() → engine.ignite() → sparkPlug.fire()。所以务必给组合对象起准确名、写好 Javadoc，并在关键路径加日志或断点标记。否则问题定位成本反而上升。
