Java组合设计模式详解与应用

本文深入剖析了Java中组合设计模式相较于继承的核心优势与实践要点，强调组合并非否定继承，而是让两者各司其职：组合以private final字段配合构造器注入实现高内聚、易测试、可替换的依赖装配，特别适用于“has-a”关系、运行时行为切换、规避final限制及mock测试等场景；而继承则应回归语义本质，仅用于真正需要“is-a”契约和共享骨架逻辑的少数情况。文章还提醒开发者关注组合带来的调试间接性，倡导通过清晰命名、完善文档和关键日志来降低维护成本——掌握这一权衡，才能写出更健壮、灵活且可持续演进的Java代码。

组合比继承更灵活，不是因为它“更高级”，而是因为你在修改行为、替换依赖、控制生命周期时，不用受制于类的继承层级和 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学习网公众号，带你了解更多关于的知识点！