這個(gè)模式使得軟件可以在不同的state下面呈現(xiàn)出完全不同的特征

• 不同的theme使得相同的元素呈現(xiàn)出不同的特點(diǎn)
• 不同的state下面相同的操作產(chǎn)生不同的效果
• 不同的狀態(tài)對(duì)相同的信息產(chǎn)生不同的處理

這個(gè)模式使得操作的state邏輯更加的清楚，省去了無數(shù)的state判斷，而state的擴(kuò)展性和可維護(hù)性和執(zhí)行效率也大幅度的上升。關(guān)于state，有如下幾點(diǎn)要注意的地方：

• 所有的state應(yīng)該被一個(gè)類（State Manager Class）管理:

  state之間的跳轉(zhuǎn)和轉(zhuǎn)換是非常復(fù)雜的，有時(shí)一些state可能要跳轉(zhuǎn)的目標(biāo)state有幾十個(gè)，這個(gè)時(shí)候我們需要一個(gè)管理類（State Manager ）來統(tǒng)一的管理這些state的切換，例如目標(biāo)state的初始化和申請(qǐng)?zhí)D(zhuǎn)state的結(jié)束處理，以及一些state間共享數(shù)據(jù)的存儲(chǔ)和處理。與其稱這個(gè)Manager 為管理類，不如說是一個(gè)中間類，它實(shí)現(xiàn)了state之間的解隅，使得各個(gè)state之間不比知道target state的具體信息，而只要向Manager申請(qǐng)?zhí)D(zhuǎn)就可以了。使得各個(gè)state的模塊化更好，更加的靈活

• 所有的state都應(yīng)該從一個(gè)state基類繼承:

  既然state要教給一個(gè)manager來管理，那么自然的，這些state都應(yīng)該從一個(gè)父類繼承下來，這樣manager并不需要知道很多子類的信息，一個(gè)最單純的manager只要只要管理一個(gè)這樣的基類的指針就可以了。另外，我們還可以統(tǒng)一的把state的一些共有的屬性放在這里

• state應(yīng)該實(shí)現(xiàn)為一個(gè)singleton:

  state并不需要總是被申請(qǐng)，這樣可能會(huì)造成管理上的混亂，state資源的申請(qǐng)也不應(yīng)該可以任意進(jìn)行，事實(shí)上，state的申請(qǐng)權(quán)限應(yīng)該只有 Manager才有，并且有且只有一次。在這樣的情況下，state的構(gòu)造函數(shù)似乎應(yīng)該被聲明為protected or private ，而Manager應(yīng)該被聲明為state的友元，但是友元被看成是破壞類的封裝性的一種做法，這一點(diǎn)上，我很矛盾，所以在這一條上我只能采取一種漠視的態(tài)度。

• 應(yīng)該做一個(gè)state么？這是一個(gè)問題：

  state可以說是if-else的一種替代品，極端的情況下面state可以讓你的程序中if-else程序塊消失得無影無蹤，但是，這并不是銀彈。state對(duì)于狀態(tài)可預(yù)知的情況下非常有效，但是對(duì)于state不可預(yù)知，或者相似的state數(shù)量太多。過多的state會(huì)造成class的粒度過細(xì)，程序反而不簡(jiǎn)潔。在這樣的情況下，你應(yīng)該考慮使用if-else程序塊來替代state。

  例如：

  有這樣的一個(gè)程序，它可以生成任意形狀的多邊形，而多邊形的各個(gè)節(jié)點(diǎn)是可以移動(dòng)的，問題就來了。

  我并不知道用戶將要使用多少個(gè)節(jié)點(diǎn)的多邊形，因此我無法的創(chuàng)建那么多相應(yīng)的state來使得這樣一個(gè)程序正常工作。state大多數(shù)都是確定的，對(duì)于不確定的，state似乎無能為力，例如此例

  一種解決方法是我利用Manager傳遞給state一個(gè)state參數(shù)，讓state有機(jī)會(huì)知道用戶的操作意圖，在這個(gè)例子里面是讓state知道用戶打算操作某一個(gè)節(jié)點(diǎn)，而state根據(jù)這個(gè)state參數(shù)來處理用戶的操作，比如說，state得到的是用戶操作的某一個(gè)點(diǎn)的index ,而state只要寫

  points[index].moveTo(points[index].getX()+offset_x , points[index].getY()+offset_y)；

  就可以，從而避免了state過多出現(xiàn)的問題

對(duì)象的切換:

// ?State?pattern?--?Structural?example??


using ?System;

namespace ?DoFactory.GangOfFour.State.Structural
{
??
?? // ?MainApp?test?application?

?? class ?MainApp
?? {
???? static ? void ?Main()
???? {
?????? // ?Setup?context?in?a?state?
??????Context?c? = ? new ?Context( new ?ConcreteStateA());

?????? // ?Issue?requests,?which?toggles?state?
??????c.Request();
??????c.Request();
??????c.Request();
??????c.Request();

?????? // ?Wait?for?user?
??????Console.Read();
????}
??}

?? // ?"State"?

?? abstract ? class ?State
?? {
???? public ? abstract ? void ?Handle(Context?context);
??}

?? // ?"ConcreteStateA"?

?? class ?ConcreteStateA?:?State
?? {
???? public ? override ? void ?Handle(Context?context)
???? {
??????context.State? = ? new ?ConcreteStateB();
????}
??}

?? // ?"ConcreteStateB"?

?? class ?ConcreteStateB?:?State
?? {
???? public ? override ? void ?Handle(Context?context)
???? {
??????context.State? = ? new ?ConcreteStateA();
????}
??}

?? // ?"Context"?

?? class ?Context
?? {
???? private ?State?state;

???? // ?Constructor?
???? public ?Context(State?state)
???? {
?????? this .State? = ?state;
????}

???? // ?Property?
???? public ?State?State
???? {
?????? get {? return ?state;?}
?????? set
?????? {?
????????state? = ?value;?
????????Console.WriteLine( " State:? " ? + ?
??????????state.GetType().Name);
??????}
????}

???? public ? void ?Request()
???? {
??????state.Handle( this );
????}
??}
} ?

?