狀態模式的定義 定義: 當一個對象內在狀態改變時允許其改變行為, 這個對象看起來像改變了其類 通俗的說, 就是一個事物有不同的狀態,在不同狀態下執行各個方法時有不同的表現, 將每個狀態都封裝成一個類, 然後通過上下文對象統一管理 其類圖如下: 其中的三個角色如下: 抽象狀態角色代碼: 抽象狀態中聲明 ...
狀態模式的定義
定義: 當一個對象內在狀態改變時允許其改變行為, 這個對象看起來像改變了其類
通俗的說, 就是一個事物有不同的狀態,在不同狀態下執行各個方法時有不同的表現, 將每個狀態都封裝成一個類, 然後通過上下文對象統一管理
其類圖如下:
其中的三個角色如下:
- State 抽象狀態角色: 介面或抽象類, 負責對象狀態定義, 並且封裝環境角色以實現狀態切換
- ConcreteState 具體狀態角色: 每一個具體狀態必須完成兩個職責: 本狀態的行為管理以及趨向狀態處理, 通俗的說, 就是本狀態下要做的事情, 以及本狀態如何過渡到其他狀態
- Context 環境角色: 定義客戶端需要的介面, 並且負責具體狀態的切換
抽象狀態角色代碼:
抽象狀態中聲明一個環境角色, 提供各個狀態類自行訪問, 並且提供所有狀態的抽象行為, 由各個實現類實現
具體狀態角色代碼:
具體狀態角色有兩個職責: 處理本狀態要完成的任務, 決定是否可以過度到其他狀態.
環境角色代碼:
環境角色有兩個不成文的約束:
- 把狀態對象生命為靜態常量, 有幾個狀態對象就聲明ji'ge幾個靜態常量
- 環境角色具有狀態抽象角色定義的所有行為, 具體執行使用委托方式
場景類代碼:
這樣就實現了在不同狀態下的切換
狀態模式的應用
狀態模式的優點:
- 結構清晰. 避免了過多的 switch...case 或者 if...else 語句的使用, 避免了程式的複雜性, 提高系統的可維護性
- 遵循設計原則. 很好的體現了開閉原則和單一職責原則, 眉哥哥狀態都是一個子類, 你要增加狀態就要增加子類, 要修改狀態, 只修改一個子類即可
- 封裝性非常好. 這也是狀態模式的基本要求, 狀態變換放置到類的內部來實現, 外部的調用不用知道類內部如何實現狀態和行為的變換
狀態模式的缺點:
狀態模式只有一個 缺點, 子類會太多, 也就是類膨脹. 一個事物有很多個狀態也不稀奇, 如果完全使用狀態模式就會有太多的子類, 不好管理. 其實有很多方式可以解決這個狀態問題, 如在資料庫中建立一個狀態表, 然後根據狀態執行相應的操作.
狀態模式的使用場景:
- 行為隨狀態改變 而改變的場景.
- 條件、分支判斷語句的替代者. 在程式中大量使用 seitch 語句或者if 判斷語句會導致程式結構不清晰, 邏輯混亂, 使用狀態模式可以很好的避免這一問題, 它通過擴展子類實現了條件的判斷處理
狀態模式適用於當某個對象在它的狀態發生改變時, 他的行為也隨著發生比較大的變化, 也就是說在行為受狀態約束的情況下可以使用狀態模式, 而且使用時對象的狀態最好不要超過5個
