重构臃肿父类的关键是识别职责、拆分边界、用组合替代继承；需诊断代码信号（如方法混杂、大量UnsupportedOperationException、if-instanceof分支等），按能力维度提取为Auditable、TenantScoped等组件，保留父类最小核心，逐步迁移并验证行为一致性。
重构臃肿父类的关键不是删减，而是识别职责、拆分边界、用组合替代“一锅炖”。父类变胖，往往是因为它既管身份、又管行为、还掺着日志、缓存、权限等横切逻辑——这不是继承的问题，是职责错配。
先诊断：哪些信号说明父类已经臃肿？
别靠直觉，看代码现实：
- 父类超过 300 行，且方法类型混杂（比如同时有
save()、logOperation()、generateToken()、validateForExport()） - 子类中大量重写方法，但重写体里只有一行
throw new UnsupportedOperationException(); - 新增一个业务子类时，必须修改父类加
if (this instanceof Xxx) { ... }分支 - 父类构造器里调用了可被重写的方法，或初始化了多个不相关组件（如同时 new Logger、CacheClient、EmailService）
拆解策略：把父类按能力维度切分成可插拔组件
不是“砍掉父类”，而是把它的能力解耦成独立角色：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
审计能力 → 提取为
Auditable接口 +AuditSupport组件（含createdAt、lastModifiedBy字段和recordAudit()方法） -
多租户隔离 → 单独抽象
TenantScoped接口 +TenantContextHelper类，子类按需持有 -
通用校验 → 不塞进父类，改用
@Valid注解配合自定义 ConstraintValidator，或封装ValidationChain工具类 - 原父类保留最小核心：仅含真正共有的领域字段（如
id、status）和最基础契约方法（如isValid()），其余全下沉或外移
迁移路径：保持兼容，逐步替换
避免一次性大改导致编译失败或测试崩塌：
立即学习“Java免费学习笔记（深入）”；
- 第一步：让原父类实现新提取的接口（如
implements Auditable, TenantScoped），内部仍用老字段，但对外暴露标准方法 - 第二步：在子类中新增组合字段（如
private final AuditSupport audit = new AuditSupport();），并用 IDE 的 “Replace Inheritance with Composition” 功能自动代理调用 - 第三步：将子类对父类日志/缓存等方法的调用，逐步替换成通过组合对象访问；旧方法标记
@Deprecated，但暂不删除 - 所有委托方法保持签名一致（如
log(String msg)），确保下游无需改调用方代码
收尾验证：确保行为没变，只是结构更清
重构不是炫技，是让代码更可靠：
- 运行全部单元测试，尤其关注父类方法被子类重写后的场景是否仍通过
- 检查 HashMap/Set 等集合使用 —— 若曾重写
equals()却漏了hashCode()，现在一并补上 - 确认子类构造器中
super(...)调用仍正确，且不再依赖父类中已移出的字段初始化逻辑 - 用 IDE 的 “Find Usages” 确认旧父类方法被调用的位置已收敛，没有遗漏的隐式依赖
