如果在程序員.stackexchange上提問，請移動它或通知我。當需要按照明確的順序執行某些步驟時，狀態機是否是適當的設計？
想象一個程序，其唯一目的是用傳感器測量溫度。有兩個輸入，傳感器和用戶（用戶可以按下放棄按鈕）。
程序啓動時，必須滿足某些條件。假設傳感器的溫度不得高於x。如果條件滿足，則程序進入下一步，否則將通知用戶確保滿足條件。
一旦滿足，用戶將看到接下來要做的事情，比如「現在將傳感器粘貼到要測量的對象中」。 程序現在測量。假設這個過程需要的不僅僅是傳感器的快照，還需要一些相當複雜的過濾等。一旦滿足了某些標準，用戶就被告知下一步該做什麼。
在某些時候，用戶正在被呈現結果。 用戶可以決定在任何時候中止整個事情（回去開始或關閉）。
爲什麼我在這方面掙扎呢，如果在某個時候引入了另一個步驟，或者刪除了某個步驟，但它們將始終遵循相同的工作流程。我在新程序的開始，我想創建一個可維護的系統。
林不知道如果一個狀態機是一個很好的解決方案，或者如果我完全誤解了一個狀態機是什麼或者有一個更簡單的解決方案。
在鬆散的定義下，您編寫的任何程序都會歸類爲狀態機。當程序從一行代碼移動到另一行時，程序會改變狀態，並且變量會更改值。
當我們談論使用狀態機作爲設計模式時，通常需要將主狀態轉換分離爲單獨的模塊（類），其中每個對象的字段存儲感興趣的狀態信息以及其主要執行方法處理當前狀態的主要任務，然後返回有關應該移入的下一個狀態的信息。主控制循環調用每個狀態的主執行方法，直到返回一個定義的結束狀態。
此模式的優點是可以密切地反映您可能在Visio或某些類型中創建的可視化工作流程的結構。當程序的每個主要狀態具有完全不同的責任時，這可以幫助您按照單一責任原則自然分組您的代碼。當每個狀態只能進入一個或兩個其他狀態時，最終會得到相對鬆散的代碼，這也有助於使事情更易於維護。
你描述的程序似乎是這種模式的一個很好的候選人。
是的，任何順序過程都可以建模爲狀態機。每個順序進程不作爲狀態機實現的原因是，通常（幾乎總是），您可以使用其他技術構建「更小」的機器（更少的概念觸發器/變量和NAND門/ if語句）和「更小」通常意味着「更容易理解」。但是，由於狀態機是如此普遍，只有少量明確的規則，所以對於具有不規則結構的系統來說，它有時是最好的（「最小」並且最容易理解的）實際實現，尤其是如果該結構知之甚少和/或需要頻繁修改。另外，在硬件中至少存在一些情況，其中諸如「可編程邏輯陣列」（PLA）的設備相當乾淨地實施狀態機 - 比定製設計的集成電路更乾淨（且更便宜） 。