抽象类实现接口部分方法可减少子类编码量与出错风险，核心是将稳定通用逻辑（如校验、日志、结果包装）收拢到父类，子类仅聚焦定制业务；通过模板方法固化流程顺序，提供钩子和可覆盖的protected方法，支持灵活扩展；相比default方法，抽象类能访问实例状态、支持构造器和字段初始化，更适合需共享资源或上下文的场景。
抽象类实现接口的部分方法，能直接减少子类的编码量和出错风险。核心不是“少写几个方法”，而是把稳定、通用、易重复的逻辑收拢到父类中，让子类只聚焦真正需要定制的业务点。
把共性行为抽到抽象类里
当多个子类对接口的某些方法实现高度一致时（比如参数校验、日志记录、结果包装），就在抽象类中提供具体实现。子类继承后自动获得这些能力，无需再写一遍。
- 例如接口 OrderProcessor 定义了
validate()、execute()、notify()、rollback()四个方法 - 其中
validate()总是检查金额和状态，notify()总是调用统一消息服务 - 抽象类 AbstractOrderProcessor 就可直接实现这两个方法，只把
execute()和rollback()声明为abstract - 子类如
PromotionOrderProcessor只需实现那两个抽象方法，其余开箱即用
用模板方法固化流程顺序
如果接口方法之间存在固定执行逻辑（比如必须先校验、再处理、最后通知），就把整个流程写成一个 final 方法，在抽象类中调度各环节。
- 模板方法内部调用
doValidate()、doExecute()、doNotify()等 protected 方法 - 其中
doValidate()和doNotify()提供默认空实现或基础实现 - 子类按需重写
doExecute()，或选择性覆盖doNotify()来增强通知逻辑 - 流程骨架不被破坏，子类自由度又足够高
比接口 default 方法更灵活
Java 8 的 default 方法虽能提供默认实现，但它无法访问实例字段、不能有构造器、也不支持 protected 工具方法。一旦逻辑涉及上下文状态或资源管理，抽象类就是更自然的选择。
- 比如退款服务需要共享缓存客户端、配置对象或线程安全的计数器——这些都得靠抽象类的字段和构造器初始化
- 子类复用同一份
RetryTemplate或HttpClient实例，避免每个类自己 new 一份 - 抽象类还能提供
protected final String getChannelPrefix()这样的钩子，让子类声明自身标识而不暴露细节
预留扩展点，避免一刀切
默认实现不是终点，而是起点。设计时要主动留出可插拔的位置，方便子类在不破坏主流程的前提下做微调。
- 在关键步骤前后添加
beforeExecute()和afterExecute()钩子，默认为空方法 - 把硬编码的常量（如超时时间、重试次数）提取为
protected static final字段，子类可直接引用或覆盖 - 对可能变化的策略（如幂等校验方式），通过构造器注入或抽象方法获取，而不是写死在模板里
- 确保默认实现具备 null 安全、异常透传和线程安全，否则子类会陷入修 bug 的泥潭
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
