Day07 - Flowchart versus State Diagram 让我们比一比

我们根据昨天的需求画出以下两张图

1. Flowchart

我们先看看 Flowchart
图中的白色 ◇ 代表逻辑判断，蓝色 ▢ 代表程序码实作的内容、『执行』的区块，我们叫角色去跳跃，按下 B ，判断是否已经在跳跃（底层实作），如果不是跳耀中，『执行』跳跃。

我们说跳跃是一个被执行的命令，在执行这命令前，程序可能处在某种状态；执行完成後，可能产生新的状态、或是状态维持不变（假如已经是跳跃中了，再次按下 B 去执行跳跃，程序码的状态不会改变）

画图时，图中比较在意底层的实作要怎麽执行、要做什麽逻辑判断，思考方式比较偏向由下而上，从程序码运行，建构出最终符合规格的程序。

我们先看看 State Diagram

整张图的『主体』是「游戏的角色」
我们可以将每一个「蓝色 ▢ 」视为一种『状态(State)』；
每一条「红色 → 」视为一种『转移的方向、地图(Mapping)』；
以及「跳跃」、「降落」、「起身」、「卧倒」等不同的『动作、事件（event)』
「站姿静止」可做为我们的『初始状态』。
我们也可以将「站姿静止」视为一个『结束的状态』，有限也包含 0 ，所以我们也可以假设我们这个模组没有『终止状态』。
注：（这边因为要让大家发现，可能有点漏思考到的感觉，所以前面的规格没有描述的很详细）

1.『主体』
2.『状态(State)』
3.『转移』
4.『事件』
5.『初始状态』
6.『结束状态』

上面的 State Diagram 符合我们 Day 5 对 Finite State Machine 的定义

by The Finite State of Reactive Animations

我们在画 State Diagram 时，是从主体出发，思考该主体可能存在、或者需要存在哪些具体的状态，什麽事件可能导致状态转移，思考方式是从上而下的。

画图时，图中的每个节点是主体存在的状态，每条线代表转移，什麽事件导致转移，也被我们明确（explicitly）写出来，却不用涉及底下实作、命令，出发点比较贴近真实世界、使用者观点的描述。

图中，Flowchart 的 do X, 逻辑判断 + do Y or do Z ，就好比是 State Diagram 的事件 E1,E2 ，所以我们上面说 事件明确（explicitly）写出来 而 逻辑判断 + do Y or do Z 就比较贴近程序命令执行。

而在 Flowchart 之间，被隐藏起来的状态，也在 State Diagram 被明确（explicitly）写出来，犹如之前所说：

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

假如开发情境是，你很在意你系统处在什麽状态？什麽状态时，要做什麽？
推荐服用，因为使用 Finite State Machine 时，你的程序码状态比较具描述性、比较贴近真实需求或物件实际的「状态」，也明确说出状态转换的事件是什麽，同时也比较能避免在进行复杂逻辑判断时，有遗漏或违反开放封闭原则。

那关於菱形的逻辑判断，可以说是状态的一种吗？这就比较像是 Day 02 提及的，他比较偏向是小状态、中介状态，导致我们实际在意的某个状态转移到另外一个状态。

接下来，一直在 Talk 实在太 Cheap 了，明天要来跟大家一起实作一下，自己用程序码做出一个状态机ＸＤ