抽象类设计重构的核心是编译期强制契约：将订单号生成、支付解析等不可妥协逻辑抽为稳定签名的抽象方法；用final模板方法固化主干流程，仅doBusiness()可变；钩子方法（如onPaymentSuccess）为空实现以支持可选扩展；禁止构造器中调用抽象方法，子类须实现全部未覆盖抽象方法且访问修饰符不得更严格。
抽象类设计重构的核心，是把“哪些逻辑必须由子类决定”这件事，提前在编译期卡死。不是靠文档提醒、不是靠代码审查，而是让没实现的子类根本编译不过。
明确哪些行为属于强制契约
先区分业务中不可妥协的部分：比如订单号生成规则、支付结果解析格式、审批通过前的校验项。这些不是“可以有”，而是“必须有”。把它们抽成抽象方法，签名要稳定——参数类型用基础类型或领域内通用DTO，返回值明确语义（如String generateOrderNo()、boolean validateRequest(Request req)）。避免用模糊类型如Object或泛型未限定的List，否则子类容易随意应付。
用模板方法固化主干流程
光有抽象方法只能保证“有这个方法”，但无法控制它什么时候被调用、前后做什么。这时要把不变的骨架写进final方法里，把可变环节留给抽象方法填空：
- 比如统一处理流程：
preCheck() → doBusiness() → postLog() → notify()，其中只有doBusiness()是abstract - 所有公共逻辑（事务开启、异常包装、耗时监控）都放在模板方法内部，子类不操心顺序，只专注自己的那一段
- 子类若删掉
doBusiness()实现，编译直接报错，不会等到上线才发现流程中断
合理使用钩子方法支持可选扩展
不是所有扩展点都需要强制。有些逻辑是“做了更好，不做也不影响主干”，比如支付成功后发审计日志、风控拦截后记录原因。这类用空的protected方法定义为钩子：
- 命名带
onXXX或afterXXX前缀，如onPaymentSuccess()、afterReject() - 默认为空实现，子类按需重写，不破坏原有契约
- 避免把钩子写成抽象方法，否则把可选变成了强制，违背设计初衷
注意初始化安全与继承链责任
抽象类可以有字段和构造器，但别在父类构造过程中调用抽象方法。因为此时子类构造器还没执行，字段还是默认值（null、0），极易引发空指针。另外，抽象方法的约束会逐层传递：
- 如果中间子类也是
abstract，它可以不实现父类抽象方法，作为过渡层进一步细化职责 - 但最终的具体子类，必须实现从顶层抽象类开始的所有未覆盖的抽象方法
- 子类实现时，访问修饰符不能比父类更严格（
public父类方法，子类不能写private），参数和返回类型要保持协变兼容
