应优先使用组合而非继承，因继承仅适用于“是”关系（如Car是Vehicle），而“有”关系（如Car有Engine）须用组合；滥用继承导致ClassCastException、空实现、维护困难等问题，且易违反Liskov替换原则。
继承用在“是”关系，组合用在“有”关系
判断该不该用继承，就看子类是不是父类的一种。比如 Car 是 Vehicle 的一种，用继承合理；但 Car 有 Engine，就不能让 Car extends Engine——这是典型的组合误用。
常见错误现象：ClassCastException 频繁出现、子类被迫重写大量空实现、父类一改，多个子类全崩。这些问题往往源于把“能复用”当成了“该继承”。
- 如果只是为了代码复用，优先考虑组合 + 接口（比如让
Car持有Engine类型的字段） - 若使用继承，父类应尽量抽象、稳定，避免含具体实现逻辑（尤其是非
protected的可变字段） - Java 中
final类（如String）或private构造器类（如Collections工具类）天然排斥继承，这时组合是唯一选择
组合更易测试和替换，继承破坏封装
组合对象可以轻松被 mock 或替换，比如单元测试中把真实的 DatabaseService 换成 MockDatabaseService；而继承关系下，子类直接依赖父类的实现细节，测试时几乎无法隔离。
性能上差异极小，但可维护性差距明显：继承链越深，修改成本越高；组合则通过接口契约解耦，各模块演进互不干扰。
立即学习“Java免费学习笔记（深入）”；
- 用组合时，优先依赖接口而非具体类（
private DataSource dataSource而非private MySQLDataSource dataSource） - 避免在父类里暴露
protected方法供子类调用——这等于把内部逻辑“拱手让人”，后续想改都得同步通知所有子类 - IDE 重构时，“提取超类”（Extract Superclass）容易诱使人盲目建继承，要警惕；而“提取接口”（Extract Interface）+ 组合更安全
Liskov 替换原则（LSP）是继承的硬门槛
如果子类不能在任何场景下无缝替代父类，那继承就是错的。典型反例：Square extends Rectangle —— 当调用 setHeight() 时，正方形必须同步改宽度，违背了父类对长宽独立控制的契约。
这种问题不会在编译时报错，但运行时行为诡异，且难以调试。组合则天然规避这类陷阱，因为“拥有”不承诺行为一致性。
- 检查子类是否重写了父类方法并改变了前置/后置条件（比如父类允许
null参数，子类抛NullPointerException） - 子类不应缩小父类方法的访问权限（如父类
public，子类改成protected） - 一旦发现子类需要
instanceof判断自身类型再分支处理，大概率已违反 LSP，应回退到组合 + 策略模式
Java 8+ 默认方法让接口也能复用逻辑，进一步削弱继承必要性
过去接口只能定义契约，现在 default 方法允许提供默认实现，配合组合，能覆盖大部分“想复用又不想继承”的场景。
例如日志能力，不必让所有业务类继承 BaseLogger，而是定义 Loggable 接口带 default void log(String msg)，再由各类自行 implements Loggable 并组合具体日志器。
- 注意
default方法不能访问实现类的私有字段，所以它适合通用行为（格式化、转发），不适合强状态耦合逻辑 - 若多个
default方法存在冲突（如两个接口都定义了同签名default方法），实现类必须显式重写，这反而强化了设计意图的表达 - 比起继承，这种方式更轻量，且不强制类层级结构，对已有类添加能力零侵入
