抽象类适合封装日志记录、参数校验、统一异常处理、数据库连接初始化、缓存操作模板等多子类共用且不可独立实例化的基础服务，通过模板方法模式区分固定流程与可变环节，结合protected final模板方法、default钩子方法和abstract核心方法实现高复用与强契约性。
抽象类在 Java 中常被用来封装公共基础服务，它既能定义通用行为规范，又能提供可复用的具体实现，是构建分层架构和避免重复代码的重要手段。
抽象类适合封装哪些基础服务
适合封装那些多个子类都需要、但又不能独立实例化的通用能力，比如日志记录、参数校验、统一异常处理、数据库连接初始化、缓存操作模板等。这些服务通常有固定流程，但部分步骤需由子类定制。
- 日志：统一记录方法进入、执行耗时、返回结果（可留钩子让子类补充业务日志）
- 校验：前置校验通用参数（如非空、ID格式），再调用子类特有的业务校验逻辑
- 异常包装：将底层异常统一转换为业务异常码和消息，子类只需关注“该抛什么业务异常”
- 资源管理：模板方法中自动开启/关闭连接或事务，子类只写核心业务逻辑
如何设计一个实用的基础抽象服务类
关键在于区分“固定流程”和“可变环节”，用模板方法模式组织结构。把不变的部分写死在抽象类里，把变化的部分声明为 abstract 方法或提供默认空实现的 hook 方法。
- 定义 protected 的 final 模板方法（如 execute()），内部按顺序调用 preCheck() → doBiz() → postHandle()
- preCheck() 和 postHandle() 可设为 default 方法，子类按需重写；doBiz() 必须 abstract
- 提供通用工具字段或方法（如 Logger、JsonUtils、ResponseBuilder），避免子类重复引入
- 构造函数中完成基础依赖注入（如 ServiceTemplate 构造时传入通用配置或客户端）
注意与接口、普通父类的区别
抽象类不是万能替代品。它比接口多出状态和具体实现能力，但单继承限制要求谨慎选择继承链。相比普通父类，抽象类更强调“强制子类参与协作”的契约性。
- 要用状态（如共享的 retryCount、timeoutMs）或复用代码 → 选抽象类
- 只定义行为契约，且可能被多类型实现（如 Controller、Job、MQ Consumer 都要支持 traceId）→ 接口更合适
- 纯工具方法集合（无状态、无子类差异）→ 直接用工具类 + static 方法
- 若已有父类，又想复用基础服务 → 考虑组合而非继承，把抽象服务类作为成员变量委托调用
一个简单示例：通用查询服务抽象类
比如多个业务查询都需统一处理缓存穿透、慢 SQL 日志、结果脱敏，但查什么数据各不相同：
- 抽象类定义 queryWithCache(String key, Supplier
dbLoader) 为 final 方法 - 内部先尝试从 Redis 获取，为空则调用 dbLoader 加载，并写入缓存
- 子类只需实现 buildCacheKey() 和 loadFromDb() 两个抽象方法
- 额外提供 maskResult(T result) 默认空实现，需要脱敏的子类才重写
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
