应从高频协作业务类中识别真实共性再建父类，命名需体现业务意图如auditableentity，避免伪共性与base泛称，构造器显式调用super，用重写替代if-else分支，警惕@deprecated、unsupportedoperationexception和非通用参数等继承滥用信号。

从真实业务类中识别可提取的共性

别一上来就建 BaseEntity 或 CommonModel。打开你正在重构的模块，挑出 2–3 个高频协作的业务类（比如 OrderService、RefundService、InvoiceService），逐行比对它们的字段和方法：

• 是否都含 id、creatorId、createdAt、status（且类型和语义一致）？
• 是否都有类似 validateBeforeSubmit()、toDto()、logOperation() 这类逻辑高度相似的方法？
• 注意排除“名字相同但含义不同”的伪共性：比如都叫 code，但一个是订单号（全局唯一）、一个是状态码（枚举值）、一个是渠道编码（固定字符串）——这三者不能塞进同一个父类。

用 extends 建立清晰的继承边界

新建父类时，名称要体现业务意图，而不是技术泛称。例如：

• 如果共性集中在“可审核、可撤回、带操作日志”的流程实体，就叫 AuditableEntity；
• 如果共性是“支持多租户隔离、按 orgId 路由”，就叫 TenantScopedModel；
• 避免使用 Base、Abstract 开头的命名，除非它确实承担抽象契约职责（如定义模板方法）。

子类声明继承后，父类的 protected 字段可直接访问，public 方法自动可用。构造器必须显式调用 super(...) —— 即使父类有无参构造器，也建议显式写出，提升可读性和未来兼容性。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

把差异逻辑交给重写，而不是 if-else

当某个行为在各子类中实现不同，但调用入口一致时，才适合抽取为父类方法并允许重写：

• 比如 calculateFee() 在订单中按金额阶梯算，在退款中按原单比例扣，在发票中按税点折算 —— 这就是典型的重写场景；
• 在父类中写 if (this instanceof Order) { ... } else if (this instanceof Refund) { ... } 是反模式，破坏开闭原则，也阻碍后续新增子类；
• 重写时可复用父类逻辑：super.preCheck(); doCustomValidation();，保持扩展性与一致性平衡。

警惕继承滥用的三个信号

出现以下任一情况，说明当前抽取可能过度或方向错误：

• 父类里开始出现大量 @Deprecated 字段或方法，只被 1 个子类使用；
• 某个子类频繁覆盖父类方法，且重写体里几乎全是 throw new UnsupportedOperationException()；
• 为了兼容某子类特殊需求，父类被迫添加非通用参数（如 boolean isForInvoiceExport），导致其他子类调用时传 false 成为默认姿势。

这时应考虑组合替代继承，或拆分更小粒度的接口/模板类。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南