設計模式學習筆記狀態模式

定義：

當乙個物件內在的狀態改變時，允許其改變行為，這個物件看起來像是改變了其類。

狀態模式不太好理解，我現在還沒有完全理解，這個模式給我的第一印象就是比較亂，給我的感覺好像是兩個類互相依賴，①呼叫②的方法，②呼叫①的方法，弄的好亂，所以這個狀態模式就不用通用類圖去描述了，那樣會不知所云，還是舉乙個實際的例子來理解吧。

這個例子是書本上的乙個例子，是針對足球隊比賽時，根據比分的領先還是落後，來調整其陣型，從而進入相應的狀態，其示意圖如下：

其對應的類圖如下：

圖2 足球對的狀態模式類圖

解釋：可以注意到footballteam這個類維護了乙個scorestate物件，表示footballteam這個類維護當前的乙個狀態，通過其中的changestate()方法來切換維護的狀態，而改變陣型的方法changelineup()這個方法是足球隊的行為，它只是呼叫當前維護狀態中的changelineup()方法，因為具體的實現是在狀態類中取實現的。而在狀態類中，也有乙個changestate()方法，這個行為的作用是呼叫footballteam中的changestate()方法，來改變footballteam所維護的狀態。

所以要理解這個交叉的類圖，關鍵要抓住兩點：

1、changelineup()方法在狀態類中實現，而在footballteam類中呼叫；

2、changestate()方法在footballteam類中實現，而在狀態類中呼叫；

狀態模式有什麼好處呢？為什麼要這樣做呢？

狀態模式的本質是將條件語句的各個分支封裝起來，從而實現了狀態邏輯與動作的分離。當分支很多時，這種模式會給**的維護帶來很大的便利。比如說要增加乙個狀態，採用分支的話，就要涉及到多個分支的更改。而用狀態模式，只需要增加乙個新的狀態實現類，在這個類中定義這個狀態可以切換到哪些狀態，這個狀態下可以有什麼行為，就可以了。當要修改乙個狀態，只需要修改這個狀態類就可以了。

狀態模式的封裝性非常好，狀態變化放置到類的內部來實現，外部的呼叫不用知道類內部如何實現狀態和行為的切換。

上面例子的源**如下：

public abstract class scorestate 
}

/*
* 平局狀態，有兩種可能切換的狀態：
* 1、對手先進球，比分落後，這時調整陣型，狀態進入比分落後狀態
* 2、己方先進球，比分領先，這時調整陣型，狀態進入比分領先狀態
*/public class drawstate extends scorestate 
else if(score=="ahead")
}}

/*
* 比分落後，只有一種可能切換的狀態：己方進球扳平比分，比分持平，調整陣型，狀態進入持平狀態
*/public class lagstate extends scorestate 
}}

/*
* 比分領先，只有一種可能切換的狀態：對手進球扳平比分，比分持平，調整陣型，狀態進入持平狀態
*/public class aheadstate extends scorestate 
}}

public class client 
}

設計模式學習筆記 狀態模式

設計模式學習筆記 狀態模式

設計模式學習筆記 狀態模式

設計模式學習筆記 狀態模式

相關推薦

設計模式學習筆記狀態模式

設計模式學習筆記狀態模式

設計模式學習筆記狀態模式

設計模式學習筆記狀態模式