Day05 - 开始、结束与有限状态机

昨天习得事件、转移的概念後，让我们来思考实作这个 transition，还需要什麽东西？

transition('待付款', '收到帐款')  === '待发货'
transition('站立', '按 B') === '跳跃'

或者说我们这个主体、状态至转移的过程，还欠缺什麽东西？

订单：提交 → 待付款 → 待发货→ 待取件→ 交易完成
角色移动模组：站 → 跳 → 站

1. 开始

以 RPG 游戏的角色移动模组为例，玩家开始操纵角色前，一定要会有个初始状态，可能是来自上次离线的纪录（等级、hp,mp, sp, attack, speed..）或是初心者最开始的状态。

而以电商订单为例，订单最开始一定会有提交阶段吧，由消费者向厂商提出购买的意愿、询问是否有货源等等，当有了这个最开始的条件，我们才能确认、有办法继续往後面处理一系列的交易流程。

所以这个主体也必须要有一个初始值，我们称做初始状态 (Initial State)

以 RPG 游戏的角色移动模组为例，玩家开始操纵角色後，什麽代表着结束？可能是玩家决定登出、角色HP归零死亡，游戏破关等等...或者是玩家移动到一个安全的地方，然後把电脑继续开着挂机，不会结束。

而以电商订单为例，怎麽样可以视一张订单为结束？
可以是产品送达客户後的交易完成、或是客户决定取消下单、或供应商没货的交易取消、或是使用者忘记期限内付费的交易失效等等。

我们称这个主体被结束时，所处的状态称作结束状态 (Final State"s")

所以我们大致观察一直以来的这两个范例需求中的一些特徵

一个主体、物件底下所存在的状态们、事件，以及转换的这个旅程，我们称作一个有限状态机(Finite State Machine)。

至於为什麽状态机前多了前缀字「有限」

我想可以用这句话理解：因为要有 Transition 这张表的存在，必须记录 什麽事件 + 什麽状态 = 转换後的状态 ，因为要把它们列举出来，前述的状态与事件的数量就会是有限的。

原因便是我们在规划一个物件、系统流程时，底下有太多不同种的状态，还有各自的条件限制，为了满足系统与规格的需求，假如我们只单纯使用 if/else block 并设计几个 flag isSomething/isOtherthing 随着系统扩充、调整，可能会为我们带来麻烦。

假设我的功能新增也是继续增加 if/else 或是增加 flag isC/hasD 等等，我们会面临到，必须回去其他检查旧有的 if/else block ，思考新增的状态跟旧状态有没有什麽相依性、或是防御 (Guard) 要处理，违反了开放封闭原则 ，专案程序码也变得难以阅读。

虽然上述的写法很简单、很快速，我们的程序码也能非常自由的灵活运用，但代价就是过於自由，变得难以顾及整体。

限制你总体状态的有哪些、可以有哪些事件存在，什麽事件配什麽状态能进行状态转移 → 有限状态机 ( Finite State Machine )

所以如果当你的需求是一个复杂状态的情境时，在系统规划上，你便可以考虑使用有限状态机