优先选择组合而非继承，因其更利于封装、解耦和测试；仅当满足is-a关系、父类明确支持继承且无易变逻辑时才用继承。
继承会暴露父类实现细节，组合更利于封装
继承让子类直接获得父类的字段和方法，但这也意味着父类内部变化可能破坏子类行为。比如父类 ArrayList 内部改用新算法重写 add()，依赖其旧执行顺序的子类就可能出错。组合则只通过公开接口通信，父类（或被组合对象）可自由重构，只要接口契约不变，使用者完全无感。
实际选型时优先考虑组合，除非满足以下全部条件：
- 子类确实是父类的一种（is-a 关系严格成立）
- 父类设计为被继承（有 protected 方法、文档明确标注“可继承”）
- 父类不包含易变的业务逻辑（如 java.util.AbstractList 是安全基类，但 java.util.ArrayList 不是）
组合需要手动委托，但可用 lombok @Delegate 简化
组合不是“自动继承”，你得显式调用被组合对象的方法。例如用 private final List<string> list = new ArrayList();</string>，想支持 size() 就得自己写 public int size() { return list.size(); }。重复写这类委托方法容易出错且冗长。
用 Lombok 可大幅减少样板代码：
@Data
public class StringBox {
@Delegate(types = List.class)
private final List<String> 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——行为悄然改变，且编译期无法发现。
立即学习“Java免费学习笔记（深入）”；
组合不存在这种隐式调用链：
- 所有调用目标明确（this.dao.query(...)）
- 即使替换被组合对象（如从 JdbcDao 换成 JpaDao），只要接口一致，调用点无需修改
- IDE 重命名/查找引用时，组合关系比继承链更易追踪
组合不是银弹——当需要深度复用模板方法模式（如 AbstractMap 的 put() + putImpl() 结构），继承仍不可替代。但日常业务对象建模中，多数所谓“父子关系”其实是“拥有关系”，强行继承只会让类职责模糊、测试难写、重构畏手畏脚。
