前言
开发中我们最头疼的就是造轮子，那么怎么避免造轮子成本，实现高效开发降低运维成本呢？
在面向对象设计中已经给了我们答案–状态机模式，这里给出一个架构演示介绍下其中的思想。
状态机的核心是
状态（state ）：当前处于哪种状态？
事件（event ）：状态转换的触发事件是什么？
动作（action）：触发之后需要做什么动作？
使用场景
- 周期性读取外设数据
- 执行过程中，外设有掉线、异常、关掉、重启等功能需求
- 甚至有可能为了特殊任务需要将设备占用的资源释放
- 这种需求的外设很多，想降开发成本
设计思想
- 结构划分，设备必要的几个功能就是任务状态，使用状态机思想可以将所有设备任务进行管理
- 每个状态独立设计
- 设备从一种状态切换成另一个工作状态时，往往需要执行多个步骤，而具体执行细节不需要命令方操心
- 供外界控制有专用接口
- 同时为提高兼容适配，设计中不能涉及硬件平台相关
- 往往一个设备上不止一个设备需要如此管理，当所有设备都需要相同功能逻辑时，就需要一个框架来低成本管理它
功能规划
- 设备第一次上电需要的初始化任务，执行硬件初始化与软件控制初始化操作
- 设备运行异常等原因，需要重新初始化，甚至是需要重新上电使用执行的反初始化操作
- 设备完成预期的初始化进程，进入一个默认状态，此状态接受有限的控制命令，解析成功后，执行响应动作完成
- 有新的事件到来并不代表设备能立刻执行，需要一定的响应时间，如有必要此处采取消费者模型管理到来的事件，下发命令不应该阻塞，除非需要给予回应
- 任务周期性消费事件(event)或执行特定的周期动作，在执行重要动作时可能时阻塞的
object接口
- 对象初始化(隐藏在默认状态里)
- 新增状态与动作接口
- 事件收发接口
- 状态读取接口
- 数据访问接口
frame接口
- 框架初始化
- 框架刷新接口
- 事件收发接口
- 设备管理接口
设计
状态设计
typedef struct __STATE_OBJECT
{
}state_t,*state_ptr;设备对象设计(device_object)
typedef struct __DEVICE_OBJECT
{
}device_objecet_t,device_objecet_ptr;状态机框架设计(finite_state_machine)
typedef struct __finite_state_OBJECT
{
}device_objecet_t;本文编写中。。。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
