“组合优于继承”指多数场景应优先用“has-a”关系替代“is-a”关系，以降低耦合、增强可测性与系统稳定性；继承适用于明确“is-a”且父类专为扩展设计的少数情况。
“组合优于继承”不是说继承不能用，而是指在大多数需要复用代码的场景下，优先用“has-a”关系（组合）代替“is-a”关系（继承）。它背后的核心诉求是：降低耦合、增强可测性、避免隐性依赖，让系统更稳定、更易演进。
组合与继承的本质区别
继承表达的是“是一个”，比如 Dog extends Animal，意味着狗本质上是一种动物；组合表达的是“有一个”，比如 Car 类里包含一个 Engine 对象，说明车拥有引擎，但车本身不是引擎。
这种语义差异直接决定了它们的适用边界：
- 继承在编译期就固定了父子关系，子类深度依赖父类的实现细节
- 组合在运行期才决定具体使用哪个对象，成员变量可以随时替换（比如换不同型号的引擎）
- 继承会暴露父类的 protected 方法和字段，破坏封装；组合只通过公开接口通信，封装性更强
为什么组合更安全、更灵活
继承容易引发“脆弱基类问题”——父类一个看似无害的修改（如重写某个方法、调整构造逻辑），可能让所有子类行为异常。而组合把功能拆成独立组件，每个组件职责单一、可单独测试、可独立升级。
立即学习“Java免费学习笔记（深入）”；
典型好处包括：
- 支持运行时行为切换：比如一个 NotificationService 类，可通过注入不同的 SmsSender 或 EmailSender 实例，动态改变通知方式
- 天然契合接口编程：组合常配合接口使用（如 private Drawable drawer;），便于用 mock 对象做单元测试
- 规避单继承限制：Java 只允许单继承，但一个类可以组合任意多个对象，扩展能力更强
哪些情况仍适合用继承
继承并非被弃用，而是适用范围更窄。当满足以下全部条件时，才建议考虑继承：
- 语义上确实是明确的“is-a”关系（如 ArrayList 是一种 List）
- 父类设计为被继承（有 protected 合理、有 template method 模式、文档明确说明可扩展）
- 子类需要重写父类行为，且该行为属于同一抽象层次（如 draw() 在所有图形中都存在，只是实现不同）
反例：不要让 TimerTask 继承 Thread，而应让其持有 Runnable；不要让 StringBuilder 继承 String，它内部组合字符数组——这些正是 JDK 自身践行“组合优先”的体现。
实际编码中的组合写法要点
组合不是简单地加个字段，关键在于如何组织：
- 成员变量通常声明为接口类型（如 private DataSource dataSource;），而非具体实现类
- 通过构造器或 setter 注入依赖，避免在类内部 new 具体对象（利于解耦和测试）
- 对外提供清晰的委托方法（如 public void save(User u) { dao.save(u); }），不暴露内部组合对象
- 必要时用组合+策略模式/装饰器模式，进一步提升灵活性
不复杂但容易忽略：组合不是替代继承的银弹，而是更可控、更可持续的复用选择。
