抽象类不实现状态模式，而是作为状态接口基类或上下文基类参与生命周期管理：定义公共方法（如enter/exit/handleEvent）、封装状态切换逻辑、配合枚举或工厂管理状态实例，并明确职责边界——状态类聚焦当前行为，上下文决定何时切换。
抽象类本身不“实现”状态模式，而是作为状态模式中状态角色的基类或上下文的一部分来参与生命周期管理。状态模式的核心是把对象在不同生命周期阶段的行为封装成独立的状态类，而抽象类常用来定义这些状态的公共接口或提供默认行为。
用抽象类定义状态接口
定义一个抽象类（或接口，但抽象类更利于复用默认逻辑），声明所有状态共有的方法，比如 enter()、exit()、handleEvent() 等，让具体状态子类选择性重写：
- 抽象类可提供空实现或基础日志、状态校验等通用逻辑
- 避免每个具体状态都重复写相同模板代码
- 例如：
AbstractState中默认enter()打印进入日志，子类只需覆盖关键业务逻辑
抽象类作为上下文的基类
生命周期管理者（即上下文）也可设计为抽象类，封装状态切换机制、当前状态引用、状态变更通知等公共能力：
- 定义
setState(State newState)方法，自动调用旧状态的exit()和新状态的enter() - 提供
getCurrentState()和受保护的state字段供子类安全访问 - 子类（如
OrderContext或MediaPlayer）继承后专注业务规则，无需重复处理状态流转细节
配合枚举或工厂管理状态实例
具体状态通常设计为单例（因无状态或只读），可用枚举或静态工厂统一管理，避免每次 new：
立即学习“Java免费学习笔记（深入）”；
- 枚举天然支持单例且类型安全，适合状态种类固定、不需运行时扩展的场景
- 若需动态创建或注入依赖，可用工厂方法返回具体状态实例，抽象类中定义工厂钩子（如
createState(String type)） - 确保状态切换时传入的是同一套状态体系中的实例，避免跨上下文误用
注意生命周期与状态职责边界
抽象类不能替代状态模式的设计意图——它只是支撑结构。真正决定生命周期行为的是状态类的组合与切换逻辑：
- 不要在抽象类里硬编码状态转换规则（如 “收到 eventA 就跳转到 StateB”），那属于上下文或状态自身的职责
- 状态类应聚焦“当前做什么”，上下文聚焦“什么时候换状态”，抽象类负责让这两者解耦且易扩展
- 生命周期结束（如销毁）可由上下文在
destroy()中触发最终状态的exit()，并清空引用
