嵌入式设计模式基础--C语言的继承封装与多态
嵌入式设计模式--C语言的简单工厂模式
嵌入式设计模式--C语言的抽象工厂模式
嵌入式设计模式--C语言的建造者模式
嵌入式设计模式--C语言的观察者模式
嵌入式设计模式--C语言的原型模式
嵌入式设计模式--C语言的桥接模式
嵌入式设计模式--C语言的中介者模式
嵌入式设计模式--C语言的装饰器模式
嵌入式设计模式--C语言的外观模式
嵌入式设计模式--C语言的解释器模式
嵌入式设计模式--C语言的享元模式
嵌入式设计模式--C语言的代理模式
嵌入式设计模式--C语言的模板方法模式
备忘录模式×C语言:嵌入式开发进阶
嵌入式设计模式--C语言的迭代器模式
本期我们要更新的是行为型设计模式--状态（机）模式。
什么是状态模式？
根据GoF《设计模式》原著，状态模式（State Pattern）的核心意图：
"Allow an object to alter its behavior when its internal state changes. The object will appear to change its class."
中文含义：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
为什么需要状态模式？
状态模式解决了传统状态机实现中代码难以维护、扩展困难的核心痛点，通过将状态封装为独立对象，实现行为与状态的绑定，让状态转移清晰化、系统可扩展化。
传统软件编码的困境
分支复杂
if-else与switch-case随状态数激增，函数冗长，圈复杂度过高。
职责混乱
上下文持有所有状态行为，修改易引入回归Bug。
扩展僵化
新增状态需改现有代码，违反开闭原则，迭代风险高。
状态模式的三重解耦
行为与状态绑定
状态对象自主实现行为，上下文通过多态分发调用，消除条件判断。
转移逻辑自治
状态内部决定"事件→下一状态"，避免集中式转移表臃肿。
上下文精简
仅维护current_state指针，行为全部委托，代码量降70%+。
上下文（Context）：
持有当前状态对象的引用，定义客户端使用的主要接口。所有与状态相关的行为请求都委托给当前状态对象处理，自身不直接实现状态逻辑，只负责状态切换时的对象替换。
抽象状态（State）：
定义状态接口，声明与上下文特定状态相关的行为方法。作为所有具体状态的公共规范，确保状态对象可以互相替换，使上下文能以统一方式调用不同状态的行为。
具体状态（ConcreteState）：
实现抽象状态接口，封装上下文在该状态下的具体行为规则和状态转移条件。每个具体状态类只关注自身状态下的操作逻辑，并决定何时以及切换到哪个下一个状态。
核心思想
状态模式将状态封装为独立的类，把与状态相关的行为分散到各个状态类中。当对象的状态改变时，其行为也随之改变，无需使用大量的条件判断语句（if-else 或 switch-case）
Context 通过 state 字段关联抽象 State，而非直接关联具体状态
具体状态 既实现 State 接口，又依赖 Context（通过参数传入），以便在条件满足时触发状态转移
状态转换可由 Context 控制（外部驱动），也可由 ConcreteState 自身控制（满足条件后主动申请切换），后者更常见
下面我们给到一个简单的电机控制的例子来展示状态模式。
核心体现
无 switch-case：
main 只调用 motor_request，行为完全由当前状态对象决定
自驱动转移：各状态类内部判断切换条件（如 startingState 检测到速达目标后主动申请切运行态）
新增状态易扩展：增加新状态只需新建结构体，不改动现有状态代码
运行日志：
=== 启动到1000转 ===
状态切换: 停止 -> 启动
启动中: 转速=100
启动中: 转速=200
启动中: 转速=1000
状态切换: 启动 -> 运行
=== 目标改为0转（停机）===
状态切换: 运行 -> 减速
减速中: 转速=900
减速中: 转速=0
状态切换: 减速 -> 停止
==== 停止 ====
状态模式
允许对象在内部状态改变时改变其行为，将状态封装为独立类，分散状态相关行为，避免冗长的条件分支。
核心角色包括：上下文维护当前状态并委托行为，抽象状态定义接口规范，具体状态实现特定行为并控制状态转移。其优势在于消除复杂条件判断、集中状态逻辑、显式化转换规则，支持通过新增状态类扩展系统。
在嵌入式开发中，该模式
广泛应用于协议解析、电源管理、电机控制等场景。通过函数指针模拟状态接口，既保留封装性与可扩展性，又避免动态内存开销
，是资源受限环境下实现清晰状态机的经典方案。
热门跟贴