設計模式狀態模式

狀態模式（state），當乙個物件的內部狀態改變時允許改變其行為，這個物件看起來像是改變了其類。

狀態管理者

public class context 
/*** 客戶端呼叫
*/public void request(string sampleparameter) 
}

抽象狀態

public inte***ce state

具體狀態a

public class concretestatea implements state 
}

具體狀態b

public class concretestateb implements state 
}

客戶端呼叫方

public class client 
}

小a正在召喚師峽谷廝殺，他玩的是卡特，買了一本殺人書。隨著遊戲時間的進行，小a殺的人越來越多，且自己都沒死過，遊戲中不斷傳來「***暴走了」、「***主宰了比賽」、「***接近神了」。最終小a以12殺0死的完美戰績結束了比賽，腦海中剛才的捷報聲還在不停環繞在他的耳邊，他就想這不就是狀態模式，隨後開啟ide開始復現剛才的過程。

環境類

package com.jo.state;
/** * @author jo
* @date 2018/1/17
*/public class lolcontext 
public integer getkillnum() 
public lolcontext setkillstate(killstate killstate) 
/*** 殺人方法，
*/public void kill()
}

抽象殺人狀態

public inte***ce killstate

普通擊殺

public class normal implements killstate }}

大殺特殺

public class killingspring implements killstate 
}

接近暴走

public class rampage implements killstate 
}

無人可擋

public class unstoppable implements killstate 
}

、、、

、超神

public class legendary implements killstate 
}

客戶端呼叫

public class client }}

執行結果

客戶端只負責呼叫lolcontext的kill方法，其餘一概不知，內部便會隨著殺人數的增長列印不同的通知。而lolcontext中也沒有複雜，一大串的if else switch case，狀態的轉移在各自的具體狀態中，如果需要修改部分邏輯只需要改對應的狀態，而不需要改原本在一起的if else，大大減少了隱患的發生率，從而不會發生牽一髮而動全身的結果。

狀態模式的優點是解除了程式的耦合度，採用子類的方式去除了煩瑣容易出錯的if else，但反而帶來的是類的資料增多。如果你要實現的功能狀態不多，且功能簡單，那不推薦使用狀態模式，不然會徒增程式的複雜性。且要執行的動作有一定的複雜度，此例的kill方法是最簡單的實現，實際應用中複雜度是遠遠大於它的。你可以想象在狀態多，且複雜的動作中不使用狀態模式會事怎樣，if else多的眼花繚亂，上乙個if和下乙個else if相差幾百行**，想必這樣的**誰都不願意碰，萬一改壞了就要背鍋了。

狀態模式和和策略模式有點相像，狀態模式的狀態轉移是內部控制的，而策略模式是由客戶端控制採用不同的策略。因此在目的和實現還是有很大的差別的。有些場景「狀態」不是那麼明顯，需要轉換成狀態模式就考察使用者的功底和對業務的理解程度了，望大家都能get更多知識點，能力越來越強，個個都是架構師。

設計模式 狀態模式

設計模式 狀態模式

設計模式 狀態模式

設計模式 狀態模式

相關推薦

設計模式狀態模式

設計模式狀態模式

設計模式狀態模式

設計模式狀態模式