1. 程式人生 > >23種設計模式之狀態模式

23種設計模式之狀態模式

狀態模式的定義

定義: 當一個物件內在狀態改變時允許其改變行為, 這個物件看起來像改變了其類

通俗的說, 就是一個事物有不同的狀態,在不同狀態下執行各個方法時有不同的表現, 將每個狀態都封裝成一個類, 然後通過上下文物件統一管理

其類圖如下:

23種設計模式之狀態模式

 

其中的三個角色如下:

  1. State 抽象狀態角色: 介面或抽象類, 負責物件狀態定義, 並且封裝環境角色以實現狀態切換
  2. ConcreteState 具體狀態角色: 每一個具體狀態必須完成兩個職責: 本狀態的行為管理以及趨向狀態處理, 通俗的說, 就是本狀態下要做的事情, 以及本狀態如何過渡到其他狀態
  3. Context 環境角色: 定義客戶端需要的介面, 並且負責具體狀態的切換

抽象狀態角色程式碼:

23種設計模式之狀態模式

 

抽象狀態中宣告一個環境角色, 提供各個狀態類自行訪問, 並且提供所有狀態的抽象行為, 由各個實現類實現

具體狀態角色程式碼:

23種設計模式之狀態模式

 

具體狀態角色有兩個職責: 處理本狀態要完成的任務, 決定是否可以過度到其他狀態.

環境角色程式碼:

23種設計模式之狀態模式

 

環境角色有兩個不成文的約束:

  1. 把狀態物件生命為靜態常量, 有幾個狀態物件就宣告ji'ge幾個靜態常量
  2. 環境角色具有狀態抽象角色定義的所有行為, 具體執行使用委託方式

場景類程式碼:

23種設計模式之狀態模式

 

這樣就實現了在不同狀態下的切換

狀態模式的應用

狀態模式的優點:

  1. 結構清晰. 避免了過多的 switch...case 或者 if...else 語句的使用, 避免了程式的複雜性, 提高系統的可維護性
  2. 遵循設計原則. 很好的體現了開閉原則和單一職責原則, 眉哥哥狀態都是一個子類, 你要增加狀態就要增加子類, 要修改狀態, 只修改一個子類即可
  3. 封裝性非常好. 這也是狀態模式的基本要求, 狀態變換放置到類的內部來實現, 外部的呼叫不用知道類內部如何實現狀態和行為的變換

狀態模式的缺點:

狀態模式只有一個 缺點, 子類會太多, 也就是類膨脹. 一個事物有很多個狀態也不稀奇, 如果完全使用狀態模式就會有太多的子類, 不好管理. 其實有很多方式可以解決這個狀態問題, 如在資料庫中建立一個狀態表, 然後根據狀態執行相應的操作.

狀態模式的使用場景:

  1. 行為隨狀態改變 而改變的場景.
  2. 條件、分支判斷語句的替代者. 在程式中大量使用 seitch 語句或者if 判斷語句會導致程式結構不清晰, 邏輯混亂, 使用狀態模式可以很好的避免這一問題, 它通過擴充套件子類實現了條件的判斷處理

狀態模式適用於當某個物件在它的狀態發生改變時, 他的行為也隨著發生比較大的變化, 也就是說在行為受狀態約束的情況下可以使用狀態模式, 而且使用時物件的狀態最好不要超過5個


 

 

可以關注一下鄙人的公眾號, 謝謝各位了!