继承导致紧耦合，因编译期强依赖使父类变更易引发子类静默错误；组合更可控，适合复用逻辑；仅当满足明确“is-a”且父类设计为可继承时才用extends；final类与方法实为契约保护。
继承导致的紧耦合问题比想象中更难解
Java 中 extends 关键字建立的是编译期强依赖，子类会无条件继承父类所有非私有成员（包括字段、方法、甚至构造逻辑）。一旦父类修改 protected 方法的行为或签名，所有子类都可能在不报错的情况下悄然出错——比如重写时漏掉对新引入的 validate() 调用，而 IDE 不会警告。
- 父类添加一个非
final的init()方法，子类若未显式调用，初始化流程就断了 - 父类把
public void save()改成public final void save()，子类里同名方法直接编译失败 - 使用 Lombok 的
@Data生成equals()时，若父类字段参与比较，子类没重写就可能违反对称性
替代继承的组合方案往往更可控
当需要复用逻辑但又不想绑定生命周期和访问权限时，优先考虑组合。比如实现「可重试的 HTTP 客户端」，与其让 RetryHttpClient extends HttpClient，不如：
public class RetryHttpClient {
private final HttpClient delegate;
private final int maxRetries;
public RetryHttpClient(HttpClient delegate, int maxRetries) {
this.delegate = delegate; // 显式持有，不隐式继承
this.maxRetries = maxRetries;
}
public HttpResponse execute(HttpRequest req) {
// 封装重试逻辑，内部调用 delegate.execute()
}
}
这样能避免子类意外覆盖 execute() 导致重试失效，也方便单元测试中用 mock 替换 delegate。
- 组合对象可运行时替换（如切换不同
HttpClient实现），继承关系在编译期就固化 - 接口隔离更干净：组合类只暴露自己需要的方法，继承会把父类所有 public/protected 接口一并暴露
- Spring 等框架对组合的支持更自然（
@Autowired注入委托对象，而非强制继承某基类）
真正适合继承的场景其实很窄
只有当满足「is-a」关系且父类明确设计为被继承时，才该用 extends。JDK 自身的典型例子是 ArrayList 和 LinkedList 都继承 AbstractList——它提供了 add()、remove() 等默认实现，并用 abstract 方法强制子类提供底层存储逻辑（get(int)、size()）。
立即学习“Java免费学习笔记（深入）”；
- 父类必须有
protected钩子方法（如beforeSave()），且文档明确说明“供子类扩展” - 子类不改变父类语义：比如
ImmutableList extends List是错的，因为List合约要求可变，应改用接口实现 - 框架强制要求：如 JPA 的
@Entity类继承BaseEntity添加通用字段，此时父类需声明为@MappedSuperclass
final 类和方法不是限制，而是契约保护
看到 String、LocalDateTime 被标记为 final 就觉得“不灵活”，其实是误解。这些类的设计目标是值语义和线程安全，开放继承反而会破坏不变量。
- 若真需要定制日期处理，应封装
LocalDateTime字段，而非试图继承它 -
final方法防止子类绕过关键校验（如BigDecimal.divide()必须指定精度，禁止子类偷偷改成无精度版本） - 现代 Java 库（如 Vavr、JOOQ）大量使用
final类 + 静态工厂方法，靠组合和函数式编程替代继承
继承的诱惑在于写起来快，但调试时父子类间隐式交互带来的不确定性，远超初期省下的几行代码。真正难的不是“能不能继承”，而是判断“该不该让这个类被继承”。
