各位朋友，本次LZ分享的是狀態模式，在這之前，懇請LZ解釋一下，由於最近公司事情多，比較忙，所以導致更新速度稍微慢了些（哦，往後LZ會越來越忙=。=）。 狀態模式，又稱狀態對象模式（Pattern of Objects for States），狀態模式是對象的行為模式。 狀態模式允許一個對象在其內部 ...
各位朋友，本次LZ分享的是狀態模式，在這之前，懇請LZ解釋一下，由於最近公司事情多，比較忙，所以導致更新速度稍微慢了些（哦，往後LZ會越來越忙=。=）。
狀態模式，又稱狀態對象模式（Pattern of Objects for States），狀態模式是對象的行為模式。
狀態模式允許一個對象在其內部狀態改變的時候改變其行為。這個對象看上去就像是改變了它的類一樣。
這裡LZ給大家舉例子，海賊王中路飛在打多弗朗明哥的時候，首先是普通狀態，然後發怒開啟二擋狀態，被多弗朗明哥嘲笑速度快，但是力量低，於是開啟三擋狀態，又被嘲笑力量夠了，但是速度差遠了，路飛被逼急，於是開啟四擋，最終打敗了多弗朗明哥。現在我們通過代碼實現這樣的一個過程。
這裡我們發現路飛的狀態經歷了普通，二擋，三擋，四擋，共四個狀態，我們創建一個實例變數state來持有目前的狀態，然後定義每個狀態的值
public final static int ORDINARY = 0;//普通狀態
public final static int SECONDGEAR = 1;//二擋狀態
public final static int THIRDGEAR = 2;//三擋狀態
public final static int FOURTHGEAR = 3;//四擋狀態
private int state = ORDINARY;//由於路飛一開始是普通狀態，所以我們初始化state為ORDINARY
接下來我們實現LuFei這個類
public class LuFei {
public final static int ORDINARY = 0;//普通狀態
public final static int SECONDGEAR = 1;//二擋狀態
public final static int THIRDGEAR = 2;//三擋狀態
public final static int FOURTHGEAR = 3;//四擋狀態
private int state = ORDINARY;//由於路飛一開始是普通狀態，所以我們初始化state為ORDINARY
public void setstate(int state) {
this.state = state;
}
public void change(){
if(state == SECONDGEAR){
System.out.println("路飛開啟二擋戰鬥");
}else if(state == THIRDGEAR){
System.out.println("路飛開啟三擋戰鬥");
}else if(state == FOURTHGEAR){
System.out.println("路飛開啟四擋戰鬥");
}else{
System.out.println("路飛當前為普通狀態戰鬥");
}
}
}
現在我們寫個測試類
public class TestLuFei {
public static void main(String[] args) {
LuFei luFei = new LuFei();
luFei.setstate(luFei.SECONDGEAR);
luFei.change();
luFei.setstate(luFei.THIRDGEAR);
luFei.change();
luFei.setstate(luFei.FOURTHGEAR);
luFei.change();
luFei.setstate(luFei.ORDINARY);
luFei.change();
}
}
這裡可以看到，通過狀態的改變，路飛會以不同的狀態進行戰鬥。
該來了總躲不過，那就是，變更需求！
這裡，路飛在第一次變四擋後，並沒有打敗多弗朗明哥，而是因為四擋導致進入了第五個狀態：虛弱狀態，現在我們還要再加上一個if語句，把虛弱狀態扔進去。這裡就看出了問題，我們這個由於需求及其簡單，所以代碼特別簡潔，但是倘若這是一個複雜的業務，我們每一次變更狀態難道都要在類中增加if else語句或者是新的業務邏輯嗎？這顯然違背了我們的設計原則：封裝變化原則。（這裡各位可能會突然想起來策略模式，那裡也用到了這個原則。）
現在，讓我們重寫代碼，將每個狀態對象封裝到各自的類中，然後在動作發生時委托給當前對象。我們的步驟為：
1.首先，我們創建一個state的介面，我們把每個狀態共有的change方法放在這個介面中
2.接下來，我們讓每一個狀態都實現狀態類，這些類將負責在對應的狀態下進行相應行為
3.最後，我們將動作委托到狀態類中
interface LuFeiState{
public void change();
}
class Ordinary implements LuFeiState{
@Override
public void change() {
System.out.println("路飛當前為普通狀態戰鬥");
}
}
class SecondGear implements LuFeiState{
@Override
public void change() {
System.out.println("路飛開啟三擋戰鬥");
}
}
class ThirdGear implements LuFeiState{
@Override
public void change() {
System.out.println("路飛開啟三擋戰鬥");
}
}
class FourthGear implements LuFeiState{
@Override
public void change() {
System.out.println("路飛開啟四擋戰鬥");
}
}
由於LZ的State類在其他包下已經定義過了，所以這裡LZ改名為LuFeiState.
接下來我們修改路飛類：
public class LuFei {
public static final LuFeiState Ordinary = new Ordinary();//普通狀態
public static final LuFeiState SecondGear = new SecondGear();//二擋狀態
public static final LuFeiState ThirdGear = new ThirdGear();//三擋狀態
public static final LuFeiState FourthGear = new FourthGear();//四擋狀態
private LuFeiState state = Ordinary;//由於路飛一開始是普通狀態，所以我們初始化state為ORDINARY
public void setstate(LuFeiState state) {
this.state = state;
}
public void change(){
state.change();
}
}
可以看到，我們原本一大堆的if else語句消失了，代替的，是非常簡潔的代碼。看到這裡，各位一定產生了一個問題，別急，忍住，LZ稍後會作解釋。
接下來是我們的測試類：
public class TestLuFei {
public static void main(String[] args) {
LuFei luFei = new LuFei();
luFei.setstate(luFei.SecondGear);
luFei.change();
luFei.setstate(luFei.ThirdGear);
luFei.change();
luFei.setstate(luFei.FourthGear);
luFei.change();
luFei.setstate(luFei.Ordinary);
luFei.change();
}
}
這是我們重做之前的代碼，可以看出，當有新的狀態產生時，我們只需要寫一個新的狀態類實現State介面，在路飛類中提供一個變數即可，其他的都不需要動。對比原本的例子，我們明顯的發現：
一：每個狀態的行為局部化到它自己的類中
二、將容易產生問題的if else結構去掉，使得代碼的可維護性更強，不易出錯。
三、使用多態代替了條件判斷，這樣我們代碼的擴展性更強，當要增加一些狀態時，會非常的容易。
四、讓每一個狀態對修改關閉，對擴展開放
五、狀態是可以被共用的，這個在上面的例子當中有體現，看下LuFei類當中的四個static final變數就知道了，因為狀態類一般是沒有自己的內部狀態的，所有它只是一個具有行為的對象，因此是可以被共用的。
六、狀態的轉換更加簡單安全，簡單體現在狀態的分割，因為我們把一堆if else分割成了若幹個代碼段分別放在幾個具體的狀態類當中，所以轉換起來當然更簡單，而且每次轉換的時候我們只需要關註一個固定的狀態到其他狀態的轉換。安全體現在類型安全，我們設置狀態時，必須是狀態介面的實現類，而不是原本的一個整數，這可以杜絕數不正確的狀態碼。
寫到這裡，不需要明說各位也看出了我們用到的是狀態模式。
狀態模式允許對象在內部狀態改變時改變它的行為，對象看起來好像改變了它的類
1.Context（上下文）是一個類，它可以擁有一些內部狀態，相當於我們例子中的LuFei。
2.state.handle() :不管什麼時候，只要有人調用Context的request方法，它就會被委托到狀態來處理。
3.state介面定義了一個所有具體狀態的共同介面；任何狀態都實現這個相同的介面，這樣一來狀態之間可以互相替換。
4.ConcreteState（具體狀態）處理來自Context的請求，每一個ConcreteState都提供了它自己對於請求的實現。所以，當Context改變狀態時行為也跟著改變。
狀態模式適用於某一個對象的行為取決於該對象的狀態，並且該對象的狀態會在運行時轉換，又或者有很多的if else判斷，而這些判斷只是因為狀態不同而不斷的切換行為。
到這裡，相信各位早已按捺不住想問LZ：這個模式明明就是策略模式嗎，無論是類圖，還是結構，都跟策略模式一模一樣啊！
下麵LZ給出兩者的區別：
狀態模式：將一群行為封裝到狀態對象中，context的行為隨時可委托到那些狀態對象中的一個。隨著時間的流逝，當前狀態在狀態對象集合中游走改變，以反映出context內部的狀態，因此，context的行為也會跟著改變。但是context的客戶對於狀態對象瞭解不多，甚至根本是渾然不覺。
而以策略模式而言，客戶通常主動指定Context所要組合的策略對象是哪一個。現在，固然策略模式讓我們具有彈性，能夠在運行時改變策略，但對於某個context對象來說，通常都只有一個最適當的策略對象。比方說LZ前面第一章所舉的例子。
一般來說，我們把策略模式想成是除了繼承之外的一種彈性替代方案。如果你使用繼承定義了一個類的行為，你將被這個行為困住，甚至要修改它都很難。有了策略模式，你可以通過組合不同的對象來改變行為。
我們把狀態模式想成是不用在context中放置許多條件判斷的替代方案。通過將行為包裝進狀態對象中，你可以通過在context內簡單地改變狀態對象來改變context的行為。
下麵我們總結一下狀態模式的要點：
1.狀態模式允許一個對象基於內部狀態而擁有不同的行為。
2.狀態模式用類代表狀態
3.Context會將行為委托給當前狀態對象
4.通過將每個狀態封裝進一個類，我們把以後需要做的任何改變局部化了
5.狀態模式和策略模式有相同的類圖，但是它們的意圖不同
6.策略模式通常會用行為或演算法來配置Context類
7.狀態模式允許Context隨著狀態的改變而改變行為
8.狀態轉換可以由State類或Context類控制。
9.使用狀態模式通常會導致設計中類的數目大量增加。
10.狀態類可以被多個Context實例共用。
另外 ，狀態模式在項目當中也算是較經常會碰到的一個設計模式，但是通常情況下，我們還是在看到if else的情況下，對項目進行重構時使用，又或者你十分確定要做的項目會朝著狀態模式發展，一般情況下，LZ不建議在項目的初期使用。
本次LZ狀態模式的分享就到此結束了，希望各位有所收穫。
