合成复用原则主张优先使用对象组合而非继承实现复用，因组合降低耦合、支持运行时替换、利于职责分离；继承仅适用于语义清晰的“is-a”关系。
合成复用原则（Composite Reuse Principle, CRP）主张优先使用对象组合（或聚合），而非类继承来实现代码复用。这不是教条，而是基于软件可维护性、灵活性和演化成本的理性权衡。
继承带来强耦合，修改风险高
子类与父类形成“白箱复用”：子类直接访问父类的实现细节（包括非私有字段和方法），一旦父类内部逻辑调整（如方法重命名、参数变更、行为重构），所有子类都可能连锁出错。例如，一个 PaymentProcessor 类若被多个支付渠道（AlipayProcessor、WechatProcessor）继承，当父类新增风控校验逻辑并改变构造流程时，各子类必须同步适配，否则编译失败或运行异常。
组合支持运行时动态替换，扩展更自然
通过组合，类型依赖的是抽象（如接口或抽象类），具体实现可在运行时注入或切换。常见做法包括：
- 将变化的部分提取为独立组件（如 NotificationService、Logger）
- 主类持有该组件的引用，并通过构造函数或 setter 注入
- 需要更换策略时，只需传入新实例，无需改动主类结构
比如订单服务 OrderService 不继承某个特定的 DiscountPolicy，而是组合一个 IDiscountStrategy 接口；促销活动上线时，直接注入 SeasonalDiscount，下线后换成 MemberDiscount，主逻辑零修改。
继承易导致层级臃肿，组合更利于职责分离
多层继承（A → B → C → D）会使类关系晦涩，调试困难，且违背单一职责。而组合天然鼓励“小而专”的组件设计：每个类只专注一件事，通过协作完成复杂功能。例如，用户实体 User 不应继承 AuthCapable 或 ReportGenerator，而应分别组合 IAuthenticator 和 IReportBuilder —— 身份验证逻辑和报表生成逻辑彼此隔离，测试、复用、替换都更轻量。
并非完全排斥继承，关键看语义是否成立
继承应严格用于表达“is-a”关系，且父类是稳定、可复用的抽象。例如：Dog 是 Animal，ArrayList 是一种 List —— 这类语义清晰、契约稳定的场景，继承合理。但若只是为了复用几个方法就强行建父子关系（如让 Order 继承 Timestamped），就违背了Liskov替换原则，也埋下维护隐患。此时用组合（如引入 TimestampedMixin 或直接包含 DateTime created 字段）更稳妥。
