狀態模式（State）

很多同學在寫**時，很喜歡使用if else if else if else if else，然後乙個方法中，**量可想而知，在網際網路企業高速迭代中，此時要修改乙個地方，眼淚水都能看出來，此時就應該想到23中設計模式中的狀態模式。

在阿里的編碼規範中明確寫到，【強制】避免後續**維護困難，請勿超過3層的if判斷

gof設計模式的定義是：允許乙個物件在其內部狀態改變時改變它的行為。物件看起來似乎修改了他所屬的類。

常規寫法

order o = new

order()
;if (o.orderstatus == 1
) 
else
if (o.orderstatus == 2
) 
else
if (o.orderstatus == 3
) 
else
if (o.orderstatus == 4
) 
else

鑑於此種寫法，當狀態新增了5,6,7種不同狀態時，直接在原有**中修改，導致整個方法中**量非常大，不利於維護。

編寫可讀性，可維護性的**（狀態模式）

定義抽象類，提供狀態變更通知

中間狀態假設存在

訂單模型中採用充血模式，預設當前狀態為新建訂單，執行狀態變更通知。

訂單類：

public

class
order
public
string orderno 
public
decimal orderamount 
public
byte orderstatus 
private
orderstate currentstate;
public
orderstate currentstate
}public
order()
public
void
statechangenotify()
}

抽象訂單狀態類

public

abstract
class
orderstate

public

class
createorderstate : orderstate
else}}

public

class
paysuccessstate : orderstate
else}}

order o = new

order()
;o.statechangenotify();
o.orderstatus = 2
; o.statechangenotify();
o.orderstatus = 3
; o.statechangenotify();
o.orderstatus = 4
; o.statechangenotify();
o.orderstatus = 5
; o.statechangenotify();
console.readline();

其他**省略………………

此時可以看出，當我們訂單狀態不管賦值任何時，直接呼叫充血模式中的訂單物件的狀態變更通知statechangenotify方法，則自動完成當前狀態的變更通知，當我們整個訂單狀態更多時，我們只需要新增訂單狀態類繼承至訂單狀態通知抽象類，就能完成對應通知的開發。

狀態模式其實只是讓你的一大段if else變成了乙個個視覺化的物件，便於維護，使**可讀性，可維護性大大提高。

狀態 State 模式

物件狀態影響物件行為 物件擁有不同的狀態，往往會行使不同的行為.1 動機 在軟體構建過程中，某些物件的狀態如果改變，其行為也會隨之而發生變化。比如文件處於唯讀狀態，其支援的行為和讀寫狀態支援的行為就可能完全不同。如何在執行時根據物件的狀態來透明地更改物件的行為？而不會為物件操作和狀態轉化之前引入緊耦...

狀態模式 State

個人理解 核心是context維護乙個當前狀態，並在invoke狀態方法時，將context維護的當前狀態更新至下一狀態 uml類圖 實現 using system namespace decoratormode public class agecontext public void printag...

state 狀態模式

include include using namespace std 1 將 state宣告為 context的友元類 friend class 其作用是讓 state模式訪問 context 的 protected介面 changesate 2 state 及其子類中的操作都將 context ...