组合优于继承的核心在于将交叉业务维度拆为可插拔组件，使主类职责单一：识别重叠维度→抽象为接口（如ITaxPolicy）→主类仅持引用并协调调用→新增维度只需扩展接口实现而不改原有代码。
当对象因多个业务维度交叉而不断添加字段、方法和条件分支，变量就容易臃肿、耦合、难以测试——这不是代码量问题，而是结构问题。组合优于继承的实战价值，正在于把“维度”拆成可插拔的组件，让主类回归职责单一。
识别导致臃肿的维度重叠点
先别急着改代码，先看哪些地方在“硬塞”不相关的职责：
- 一个类同时承担“支付方式”“地区规则”“用户等级”“促销类型”等逻辑判断，if-else 层层嵌套
- 为支持新场景（如“海外+学生+分期”），不断新增 protected 字段或虚方法，子类被迫覆盖大量空实现
- 字段名出现类似 isOverseasDiscountApplicable、shouldSkipTaxForVip 这类长命名——说明语义已超出类本意
- 单元测试用例数随维度呈指数增长（2种支付 × 3个地区 × 4类用户 = 24个组合）
把每个维度抽象为接口+实现组件
不是删字段，而是把字段背后的“行为意图”拎出来，封装成独立组件：
- 将“地区规则”提取为 ITaxPolicy 接口：含 calculateTax(amount)、isTaxExempt()
- 将“用户等级权益”提取为 IPromotionEligibility：含 canUseCoupon()、getCashbackRate()
- 将“支付通道适配”提取为 IPaymentGateway：含 authorize()、capture()
- 每个接口对应多个轻量实现类（如 VatTaxPolicy、StudentEligibility、StripeGateway），彼此无依赖
主类只持组件引用，不继承任何业务基类
原臃肿类（如 OrderService）不再承载逻辑，只负责协调：
- 声明私有字段：private final ITaxPolicy taxPolicy;、private final IPromotionEligibility eligibility;
- 构造函数注入所有策略，或通过 DI 容器按配置自动装配
- 核心方法如 process() 只调用 taxPolicy.calculateTax(...) 和 eligibility.canUseCoupon(...)，不写 if 判定维度
- 若某次请求需临时切换策略（如灰度测试新税率），直接 order.setTaxPolicy(new BetaVatPolicy())
新增维度不再动主类，只需加接口和实现
当业务要求支持“碳中和订单”时：
- 新增 ICarbonOffsetPolicy 接口和 TreePlantingOffset 实现类
- 修改 OrderService 构造函数，增加该组件参数（或扩展 Builder）
- 在 process() 中插入一行 offsetPolicy.apply(order)，其他逻辑完全不动
- 旧测试用例仍全绿；新维度可单独测 TreePlantingOffsetTest
变量臃肿的本质是职责混杂，而非功能太多。用组合划清边界后，每个组件可独立演进、替换、监控——系统不再是单体巨石，而是一组协作清晰的乐高模块。
