定義
當乙個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類。
狀態模式主要解決的是當控制乙個物件狀態的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類中，可以把複雜的判斷邏輯簡化。
上下文環境（context）：它定義了客戶程式需要的介面並維護乙個具體狀態角色的例項，將與狀態相關的操作委託給當前的concrete state物件來處理。
具體狀態（concrete state）：實現抽象狀態定義的介面。
例項
例子1：按鈕來控制乙個電梯的狀態，乙個電梯開們，關門，停，執行。每一種狀態改變，都有可能要根據其他狀態來更新處理。例如，開門狀體，你不能在執行的時候開門，而是在電梯定下後才能開門。
例子2：我們給一部手機打**，就可能出現這幾種情況：使用者開機，使用者關機，使用者欠費停機，使用者消戶等。 所以當我們撥打這個號碼的時候：系統就要判斷，該使用者是否在開機且不忙狀態，又或者是關機，欠費等狀態。但不管是那種狀態我們都應給出對應的處理操作。
/**
* 水的狀態
*/public inte***ce iwaterstate
/** * 冰水狀態實現類
*/public class icewaterstateimpl implements iwaterstate
}/**
* 溫水狀態實現類
*/public class warmwaterstateimpl implements iwaterstate
}/**
* 沸水狀態實現類
*/public class wastewaterstateimpl implements iwaterstate
}/**
* 狀態上下文實現
*/public class watercontext else if(i == 1)else if(i == 2)
}/**
* 獲得狀態物件
* @return
*/public iwaterstate getstate()
}/**
* 測試main方法
*/public class testmain catch (interruptedexception e) }}
}
所有狀態相關的**都存在於某個conceretestate中，所以通過定義新的子類很容易地增加新的狀態和轉換。
狀態模式通過把各種狀態轉移邏輯分不到state的子類之間，來減少相互間的依賴。
缺點
導致較多的concretestate子類
使用場景
1.乙個物件的行為取決於它的狀態，並且它必須在執行時刻根據狀態改變它的行為。
2.乙個操作中含有龐大的多分支結構
，並且這些分支決定於物件的狀態。
比較
職責鏈模式和狀態模式都可以解決if分支語句過多，
從定義來看，狀態模式是乙個物件的內在狀態發生改變（乙個物件，相對比較穩定，處理完乙個物件下乙個物件的處理一般都已確定），
而職責鏈模式是多個物件之間的改變（多個物件之間的話，就會出現某個物件不存在的現在，就像我們舉例的公司請假流程，經理可能不在公司情況），這也說明他們兩個模式處理的情況不同。
這兩個設計模式最大的區別就是狀態模式是讓各個狀態物件自己知道其下乙個處理的物件是誰。
而職責鏈模式中的各個物件並不指定其下乙個處理的物件到底是誰，只有在客戶端才設定。
用我們通俗的程式語言來說，就是
狀態模式：
相當於if else if else；
設計路線：各個state類的內部實現(相當於if，else if內的條件)
執行時通過state呼叫context方法來執行。
職責鏈模式：
相當於swich case
設計路線：客戶設定，每個子類(case)的引數是下乙個子類(case)。
使用時，向鏈的第乙個子類的執行方法傳遞引數就可以。
就像對設計模式的總結，有的人採用的是狀態模式，從頭到尾，提前一定定義好下乙個處理的物件是誰，而我採用的是職責鏈模式，隨時都有可能調整鏈的順序。
狀態模式和策略模式的實現方法非常類似，都是利用多型把一些操作分配到一組相關的簡單的類中，因此很多人認為這兩種模式實際上是相同的。
然而在現實世界中，策略（如**一種商品的策略）和狀態（如同乙個按鈕來控制乙個電梯的狀態，又如手機介面中乙個按鈕來控制手機）是兩種完全不同的思想。當我們對狀態和策略進行建模時，這種差異會導致完全不同的問題。例如，對狀態進行建模時，狀態遷移是乙個核心內容；然而，在選擇策略時，遷移與此毫無關係。另外，策略模式允許乙個客戶選擇或提供一種策略，而這種思想在狀態模式中完全沒有。
乙個策略是乙個計畫或方案，通過執行這個計畫或方案，我們可以在給定的輸入條件下達到乙個特定的目標。策略是一組方案，他們可以相互替換；選擇乙個策略，獲得策略的輸出。策略模式用於隨不同外部環境採取不同行為的場合。我們可以參考微軟企業庫底層object builder的建立物件的strategy實現方式。而狀態模式不同，對乙個狀態特別重要的物件，通過狀態機來建模乙個物件的狀態；狀態模式處理的核心問題是狀態的遷移，因為在物件存在很多狀態情況下，對各個business flow，各個狀態之間跳轉和遷移過程都是及其複雜的。
例如乙個工作流，審批乙個檔案，存在新建、提交、已修改、hr部門審批中、老闆審批中、hr審批失敗、老闆審批失敗等狀態，涉及多個角色互動，涉及很多事件，這種情況下用狀態模式(狀態機)來建模更加合適；把各個狀態和相應的實現步驟封裝成一組簡單的繼承自乙個介面或抽象類的類，通過另外的乙個context來操作他們之間的自動狀態變換，通過event來自動實現各個狀態之間的跳轉。在整個生命週期中存在乙個狀態的遷移曲線，這個遷移曲線對客戶是透明的。我們可以參考微軟最新的wwf 狀態機工作流實現思想。
在狀態模式中，狀態的變遷是由物件的內部條件決定，外界只需關心其介面，不必關心其狀態物件的建立和轉化；而策略模式裡，採取何種策略由外部條件(c)決定他們應用場景（目的）卻不一樣，state模式重在強調物件內部狀態的變化改變物件的行為，strategy模式重在外部對策略的選擇，策略的選擇由外部條件決定，
也就是說演算法的動態的切換。但由於它們的結構是如此的相似，我們可以認為「狀態模式是完全封裝且自修改的策略模式」。即狀態模式是封裝物件內部的狀態的，而策略模式是封裝演算法族的
狀態模式：封裝基於狀態的行為，並將行為委託到當前狀態。
策略模式：將可以互換的行為封裝起來，然後使用委託的方法，決定使用哪一組
模板方法：由子類來決定如何實現演算法中的某些步驟
狀態模式 行為型
3 相關模式 1 狀態模式和策略模式 這是兩個結構相同，功能各異的模式，具體的在策略模式裡面講過了，這裡就不再贅述。2 狀態模式和觀察者模式 這兩個模式乍一看，功能是很相似的，但是又有區別，可以組合使用。這兩個模式都是在狀態發生改變的時候觸發行為，只不過觀察者模式的行為是固定的，那就是通知所有的觀察...
狀態模式 行為型
3 相關模式 1 狀態模式和策略模式 這是兩個結構相同，功能各異的模式，具體的在策略模式裡面講過了，這裡就不再贅述。2 狀態模式和觀察者模式 這兩個模式乍一看，功能是很相似的，但是又有區別，可以組合使用。這兩個模式都是在狀態發生改變的時候觸發行為，只不過觀察者模式的行為是固定的，那就是通知所有的觀察...
狀態模式 行為型
3 相關模式 1 狀態模式和策略模式 這是兩個結構相同，功能各異的模式，具體的在策略模式裡面講過了，這裡就不再贅述。2 狀態模式和觀察者模式 這兩個模式乍一看，功能是很相似的，但是又有區別，可以組合使用。這兩個模式都是在狀態發生改變的時候觸發行為，只不過觀察者模式的行為是固定的，那就是通知所有的觀察...