設計模式小議:state【轉】

​

這個模式使得軟體可以在不同的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過多出現的問題

---------------------

作者：積木

【作者】​​張昺華​​

【知乎】 ​​http://www.zhihu.com/people/zhang-bing-hua​​

【我的作品---旋轉倒立擺】 ​​http://v.youku.com/v_show/id_XODM5NDAzNjQw.html?spm=a2hzp.8253869.0.0&from=y1.7-2​​

【我的作品---自平衡自動循迹車】 ​​http://v.youku.com/v_show/id_XODM5MzYyNTIw.html?spm=a2hzp.8253869.0.0&from=y1.7-2​​

【

【新浪微網誌】 張昺華--sky

【twitter】 @sky2030_

【微信公衆号】 張昺華