组合优于继承的关键在于按生命周期、复用性、可测试性拆分；避免接口宽泛、抽象类滥用、字段可变失控，聚焦小接口和不可变设计。
用组合代替继承时，怎么判断该拆哪个类
继承容易让类耦合变紧，改父类就可能牵连一堆子类。组合更灵活，但新手常卡在“到底该把哪块逻辑抽成独立类”。关键不是看功能多大，而是看它有没有自己的生命周期、会不会被复用、是否需要单独测试。
- 如果某段逻辑会随业务变化频繁修改（比如不同渠道的订单校验规则），就该拆成
OrderValidator这样的策略类，而不是塞进OrderService里 - 如果一个类里有超过两个
new XXXImpl()，且这些实例只在局部方法用，大概率说明它承担了创建职责，该交给工厂或依赖注入容器 - 注意
java.util.Date和java.time.LocalDateTime的混用——前者不可变性差、线程不安全，硬套进继承体系里后期很难替换，直接用组合包装一层更稳妥
接口定义太宽泛，导致实现类被迫写一堆空方法
典型症状是实现类里堆着十几个 @Override，其中一大半是 throw new UnsupportedOperationException()。这不是设计灵活，是接口没聚焦。
- 按使用方来切接口：比如
PaymentProcessor接口，别一股脑塞上refund()、cancel()、queryStatus()，支付网关和退款网关根本不会同时调用全部方法 - 优先定义小而专的接口，如
Refundable、Cancelable，让具体类按需实现，避免“实现即背锅” - 警惕
Object类方法污染接口：像toString()、hashCode()被强行抽象进业务接口，后续加字段就得同步改所有实现，纯属自找麻烦
过度使用抽象类，反而锁死扩展路径
抽象类自带模板方法和默认实现，看着省事，但一旦定下钩子方法签名，下游就很难绕开。比如 AbstractReportGenerator 强制所有子类走 beforeRender() → doRender() → afterRender() 流程，结果新需求要异步导出 PDF，流程完全不匹配。
- 能用接口的地方不用抽象类；抽象类只在“必须共享状态 + 必须强制执行固定流程”时才考虑
- 抽象类里的非 final 方法，如果参数类型是具体类（如
process(User user)），比用接口+泛型（<t extends user> process(T user)</t>）更难适配未来子类型 - Spring 中常见陷阱：
@Configuration类继承抽象配置类，结果抽象类里用了@Bean方法，导致子类无法覆盖 bean 定义——这种“配置继承”几乎等于给自己埋雷
字段可变性失控，导致谁都能改谁都不敢动
一个 public 字段、一个没加 final 的集合、一个返回内部数组的 getter，三者叠加，基本宣告这个类进入“只敢读不敢碰”状态。
立即学习“Java免费学习笔记（深入）”；
- 所有字段默认加
private，暴露行为（方法）而非状态（字段）；集合类一律用Collections.unmodifiableList()包裹后返回 - getter 不要返回可变对象引用：比如
getAddress()返回Address对象可以，但返回address.getDetailMap()就危险，应该返回副本或不可变视图 - 构造器里别直接赋值外部传入的可变对象，尤其
java.util.Calendar、byte[]这类，要用clone()或Arrays.copyOf()防止外部篡改
可维护性的核心不在结构多漂亮，而在“改一处时，你能准确说出影响范围”。很多问题不是出在没用设计模式，而是字段权限、接口粒度、组合边界这些基础控制没做实。稍不注意，三年后的自己打开代码，第一反应不是“我当年真聪明”，而是“这玩意谁敢动”。
