组合与继承怎么选？

在Java设计中，组合优于继承应成为默认选择：它通过接口隔离实现细节，大幅提升封装性、可测试性和重构自由度，避免继承带来的脆弱性——如父类变更意外破坏子类、多层继承链中super调用行为不可控、单元测试被迫耦合真实依赖等；仅当严格满足“is-a”关系、父类明确支持继承且逻辑稳定时，才考虑使用继承，而Lombok的@Delegate等工具可有效缓解组合所需的委托样板代码，让灵活稳健的设计真正落地于日常开发。

继承会暴露父类实现细节，组合更利于封装

继承让子类直接获得父类的字段和方法，但这也意味着父类内部变化可能破坏子类行为。比如父类 ArrayList 内部改用新算法重写 add()，依赖其旧执行顺序的子类就可能出错。组合则只通过公开接口通信，父类（或被组合对象）可自由重构，只要接口契约不变，使用者完全无感。

实际选型时优先考虑组合，除非满足以下全部条件：
- 子类确实是父类的一种（is-a 关系严格成立）
- 父类设计为被继承（有 protected 方法、文档明确标注“可继承”）
- 父类不包含易变的业务逻辑（如 java.util.AbstractList 是安全基类，但 java.util.ArrayList 不是）

组合需要手动委托，但可用 lombok @Delegate 简化

组合不是“自动继承”，你得显式调用被组合对象的方法。例如用 private final List list = new ArrayList();，想支持 size() 就得自己写 public int size() { return list.size(); }。重复写这类委托方法容易出错且冗长。

用 Lombok 可大幅减少样板代码：

@Data
public class StringBox {
    @Delegate(types = List.class)
    private final List list = new ArrayList();
}

这样 StringBox 就自动拥有了 add()、get()、size() 等所有 List 接口方法。注意：@Delegate 只代理接口定义的方法，不代理具体类的独有方法（如 ArrayList.ensureCapacity()）。

继承破坏单元测试隔离性，组合更容易 mock

继承下，子类测试常被迫启动整个父类逻辑链。比如测试 DatabaseService extends JdbcDao，即使只想验证 SQL 拼接逻辑，也可能触发真实数据库连接——因为 JdbcDao 的构造器或 init() 方法隐式初始化了数据源。

组合则天然解耦：

public class DatabaseService {
    private final JdbcDao dao; // 构造注入
    public DatabaseService(JdbcDao dao) {
        this.dao = dao;
    }
}

测试时直接传入 Mockito.mock(JdbcDao.class)，完全绕过真实 DAO 初始化。这也是 Spring 推荐依赖注入而非继承的根本原因之一。

多层继承链会让 super 调用变得脆弱

当出现 A extends B extends C 时，A 中调用 super.method() 实际指向 B 的实现；如果后续在 B 和 C 之间插入新类 D（即变成 A extends B extends D extends C），而 B 又没重写该方法，那 A.super.method() 就会跳到 D 而非 C——行为悄然改变，且编译期无法发现。

组合不存在这种隐式调用链：
- 所有调用目标明确（this.dao.query(...)）
- 即使替换被组合对象（如从 JdbcDao 换成 JpaDao），只要接口一致，调用点无需修改
- IDE 重命名/查找引用时，组合关系比继承链更易追踪

组合不是银弹——当需要深度复用模板方法模式（如 AbstractMap 的 put() + putImpl() 结构），继承仍不可替代。但日常业务对象建模中，多数所谓“父子关系”其实是“拥有关系”，强行继承只会让类职责模糊、测试难写、重构畏手畏脚。

今天关于《组合与继承怎么选？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！