26.3 狀態模式的應用 26.3.1 狀態模式的優點 ● 結構清晰 避免了過多的switch...case或者if...else語句的使用，避免了程序的復雜性,提高系統的可維護性。 ● 遵循設計原則 很好地體現了開閉原則和單一職責原則，每個狀態都是一個子類，你要增加狀態就要增加子類，你要修改狀態，你只修改一個子類就可以了。 ● 封裝性非常好 這也是狀態模式的基本要求，狀態變換放置到類的內部來實現，外部的調用不用知道類內部如何實現狀態和行為的變換。 26.3.2 狀態模式的缺點 狀態模式既然有優點，那當然有缺點了。但只有一個缺點，子類會太多，也就是類膨脹。如果一個事物有很多個狀態也不稀奇，如果完全使用狀態模式就會有太多的子類，不好管理，這個需要大家在項目中自己衡量。其實有很多方式可以解決這個狀態問題，如在數據庫中建立一個狀態表，然后根據狀態執行相應的操作，這個也不復雜，看大家的習慣和嗜好了。 26.3.3 狀態模式的使用場景 ● 行為隨狀態改變而改變的場景 這也是狀態模式的根本出發點，例如權限設計，人員的狀態不同即使執行相同的行為結果也會不同，在這種情況下需要考慮使用狀態模式。 ● 條件、分支判斷語句的替代者 在程序中大量使用switch語句或者if判斷語句會導致程序結構不清晰，邏輯混亂，使用狀態模式可以很好地避免這一問題，它通過擴展子類實現了條件的判斷處理。 26.3.4 狀態模式的注意事項 狀態模式適用于當某個對象在它的狀態發生改變時，它的行為也隨著發生比較大的變化，也就是說在行為受狀態約束的情況下可以使用狀態模式，而且使用時對象的狀態最好不要超過5個。 26.4 最佳實踐 上面的例子可能比較復雜，請各位看官耐心看，看完肯定有所收獲。我翻遍了所有能找得到的資料（關于這個電梯的例子也是由《Design Pattern for Dummies》這本書激發出來的），基本上沒有一本把這個狀態模式講透徹的（當然，還是有幾本講得不錯），我不敢說我就講得透徹，大家都只講了一個狀態到另一個狀態的過渡。狀態間的過渡是固定的，舉個簡單的例子，如圖26-6所示。  圖26-6 簡單狀態切換示意圖 這個狀態圖是很多書上都有的，狀態A只能切換到狀態B，狀態B再切換到狀態C。舉例最多的就是TCP監聽的例子。TCP有3個狀態：等待狀態、連接狀態、斷開狀態，然后這3個狀態按照順序循環切換。按照這個狀態變更來講解狀態模式，我認為是不太合適的，為什么呢？你在項目中很少看到一個狀態只能過渡到另一個狀態情形，項目中遇到的大多數情況都是一個狀態可以轉換為幾種狀態，如圖26-7所示。  圖26-7 復雜狀態切換示意圖 狀態B既可以切換到狀態C，又可以切換到狀態D，而狀態D也可以切換到狀態A或狀態B，這在項目分析過程中有一個狀態圖可以完整地展示這種蜘蛛網結構，例如，一些收費網站的用戶就有很多狀態，如普通用戶、普通會員、VIP會員、白金級用戶等，這個狀態的變更你不允許跳躍？！這不可能，所以我在例子中就舉了一個比較復雜的應用，基本上可以實現狀態間自由切換，這才是最經常用到的狀態模式。 再提一個問題，狀態間的自由切換，那會有很多種呀，你要挨個去牢記一遍嗎？比如上面那個電梯的例子，我要一個正常的電梯運行邏輯，規則是開門->關門->運行->停止；還要一個緊急狀態（如火災）下的運行邏輯，關門->停止，緊急狀態時，電梯當然不能用了；再要一個維修狀態下的運行邏輯，這個狀態任何情況都可以，開著門電梯運行？可以！門來回開關？可以！永久停止不動？可以！那這怎么實現呢？需要我們把已經有的幾種狀態按照一定的順序再重新組裝一下，那這個是什么模式？什么模式？大聲點！建造者模式！對，建造模式+狀態模式會起到非常好的封裝作用。 更進一步，應該有部分讀者做過工作流開發，如果不是土制框架，那么就應該有個狀態機管理（即使是土制框架也應該有），如一個Activity（節點）有初始化狀態（Initialized State）、掛起狀態（Suspended State）、完成狀態（Completed State）等，流程實例也有這么多狀態，那這些狀態怎么管理呢？通過狀態機（State Machine）來管理，那狀態機是個什么東西呢？就是我們上面提到的Context類的升級變態BOSS！