如何用狀態機簡化代碼中復雜的 If Else 邏輯

作者：神說要有光zxg 2021-06-05 05:11:52

不知道你有沒有遇到代碼邏輯特別復雜的情況，需要很多的 if else 來判斷，每種情況有自己的邏輯。這樣的 if else 特別多以后，閱讀代碼和繼續迭代都變得很困難。如果你遇到這種代碼，會怎么優化呢?

本文轉載自微信公眾號「神光的編程秘籍」，作者神說要有光zxg。轉載本文請聯系神光的編程秘籍公眾號。

本文就提供一種思路，通過狀態機來簡化復雜的 if else 代碼邏輯。

讀完本文，你會了解到：

當處理的情況特別多，我們把每種情況的處理邏輯封裝成一個狀態，然后不同情況之間的轉換變成狀態的轉換。這種代碼組織形式就是狀態機。

當每個狀態知道輸入某一段內容時轉到哪一個狀態，在一個循環內自動進行狀態的流轉和不同狀態的處理，這種叫做狀態自動機(automation)，如果一個狀態在一種輸入下只有一個后續狀態，這種就叫做確定性有限狀態自動機(DFA)。

狀態之間的流轉可以通過狀態轉換圖來表示。

typescript compiler 就是通過狀態機來組織整個編譯流程的：

首先 tsc 劃分了很多狀態，每種狀態處理一種邏輯。比如：

typescript 就通過這種狀態的修改來完成不同處理邏輯的流轉，如果處理到結束狀態就代表流程結束。

這樣使得整體流程可以很輕易的擴展和修改，比如想擴展一個階段，只要增加一個狀態，想修改某種狀態的處理邏輯，只需要修改下狀態機的該狀態的轉向。而不是大量的 if else 混雜在一起，難以擴展和修改。

可以看到，狀態機使得 typescript 的編譯步驟可以靈活的擴展和修改。

其實狀態機最常用的地方是用于詞法分析，因為每個 token 都是一種處理情況，自然會有很多 if else。

像下面這樣用 if else 來做分詞自然也可以，這是 wenyan 的詞法分析邏輯，但是代碼很難維護。

更好的做法是使用狀態機(DFA)來做分詞，把每一種 token 的處理封裝成一個狀態。通過邊界條件的判斷來做狀態流轉，比如某個 wxml parser 分了這些狀態：

每種狀態處理一種情況的 token 的識別：

通過狀態的變化驅動處理邏輯的流轉：

這樣不斷的進行各狀態之間的流轉，當處理到字符串的末尾的時候，就完成了所有的分詞。

業務代碼中當遇到各種 if else 的判斷的時候同樣可以用狀態機來優化。把每種情況封裝成一個狀態，通過某一種條件觸發狀態的流轉，然后在狀態機里面選擇不同的狀態處理邏輯進行處理。

不管是游戲中不同狀態做不同的處理邏輯，還是在 ui 項目中不同狀態做不同的渲染，當代碼邏輯復雜時，難免會有很多 if else，這時候都可以用狀態機的思路來做優化。

這樣，當后續擴展處理邏輯、修改不同條件下的處理邏輯都變得簡單和清晰很多。

我們首先明確了狀態機的概念：通過不同狀態封裝不同情況的處理邏輯，通過狀態的修改來完成處理邏輯之間的流轉。

如果每種狀態都知道下一個狀態是什么，在一個循環內自動完成狀態流轉的狀態機，就是狀態自動機，當狀態為有限個時，就是有限狀態自動機(DFA)。

typescript compiler 就是通過狀態自動機來進行處理，封裝了很多個狀態，每個狀態知道下一個狀態是什么，直到處理到終止狀態，就結束編譯。

詞法分析中一般會使用有限狀態自動機(DFA)來處理，不同 token 用不同的狀態來處理，通過輸入字符的不同來做狀態的流轉，處理完字符串就完成了分詞。

業務代碼中也經常會有不同情況做不同的處理，這些情況在一定的條件時會做轉換的場景，比如類似開始、暫停、結束、重新開始這種。這種代碼就很適合用狀態機來優化，不然會有很多的 if else。

總之，當邏輯可以劃分為不同的情況，各種情況之間會相互轉換的時候就可以用狀態機來優化，能夠免去大量的 if else，并且代碼的可讀性、可擴展性、可維護性都會有一個很大的提升。

希望這篇文章能夠讓你知道狀態機是什么，什么時候可以用狀態機，狀態機可以帶來哪些提升，真正在代碼中用起來。

責任編輯：武曉燕來源：神光的編程秘籍