优先使用组合而非继承，仅在明确稳定的is-a关系且符合liskov替换原则时才用继承；组合通过has-a关系实现灵活、解耦、可测试的复用，避免继承的强耦合与脆弱基类问题。
继承和组合都是实现代码复用的方式，但语义、灵活性和维护性差异很大。优先用组合，仅在“是某种类型”（is-a）关系明确且稳定时才考虑继承。
继承：适合表达清晰的 is-a 关系
继承表示子类是父类的一种特例，比如 Student 是 Person、ArrayList 是 List。Java 中用 extends 实现，子类自动获得父类的非私有成员，并可重写方法。
但继承会带来强耦合：父类修改可能破坏子类行为；子类被迫继承所有细节（包括不需要的）；无法在运行时切换父类逻辑。
- 父类设计需预留扩展点（如模板方法、protected 钩子），否则子类容易误用
- 一旦继承了具体类（而非抽象类或接口），就难以替换底层实现
- 多重继承不支持，只能单继承，限制建模能力
组合：更灵活、更可控的复用方式
组合体现“有一个”（has-a）关系，比如 Car 有一个 Engine、OrderService 有一个 PaymentProcessor。通过持有其他类的实例并委托调用实现功能。
它把依赖显式暴露出来，便于测试（可注入模拟对象）、替换（运行时换不同实现）、控制生命周期（按需创建/销毁）。
- 可通过接口组合，完全解耦实现细节
- 支持动态行为变更（如策略模式中切换算法）
- 避免继承带来的脆弱基类问题（Fragile Base Class Problem）
选择原则：看关系本质，而非复用便利性
不要因为“能复用代码”就选继承——那是对继承的误用。真正该用继承的场景非常有限：
- 父类是为被继承而设计的（文档明确说明可扩展，有 protected 方法、空构造等）
- 子类确实属于父类的逻辑子类型，且 Liskov 替换原则成立（子类对象可安全替换父类位置）
- 框架要求（如 Servlet 继承
HttpServlet、JUnit 测试类继承TestCase）
其余情况，尤其是想复用功能、封装行为、构建可配置组件时，一律优先用组合。现代 Java 开发中，组合配合接口、依赖注入（如 Spring）、函数式接口，已能优雅覆盖绝大多数需求。
一个典型误用与修正示例
错误写法：class Stack extends Vector { ... } —— Stack “不是” Vector，只是内部用到了类似数组的行为；Vector 的 public 方法（如 addElement()）暴露给 Stack 用户，破坏了栈的语义。
正确做法：class Stack { private List<object> data = new ArrayList(); ... }</object> —— 只暴露 push/pop/peek，内部实现可随时换成 LinkedList 或线程安全容器，不影响使用者。
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
