“组合优于继承”是对业务动态性的响应，继承适用于稳定不可逆的“是一种”关系，组合适用于可变协作的“有一个”关系；组合落地需字段私有、构造注入、校验非空、委托收口；接口+运行时决策实现柔性多态，避免继承导致的隐性锁死。
“组合优于继承”不是一句口号，而是对业务变化本质的回应——复杂系统里，关系常是动态的、可插拔的、非结构性的。真正落地时，关键不在语法怎么写，而在每次建模前多问一句：这个关系，是“是一种”，还是“有一个”？
先划清边界：哪些场景必须用继承，哪些天然该用组合
继承适用于稳定、不可逆、语义明确的层级结构。比如：
– AdminUser 是 User 的一种
– PDFWriter 是 Writer 的一种
– Dog 是 Animal 的一种
这些关系在业务生命周期内不会反转、不会拆解、不会临时替换。
而组合适用于行为可变、来源多样、职责分离的协作关系
- 订单（Order）包含多个商品（Product），但订单不是商品的一种
- 用户（User）拥有一个收货地址（Address），但用户不是地址的一种
- 支付服务（PaymentService）使用微信SDK或支付宝SDK，但它本身不是任一SDK的子类
一旦把“has-a”硬写成“is-a”，后续加渠道、换策略、做灰度、隔离故障，都会变成牵一发而动全身的重构。
组合落地四步法：从字段声明到策略切换
组合不是简单 new 一个对象塞进字段，它是一套轻量但完整的控制契约：
- 字段声明用 private final：保证不可变性，避免运行时被意外覆盖
- 依赖通过构造器注入：不 new 具体实现，也不用 static 工厂；便于单元测试 mock，也利于 Spring 管理生命周期
- 校验非空 + 拒绝 setter：Objects.requireNonNull(processor, "processor must not be null")；除非真有运行时策略切换需求（如 AB 实验），否则不暴露 set 方法
- 委托方法要“收口”，不能裸转调：不是 return processor.pay() 就完事，而是在调用前后加入风控、日志、重试、降级、统一异常包装等业务拦截点
用接口+运行时决策替代继承树膨胀
继承靠 extends 做静态多态，组合靠接口 + 动态注入实现更柔性的多态。例如支付策略：
- 定义统一接口：
interface PaymentStrategy { void execute(Order order); } - 各渠道独立实现：
WechatPayStrategy、AlipayStrategy、BalancePayStrategy - 业务类只持有接口：
private final PaymentStrategy strategy; - 策略由上层决定：Spring Profile 控制环境差异，或根据
order.getChannel()工厂路由，甚至从配置中心实时拉取
新增支付方式？只需加一个实现类 + 配置映射，完全不碰原有 OrderService 或 PaymentService 的代码。
警惕继承的隐性锁死效应
继承一旦确立，就锁死了类型语义和演化路径。比如：
- 写
class Square extends Rectangle，数学上成立，但程序中setHeight()和setWidth()无法独立调用，违反 Liskov 替换原则 - 写
class VIPUser extends User，看似合理，但如果 VIP 特权需按等级动态调整（青铜/白银/黄金）、且不同渠道开通方式不同，继承就会迅速僵化 - 父类方法被子类重写后，若父类逻辑升级（如增加风控校验），子类可能因绕过 super 调用而漏掉新规则
这类问题在单体演进为微服务、或接入三方 SDK 时集中爆发。组合则天然支持“解耦+替换+熔断”，比如把微信 SDK 封装成 WechatClient 实例，出问题时可一键替换成降级版 DummyWechatClient，不影响订单主流程。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
