Java组合设计技巧：组合优于继承解析

本文深入解析了Java中组合优于继承的设计原则，强调组合通过private final字段与构造器注入实现更灵活、安全且可测试的依赖管理，特别适用于非“is-a”关系、需运行时替换行为、父类不支持继承或需要Mock测试等场景；同时澄清组合并非否定继承，而是让继承回归语义本质——专注类型契约与模板逻辑，而组合则负责能力装配与解耦，二者可协同使用，关键在于根据真实语义和工程需求做出清醒选择。

组合比继承更灵活，不是因为它“更高级”，而是因为你在修改行为、替换依赖、控制生命周期时，不用受制于类的继承层级和 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）。但这些继承关系应窄而深，不是宽而浅。

• 继承适合定义“可扩展的骨架”，组合适合组装“可替换的零件”
• 一个类同时有继承和组合？可以，但优先确保继承解决的是“类型契约”，组合解决的是“能力装配”
• 别为了“避免继承”而硬套组合——如果两个类天然存在清晰的 is-a 关系，且父类设计良好，继承反而更简洁

真正容易被忽略的点是：组合带来的间接层会让调试多跳一次，比如 car.start() → engine.ignite() → sparkPlug.fire()。所以务必给组合对象起准确名、写好 Javadoc，并在关键路径加日志或断点标记。否则问题定位成本反而上升。

今天关于《Java组合设计技巧：组合优于继承解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！