目錄
定義如下：
個人理解：
通用類圖：
角色介紹：
● state——抽象狀態角色
● concretestate——具體狀態角色
● context——環境角色
通用源**：
場景類：
狀態模式的優點：
狀態模式的缺點：
使用場景：
狀態模式又是乙個比較難的設計模式
當乙個物件內在狀態改變時允許其改變行為，這個物件看起來像改變了其類。
通俗的講，狀態模式就是狀態的改變引起了行為的改變，但是，我們只能看到行為的改變，看不到狀態的改變。介面或抽象類，負責物件狀態定義，並且封裝環境角色以實現狀態切換。
每乙個具體狀態必須完成兩個職責：本狀態的行為管理以及趨向狀態處理，通俗地說，就是本狀態下要做的事情，以及本狀態如何過渡到其他狀態。
定義客戶端需要的介面，並且負責具體狀態的切換。
舉個例子：
狀態模式提供了一種對物質運動的另乙個觀察視角，通過狀態變更促使行為的變化，就類似水的狀態變更一樣，一碗水的初始狀態是液態，通過加熱轉變為氣態，狀態的改變同時也引起體積的擴大，然後就產生了乙個新的行為：鳴笛或頂起壺蓋。
抽象狀態中宣告乙個環境角色，提供各個狀態類自行訪問，並且提供所有狀態的抽象行為，由各個實現類實現。//抽象狀態角色public abstract class state
//行為1
public abstract void handle1();
//行為2
public abstract void handle2();
}
具體狀態角色有兩個職責：處理本狀態必須完成的任務，決定是否可以過渡到其他狀態。//具體狀態角色public class concretestate1 extends state
@override
public void handle2()
}public class concretestate2 extends state
@override
public void handle2()
}
環境角色有兩個不成文的約束：//環境角色public class context
//設定當前狀態
public void setcurrentstate(state currentstate)
//行為委託
public void handle1()
public void handle2()}
如上所示：我們只看到了行為發生改變。public class client}
● 結構清晰
避免了過多的switch...case或者if...else語句的使用，避免了程式的複雜性,提高系統的可維護性。
● 遵循設計原則
很好地體現了開閉原則和單一職責原則，每個狀態都是乙個子類，你要增加狀態就要增加子類，你要修改狀態，你只修改乙個子類就可以了。
● 封裝性非常好
這也是狀態模式的基本要求，狀態變換放置到類的內部來實現，外部的呼叫不用知道類內部如何實現狀態和行為的變換。
每乙個狀態都是乙個子類，容易產生子類膨脹的問題。
● 行為隨狀態改變而改變的場景
這也是狀態模式的根本出發點，例如許可權設計，人員的狀態不同即使執行相同的行為結果也會不同，在這種情況下需要考慮使用狀態模式。
● 條件、分支判斷語句的替代者
在程式中大量使用switch語句或者if判斷語句會導致程式結構不清晰，邏輯混亂，使用狀態模式可以很好地避免這一問題，它通過擴充套件子類實現了條件的判斷處理。
設計模式 狀態模式 Java
狀態模式 state 當乙個物件的內在狀態改變時允許改變其行為。這個物件看上去就像是改變了它的類一樣。狀態模式主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類當中，可以把複雜的判斷邏輯簡化。狀態模式的好處 將與特定狀態相關的行為區域性化，並...
Java設計模式 狀態模式
當乙個物件的內在狀態改變時允許改變其行為，對這個物件看起來像是改變了其類。狀態模式的uml圖如下 context 環境類，定義客戶感興趣的解耦，維護乙個states子類的例項，這個實力定義了物件當前的狀態。state 抽象狀態類或者狀態介面，定義乙個或一組介面，表示改狀態下的行為。concrete ...
Java設計模式 狀態模式
核心思想就是 當物件的狀態改變時，同時改變其行為。也就是行為由其狀態決定。介紹 意圖 允許物件在內部狀態發生改變時改變它的行為，物件看起來好像修改了它的類。何時使用 中包含大量與物件狀態有關的條件語句。如何解決 將各種具體的狀態類抽象出來。關鍵 通常命令模式的介面中只有乙個方法。而狀態模式的介面中有...