這個模式使得軟件可以在不同的state下面呈現出完全不同的特征

• 不同的theme使得相同的元素呈現出不同的特點
• 不同的state下面相同的操作產生不同的效果
• 不同的狀態對相同的信息產生不同的處理

這個模式使得操作的state邏輯更加的清楚，省去了無數的state判斷，而state的擴展性和可維護性和執行效率也大幅度的上升。關于state，有如下幾點要注意的地方：

• 所有的state應該被一個類（State Manager Class）管理:

  state之間的跳轉和轉換是非常復雜的，有時一些state可能要跳轉的目標state有幾十個，這個時候我們需要一個管理類（State Manager ）來統一的管理這些state的切換，例如目標state的初始化和申請跳轉state的結束處理，以及一些state間共享數據的存儲和處理。與其稱這個Manager 為管理類，不如說是一個中間類，它實現了state之間的解隅，使得各個state之間不比知道target state的具體信息，而只要向Manager申請跳轉就可以了。使得各個state的模塊化更好，更加的靈活

• 所有的state都應該從一個state基類繼承:

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

• state應該實現為一個singleton:

  state并不需要總是被申請，這樣可能會造成管理上的混亂，state資源的申請也不應該可以任意進行，事實上，state的申請權限應該只有 Manager才有，并且有且只有一次。在這樣的情況下，state的構造函數似乎應該被聲明為protected or private ，而Manager應該被聲明為state的友元，但是友元被看成是破壞類的封裝性的一種做法，這一點上，我很矛盾，所以在這一條上我只能采取一種漠視的態度。

• 應該做一個state么？這是一個問題：

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

  例如：

  有這樣的一個程序，它可以生成任意形狀的多邊形，而多邊形的各個節點是可以移動的，問題就來了。

  我并不知道用戶將要使用多少個節點的多邊形，因此我無法的創建那么多相應的state來使得這樣一個程序正常工作。state大多數都是確定的，對于不確定的，state似乎無能為力，例如此例

  一種解決方法是我利用Manager傳遞給state一個state參數，讓state有機會知道用戶的操作意圖，在這個例子里面是讓state知道用戶打算操作某一個節點，而state根據這個state參數來處理用戶的操作，比如說，state得到的是用戶操作的某一個點的index ,而state只要寫

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

  就可以，從而避免了state過多出現的問題

對象的切換:

// ?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 );
????}
??}
} ?

?