你有沒有必要創造一個有限狀態機？

Question

這不包括你可能爲大學所做的有限狀態機。我想知道誰不得不創建一個，爲什麼？

創建機器最困難的方面是什麼？

Answer 1

是的，很多。基本上，我出於性能原因必須手動實施詞法分析器。其他個人用途已經在GUI設計中，FSA已經控制了與用戶的交互流程。

創建這樣的機器根本不難。 更改他們是因爲FSA的至少部分結構被嚴格嵌入代碼中。 state pattern有助於緩解其中的一些轉變 - 但不是全部。

Answer 2

如上所述，FSA的目的就在於，從一步一步到另一步，所有的處理（和狀態更改）都在一個循環中處理。而且，當流程發生變化時，進入下一個邏輯步驟很簡單。

是的，他們很容易做到，我經常使用它們超過25年。

Answer 3

很多次！

通信系統中使用的大多數協議棧都是作爲狀態機來實現的。 CSTA呼叫模式就是一個很好的例子。

此外，大多數嵌入式系統本質上是狀態機。

基本上，任何必須對現實世界中的事件做出反應的系統都是實現狀態機的好選擇。

關於狀態機最困難的事情是理解他們在沒有最新文檔的情況下所做的事情。他們傾向於將錯誤修復得無法識別。

Answer 4

當然，我設計並創建了一個渦輪調速器來控制小型渦輪機，泵和電機。它是一款帶DSP芯片的嵌入式設備。它具有諸如停止，啓動，運行，超速測試等狀態，然後在運行狀態中有幾個狀態來覆蓋其他控制可能性。

就我而言，關於狀態機管理最難的部分是設計一個乾淨的轉換，特別是當狀態可以有子狀態時。對於水輪機調速器來說，這意味着轉速輸出（執行器）必須在轉換之間平穩調整。其他挑戰與用戶界面（按鈕和7段LED顯示屏）以及它們如何與狀態機進行交互有關。因此最終成爲一個主控制狀態機，一個相關的用戶界面狀態機和一個相關的通信狀態機（在渦輪機運行時不允許寫入某些值）。

我在各種其他項目，一些嵌入式和一些標準軟件以及從用戶界面軟件的通信中使用了狀態機。

Answer 5

我也有。我通常創建小FSM（很少有狀態），因爲更大的FSM成爲維護噩夢，但有時FSM對於給定任務來說是非常簡單和優雅的設計。

作爲一個現實世界的例子，我創建了一個小工具來修復某種類型的文件一次。有僅3或4與用戶可能的相互作用的路徑：

• 表現出一點信息，選擇文件（可能取消並重新開始），
• 修復文件（可能取消，並用錯誤消息出口），
• 顯示確認消息。

創建狀態機使這些路徑顯而易見並且易於實現。