Java继承与组合如何选择？

本文深入探讨了Java中继承与组合的选择之道，强调应优先采用组合而非继承——因为组合通过“有一个”（has-a）关系实现松耦合、高内聚、易测试和可动态替换的代码复用，而继承仅适用于语义清晰、稳定且严格满足Liskov替换原则的“是某种类型”（is-a）关系；文章不仅剖析了继承带来的脆弱基类、强耦合与扩展受限等隐患，也展示了组合如何借助接口、依赖注入和设计模式（如策略模式）构建更健壮、灵活和可维护的系统，并以Stack误用Vector的经典案例生动揭示：复用目的绝不能凌驾于语义准确性和设计原则之上。

继承和组合都是实现代码复用的方式，但语义、灵活性和维护性差异很大。优先用组合，仅在“是某种类型”（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