抽象类应提取稳定流程骨架并声明变体为抽象方法，如通知流程中校验、日志等通用逻辑放父类，消息组装与发送交由子类实现；支持默认行为覆盖、protected字段与构造注入；避免过度抽象，差异大时改用接口+独立实现；接口定义能力契约，抽象类专注内部复用。
抽象类提取公共逻辑，核心是识别“稳定不变的骨架”和“必须由子类决定的变体”，把前者抽到父类，后者声明为抽象方法留给子类实现。
找准可复用的流程骨架
公共逻辑通常出现在一组类共有的执行步骤中，比如支付、通知、文本处理这类有固定阶段的业务。例如下单后发通知，不管邮件、短信还是推送，都绕不开“组装消息内容→校验渠道参数→调用发送接口→记录日志”这几个环节。这些环节中，校验和日志往往通用，只有“调用哪个接口”和“怎么组装内容”因渠道而异。
- 把校验参数、记录日志、统一异常包装等代码写进抽象类的普通方法里
- 把“生成消息体”“执行发送”声明为 abstract 方法，强制子类提供具体实现
- 用模板方法模式封装整个流程，比如定义 final 的 send() 方法，内部按序调用 checkParams()、buildMessage()、doSend()、logResult()
保留可配置的默认行为
不是所有逻辑都非得抽象，有些可以给默认实现，让子类按需覆盖。比如所有通知渠道都要设置超时时间，但微信可能用 3 秒、短信用 5 秒、推送用 2 秒——这时可以在抽象类里定义 protected int getTimeout() { return 3000; }，子类只需重写该方法，不必动整个流程。
- 字段（如 baseUrl、apiKey）可在抽象类中声明为 protected，子类直接访问
- 构造器可接收通用参数（如 RestTemplate、Logger），完成基础依赖注入
- 避免在抽象类中硬编码具体值，用可被子类覆盖的方法或配置项替代
警惕过早抽象与强耦合
抽象类不是万能收纳盒。如果新加的子类流程差异太大（比如云闪付要走预下单+跳转+对账三步），强行塞进原有抽象类，就会出现大量 if (type == XXX) 或空实现，违背设计初衷。
- 当子类间公共逻辑少于 50%，或流程分支超过两个明显路径时，考虑改用接口 + 独立实现类
- 抽象类中不要包含只服务于某一个子类的私有逻辑，也不应加载特定环境的资源（如某个渠道专用的证书）
- 若测试需要 Mock，但抽象类绑死了真实依赖（如数据库连接），说明抽象层级过高，应拆出策略接口解耦
配合接口明确能力契约
抽象类负责“怎么做”，接口负责“能做什么”。比如定义一个 NotificationService 接口，只声明 void send(String content)，所有通知实现类都必须支持；再让 EmailSender、SmsSender 继承同一个 AbstractNotification 类，共享重试、限流、日志等逻辑。
- 对外暴露类型优先使用接口（如 NotificationService service = new EmailSender()）
- 抽象类专注内部复用，不暴露给调用方；它是实现细节，不是 API 合约
- 一个类可以实现多个接口，同时继承一个抽象类，二者分工清晰：接口定边界，抽象类填内容
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
