最近由于項目需要，開始研究狀態機。其實原來就做過狀態機相關的東西，畢竟在手機實時系統上狀態是個很常見也很重要的東西。但是狀態機的設計和實現的好壞直接影響整個系統的性能及可維護性。從設計上講，無非是畫狀態圖，理清各個狀態之間的遷移關系；從編碼上講，對于非層次式有限狀態自動機（FSM）一般有以下幾種實現方法：
1、最簡單的switch-case方法，設若干個變量保存當前狀態，針對每個狀態switch-case各種signal輸入進行判斷分別處理。說起來很容易理解，但是實際做起來卻遠不是這么簡單。這種實現將所有狀態的處理全部雜糅在一起，如果系統稍微復雜一些，那么維護起來將相當困難，我原來接觸過的一個項目其中的主服務層的內部就有10多個變量標示各種不同類別的狀態，十幾層switch-case和if/else錯綜復雜，經常是一大段處理找不到他的輸入signal在哪里，在什么情況下進行該處理。曾經安排我來維護這個，那個吐血...
2、狀態表。以輸入signal作索引，相應操作的函數指針和狀態遷移作表元素，建立一個狀態表。這樣做的好處首先是速度快，完全避免了判斷分支；所有狀態遷移時的處理以獨立函數的形式分離，在邏輯上比較清晰。但是該方法的缺點是即使可能某些狀態并不接受某些signal輸入，還是需要針對所有的signal輸入和所有的狀態列出所有可能的處理情況。并且由于c中沒有現成的hash表，所以構造出的狀態表通常是稀疏的，空間浪費比較大。另外由于將所有情況線性列舉，如果對原狀態圖進行修改，在維護上也相對困難（需要在一個大的方陣中找出修改所影響的行列）。
3、狀態模式。這個是基于面向對象的解決方法，基類中定義所有事件的處理接口，對于新狀態通過派生基類的子類來擴展，在子類中重寫該狀態所涉及到的事件處理方法。這種方法可以很方便的擴展新狀態，將不同狀態處理獨立開來，邏輯清晰。但是由于需要最大化基類接口數量，似乎不是很符合OO的設計原則，而且也需要枚舉所有的signal輸入，設計粒度太細。
4、不太好歸納該方法的名字，姑且叫綜合方法吧。該方法綜合了以上幾種方法的優點，也是我比較欣賞的一種方法。該方法將著眼點從transition轉移到state本身上來，以每個state作為粒度單位來設計。
定義一個狀態管理變量currentState，保存當前狀態處理的函數指針，同時定義init,destroy,trans等接口。對于新狀態，只需新建一個狀態處理函數，遵循接口
ret_value State1Handle( Signal )
{
signal2:
action2;
trans(State2Handle);
signal3:
action3;
trans(State3Handle);
....
}
trans中僅需要更改currentState的函數指針取值即可。
對于狀態內的signal分發可以采用狀態表（signal需可枚舉）或簡單的switch-case形式。
該方法避免了簡單switch-case和狀態表的處理堆疊的情況，狀態轉換非常高效（重新賦值狀態處理指針），可以很方便的添加/刪除/修改狀態及處理（添加刪除相應的狀態處理函數及相關狀態的處理即可），并且避免了signal處理接口的最大化，每個狀態只處理所關心的signal輸入。可以說這種方法最大限度的發揮了函數指針的靈活性。
以上所說的幾種方法都針對非層次式狀態機，也就是說對于某些共同的處理不能在宏觀上加以綜合，而只能在最小粒度上設計每個狀態。而層次式狀態機則允許有復合狀態的出現，對于共通處理可以在父狀態上進行而不必遷移到每一個子狀態上。當子狀態接收到一個共同處理時，可以將該處理throw給父狀態，如果還不能處理就再次向上層throw。這種處理方法抽象程度更高，設計更加簡潔。有一種量子模型是很好的層次式狀態機的實現方式，不過由于此次項目尚未涉及層次式狀態機，所以僅作了解。
越來越深的體會到了函數指針的強大了...