继承与组合：Java开发选择指南

本文深入剖析了Java中继承与组合这两种代码复用机制的本质区别与适用边界，强调应摒弃“为复用而继承”的惯性思维，坚定奉行“优先使用组合”的现代设计原则；只有当存在清晰、稳定且符合Liskov替换原则的is-a关系，并满足父类明确支持扩展等严苛条件时，继承才成为合理选择，而组合凭借其松耦合、高可测、易替换和运行时灵活性，已成为构建健壮、可维护、可演进Java系统的核心实践——读懂这一取舍，往往就是区分新手与成熟开发者的分水岭。

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