最近看了些部門牛人的**，有網路框架也有具體的業務系統，其中頻繁使用了state的設計模式。在實現大規模複雜邏輯時，狀態設計模式確實是非常有效的手段。
在乙個複雜的邏輯中，乙個物件的行為往往是不連續的，這種不連續是指站在**執行的角度來看的：物件的乙個完整操作可能會被多個非同步操作所中斷，而高效能的後台伺服器是不可能阻塞在單個物件的某個操作上，這時候就需要儲存物件的臨時狀態，等待非同步操作結束後才重新繼續之前中斷的操作。
當物件的型別和操作都快速增加時，**的邏輯可能會變得非常複雜，並且難以維護。此時把物件的狀態介面進行抽象，將不同狀態和行為以類為單位進行封裝就可以很好的維護邏輯的清晰性，保證**的可維護性。
在乙個複雜的邏輯中，物件的狀態改變需要大量依賴外部的訊息或者環境資訊，而且狀態改變本身的實現是瑣碎或複雜的。
狀態模式的使用場景比較通用，只要涉及較為複雜的邏輯和事件驅動的情景下，都可以使用狀態模式。例如在乙個tcp連線中，包括這個open，listen，connected，closed等若干狀態，各個狀態之間的轉換多而複雜，是比較典型的適用狀態模式的場景。使用狀態模式可以封裝這個狀態的變化規則，從而對邏輯進行較好的抽象，不必涉及到狀態的使用者。同樣狀態設計模式在工作流或遊戲等各種系統中也有大量使用，甚至是這些系統的核心功能設計。
說了這麼多，都是從概念上的解釋，那麼下面看一些例子：
在驢哥實現的乙個系統中，需要實現對於不同事務的管理（這裡只列舉了add和del的操作），每乙個事務有較為複雜的業務邏輯（實際的實現要複雜很多，這裡只進行了簡單的抽象）。通過狀態模式，每次對於事務的操作只需要通過呼叫統一process操作即可，而乙個單獨的操作（比如add）中不同state之間的轉換則在具體的handlestat*系列函式中實現。因為系統存在不同的操作（add和del），所以對不同操作抽象出基類，這樣以後擴充新的操作也非常簡單，而且不影響現有架構。
下面是在另一種狀態模式的實現，這種模式嚴格按照了經典「四人幫」的《設計模式》書籍中對state模式的說明來實現的。不同點在於對於狀態的抽象更加徹底，實現各種狀態的繼承結構，而且狀態改變的邏輯也和狀態本身耦合在了一起。這一種實現是比較純粹的狀態機模式，上面的實現有點結合了命令模式的感覺。總之各有自身的優點吧。
設計模式的核心更多在於概念上的抽象，在於方**，具體的實現細節比較靈活。以上我最近的一些心得，歡迎感興趣的同學相互討論，共同進步。
State設計模式
最近做實驗時用到了state設計模式，雖然老師說state設計模式要到以後講，但通過自學我已經基本明白其要點，不妨在此寫一些東西。我們知道，軟體在執行過程中，會產生很多的狀態，狀態就是指軟體所處的某一種相對穩定的形式，在這裡我要解釋清楚它和軟體基線的區別。軟體的基線是指軟體本身所處的相對穩定的形式，...
設計模式之State模式
state模式類似於switch的多路分鐘功能 狀態模式的ulm圖 狀態模式用於改變目標物件的行為方式，隨著狀態變化目標程式從乙個轉到另乙個目標程式。package state public class creature private class forg implements state pri...
設計模式之state模式
狀態模式 state pattern 允許乙個物件在其內部狀態改變時改變它的行為。適用場景 一 乙個物件的行為取決於他的狀態，並且它必須在執行時根據狀態改變它 的行為 二 乙個操作中含有龐大的多分支條件語句，並且這些分支依賴於該物件的 狀態。優缺點 狀態模式的主要優點在於封裝了轉換規則，其缺點在於使...