C++实现简单的状态模式切换 _ 接口类与具体状态实现【源码】

C++状态模式实战：避开那些教科书里不提的坑

一提到状态模式，很多人的第一反应就是继承和虚函数。但真正用起来才会发现，比设计模式本身更棘手的，往往是那些隐藏在实现细节里的“坑”。从内存管理到资源生命周期，一步走错，轻则逻辑混乱，重则直接崩溃。接下来，我们就聊聊如何把状态模式写得更健壮、更清晰。

状态模式的核心不是继承，而是委托

从教科书里学来的标准开局，通常是定义一个class State基类，然后让具体状态去继承，最后在上下文（Context）里保存一个State*指针。这个起点看似顺理成章，却埋下了隐患：状态切换时，如果忘记更新指针，或者新状态构造失败导致指针悬空，segfault几乎就是必然结局。

问题的核心在于所有权的模糊。更稳妥的思路，是让Context牢牢掌握状态对象的所有权，切换时通过值语义或智能指针完成“交接仪式”，彻底杜绝裸指针带来的生命周期失控。

• 首选std::unique_ptr。构造新状态后，直接用std::move赋值，旧状态会自动析构，内存管理变得清晰无比。
• 虚析构函数是必须的。所有状态类的基类都必须定义虚析构函数，否则通过基类指针delete派生类对象时，派生类的析构逻辑会被跳过，资源泄漏随之而来。
• 警惕循环依赖。切忌在状态内部调用Context的非const成员函数来“主动切换自己”。这会造成状态和上下文之间的双向依赖，让逻辑纠缠不清。状态切换的决策权，应交由Context统一掌控。

接口类 State 必须只暴露行为契约，不暴露数据

State接口类的职责应该非常纯粹：只定义行为契约，比如handleInput()、update()、render()，而绝不掺杂任何成员变量。

有些实现为了图方便，会在基类里放一个m_context指针，让状态能直接调用上下文的方法。这看似捷径，实则破坏了状态模式最关键的单向依赖原则（理想情况下应是Context依赖State，而非反之）。它不仅让Context变成了状态的依赖项，还极易引发头文件循环包含的编译难题。

正确的做法是：当Context调用state->handleInput(*this)时，将自身的引用作为参数传递进去。这样，依赖关系清晰，数据流向也一目了然。

• 用引用代替指针。接口函数参数优先使用Context&，而非Context*。这样可以避免在状态逻辑里充斥不必要的空指针检查。
• 控制数据访问。如果某个状态确实需要读取Context的私有数据，可以考虑提供一个const Context& getConstContext() const这样的只读接口，或者使用友元，而不是将Context的全部内部接口暴露出去。
• 注意构造顺序。别在State的构造函数里尝试访问Context的成员——状态对象的创建时机可能早于Context的完全初始化，这是一个常见的陷阱。

具体状态实现要隔离副作用，尤其资源管理

状态切换往往伴随着副作用的产生与清理，这才是真正体现设计功底的地方。例如，PlayingState进入时需要播放音频，退出时需要暂停；PausedState进入时要记录时间戳，退出时要计算暂停时长。

把这些逻辑统统塞进handleInput()里，会让代码变得臃肿且难以维护。更好的策略是将它们拆解到onEnter()和onExit()这两个专用的钩子函数中。Context在切换状态时，应遵循一个明确的流程：先调用旧状态的onExit()进行清理，然后构造新状态，最后调用新状态的onEnter()进行初始化。

• 钩子是私有契约。onEnter()和onExit()通常不作为公共虚函数接口的一部分，而是每个具体状态内部实现的私有方法，仅由Context在特定时机调用。
• 资源释放要及时。对于音频句柄、网络连接、图形上下文等资源，必须在onExit()中立即释放，而不能等到状态对象析构。因为同一个状态对象可能会被多次切换进出，析构只发生一次，延迟释放会导致资源占用。
• 避免阻塞操作。尽量不要在onEnter()中执行磁盘读取、网络请求等耗时操作，以免阻塞主线程。可以考虑改为异步触发，再由状态机来响应完成事件。

用 std::variant 替代虚函数基类？谨慎

随着C++17引入std::variant

理论上，你可以定义std::variant。然而，一旦项目开始演进，问题就接踵而至：每增加一种新状态，都要修改variant的类型列表，并重写所有相关的std::visit分支。更麻烦的是，这种模式无法支持动态扩展（比如运行时加载插件状态）。