抽象类是大型系统架构稳定与演进的关键构件：它强制子类实现核心契约、复用通用逻辑、支持模板方法模式、承载领域状态与可变配置，兼具约束性与扩展性。
抽象类在大型系统设计中不是“可有可无的装饰”，而是支撑架构稳定性和演进能力的关键构件。它既不是纯契约（如接口），也不是完全实现的实体（如普通类），而是在两者之间提供可控的中间层——既能统一规范，又能沉淀共性逻辑。
定义核心契约并约束子类行为
大型系统中模块间协作依赖清晰、不可绕过的约定。抽象类通过强制子类实现抽象方法，把“必须做什么”从文档或口头约定变成编译期检查。
- 例如，在订单处理系统中定义 abstract class OrderProcessor，声明 abstract boolean validate() 和 abstract void execute()，确保所有具体处理器（如 CreditOrderProcessor、GiftCardOrderProcessor）都完成校验与执行逻辑，避免因遗漏导致生产事故
- 与接口不同，抽象类还能配合 final 方法锁定关键流程（如 final void handle() 内部调用 validate → execute → notify），防止子类破坏主干逻辑
复用通用逻辑，减少重复代码和维护风险
大型项目里，大量相似但非完全相同的业务流程反复出现。抽象类允许把稳定、共享的部分（日志、幂等校验、事务模板、监控埋点）写在父类，让子类专注差异化实现。
- JDK 中的 AbstractList 就是典型：indexOf、lastIndexOf、contains 等方法基于迭代器统一实现，ArrayList 和 LinkedList 只需提供自己的 iterator() 和 size()，大幅降低出错概率
- 在微服务网关中，abstract class AuthFilter 可封装 token 解析、白名单校验、上下文注入等通用步骤，各业务线继承后仅重写 isAuthorized() 即可，无需各自重复解析 JWT 或处理异常格式
支持模板方法模式，固化流程骨架
当某类业务存在固定步骤但部分环节因场景而异时，抽象类是实现模板方法模式的自然载体。它把算法流程“定死”，把变化点“留空”。
立即学习“Java免费学习笔记（深入）”；
- 支付系统中 abstract class PaymentService 定义 final void pay(Trade trade)：先锁库存 → 调三方 → 更新状态 → 发消息；其中 abstract Result callThirdParty(Trade trade) 由 AlipayPayment、WechatPayment 等子类分别实现
- 这种设计让新增支付渠道只需新增一个子类，不侵入主流程，也无需修改已有代码，符合开闭原则
承载领域状态与可变配置
接口无法持有状态，而抽象类可以定义 protected 字段、构造器参数、延迟初始化的缓存等，为子类提供可复用的上下文。
- 报表生成模块中，abstract class ReportGenerator 可包含 protected final DataSource dataSource、protected Map<String, Object> config，子类直接使用，无需每个实现都重新加载连接或解析配置
- 结合 Spring 的 @Autowired，抽象类还能注入通用 service（如 protected final AuditLogService auditLog），进一步提升横切关注点的复用效率
