• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            C++ Programmer's Cookbook

            {C++ 基礎} {C++ 高級} {C#界面,C++核心算法} {設計模式} {C#基礎}

            模式設計c#--行為型--state

            名稱 State
            結構 o_state.bmp
            意圖 允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為。對象看起來似乎修改了它的類。
            適用性
            • 一個對象的行為取決于它的狀態(tài), 并且它必須在運行時刻根據(jù)狀態(tài)改變它的行為。
            • 一個操作中含有龐大的多分支的條件語句,且這些分支依賴于該對象的狀態(tài)。這個狀態(tài)通常用一個或多個枚舉常量表示。通常, 有多個操作包含這一相同的條件結構。S t a t e模式將每一個條件分支放入一個獨立的類中。這使得你可以根據(jù)對象自身的情況將對象的狀態(tài)作為一個對象,這一對象可以不依賴于其他對象而獨立變化。

            namespace ?State_DesignPattern
            {
            ????
            using ?System;

            ????
            abstract ? class ?State?
            ????
            {
            ????????
            protected ? string ?strStatename;????????

            ????????
            abstract ? public ? void ?Pour();
            ????????
            // ?do?something?state-specific?here
            ????}


            ????
            class ?OpenedState?:?State?
            ????
            {????????
            ????????
            public ?OpenedState?()
            ????????
            {
            ????????????strStatename?
            = ? " Opened " ;
            ????????}

            ????????
            override ? public ? void ?Pour()
            ????????
            {
            ????????????Console.WriteLine(
            " pouring " );
            ????????????Console.WriteLine(
            " pouring " );
            ????????????Console.WriteLine(
            " pouring " );
            ????????}

            ????}

            ????
            ????
            class ?ClosedState?:?State?
            ????
            {????????
            ????????
            public ?ClosedState()
            ????????
            {
            ????????????strStatename?
            = ? " Closed " ;
            ????????}

            ????????
            override ? public ? void ?Pour()
            ????????
            {
            ????????????Console.WriteLine(
            " ERROR?-?bottle?is?closed?-?cannot?pour " );
            ????????}

            ????}


            ????
            class ?ContextColaBottle?
            ????
            {
            ????????
            public ? enum ?BottleStateSetting? {
            ????????????Closed,
            ????????????Opened
            ????????}
            ;

            ????????
            // ?If?teh?state?classes?had?large?amounts?of?instance?data,
            ????????
            // ?we?could?dynamically?create?them?as?needed?-?if?this?demo
            ????????
            // ?they?are?tiny,?so?we?just??create?them?as?data?members
            ????????OpenedState?openedState? = ? new ?OpenedState();
            ????????ClosedState?closedState?
            = ? new ?ClosedState();

            ????????
            public ?ContextColaBottle?()
            ????????
            {
            ????????????
            // ?Initialize?to?closed
            ????????????CurrentState? = ?closedState;
            ????????}


            ????????
            private ?State?CurrentState;
            ????????
            ????????
            public ? void ?SetState(BottleStateSetting?newState)
            ????????
            {
            ????????????
            if ?(newState? == ?BottleStateSetting.Closed)
            ????????????
            {
            ????????????????CurrentState?
            = ?closedState;
            ????????????}

            ????????????
            else ?
            ????????????
            {
            ????????????????CurrentState?
            = ?openedState;
            ????????????}

            ????????}


            ????????
            public ? void ?Pour()
            ????????
            {
            ????????????CurrentState.Pour();
            ????????}
            ????
            ????}


            ??????
            /// ? <summary>
            ????
            /// ????Summary?description?for?Client.
            ????
            /// ? </summary>

            ???? public ? class ?Client
            ????
            {
            ????????
            public ? static ? int ?Main( string []?args)
            ????????
            {
            ????????????ContextColaBottle?contextColaBottle?
            = ? new ?ContextColaBottle();

            ????????????Console.WriteLine(
            " initial?state?is?closed " );

            ????????????Console.WriteLine(
            " Now?trying?to?pour " );
            ??????????????contextColaBottle.Pour();

            ????????????Console.WriteLine(
            " Open?bottle " );
            ????????????contextColaBottle.SetState(ContextColaBottle.BottleStateSetting.Opened);

            ????????????Console.WriteLine(
            " Try?to?pour?again " );
            ????????????contextColaBottle.Pour();

            ????????????
            return ? 0 ;
            ????????}

            ????}

            }


            設計模式:關于State模式的一些需要注意的地方

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

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

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

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

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

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

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

            • state應該實現(xiàn)為一個singleton:

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

            • 應該做一個state么?這是一個問題:

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

              例如:

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

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

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

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

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

            對象的切換:

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

            ??}

            }
            ?

            ?

            posted on 2006-01-03 16:15 夢在天涯 閱讀(1107) 評論(2)  編輯 收藏 引用 所屬分類: Design pattern

            評論

            # re: 模式設計c#--行為型--state 2006-04-25 14:33 夢在天涯

            State模式與Strategy模式的區(qū)別時什么啊?,potian大俠幫忙。
            首先,兩者的意圖是不同的。策略用來處理算法變化,而狀態(tài)則是透明地處理狀態(tài)變化。
            造成混淆的原因可能是兩者好像都能成為繼承的替代。
            策略主要處理算法變化的意思是算法可能是要變的,但是這種變化卻是由用戶來決定到底采用何種算法。這些算法之間一般來說沒有狀態(tài)變遷的問題,并且你總是從幾個算法中間選取一個。策略最經(jīng)典的用法是和observe一起組成MVC,其中V通過Observe觀察M,而V通過strategy控制C.
            策略使用的另一個最頻繁的地方就是消除大量的Case或if else ,但是條件是這些case中每個條件可以歸納為一個算法,最好它們只需要相同的參數(shù)。當然,在strategy中,Context可以提供接口讓strategy,但是我一般不太喜歡這么用,因為這樣可能造成一系列的不必要耦合和開銷。
            對這些case,if else使得strategy有了一個policy的別名,還有一個常用的地方叫做validator,譬如在輸入框內(nèi)進行檢查時可以把它實現(xiàn)為Validator。有時候,if else的嵌套層次可能很深,這時候策略可能不能用,那么你可能需要更加復雜或者更加專注的Rule模式。
            狀態(tài)模式則有所不同,她實現(xiàn)的一個概念可以叫做動態(tài)繼承,也就是繼承的子類(每一個狀態(tài))可以發(fā)生變化。這些狀態(tài)的變化是一個整體,組成了一個狀態(tài)變化圖。而一般來說,使用該模式的狀態(tài)之間存在著一種線性變化的關系,也就是一個狀態(tài)變?yōu)榱硪粋€,然后是第三個。客戶代碼并不清楚這些狀態(tài)在何時發(fā)生變化,這樣做的好處是在組成你整個變化過程中某些狀態(tài)之間需要插入一個新的狀態(tài),或者狀態(tài)的順序之間發(fā)生變化,對客戶是不可見。實現(xiàn)模式一方面,修改的也只是相領的狀態(tài)。在處于不同的狀態(tài)時,客戶代碼可以執(zhí)行的方法也是不同的。但它的問題就是必須在Context和所有的狀態(tài)實現(xiàn)所有狀態(tài)可能的方法。
            這兩個之間的區(qū)別有時候可能沒有,譬如在面向連結的TCPConnection例子中,不同的狀態(tài)可能具有不同的方法。但是在我剛剛實現(xiàn)的一個無連結的P2P底層協(xié)議中,所有狀態(tài)需要處理地就是一個processXML方法,這時候,你可以叫它狀態(tài)或者策略都可以。但由于還是又狀態(tài)變遷的問題,所以我喜歡把它叫做狀態(tài)。  回復  更多評論   

            # re: 模式設計c#--行為型--state 2006-04-30 18:39 cxvcx

            zxcxzc  回復  更多評論   

            公告

            EMail:itech001#126.com

            導航

            統(tǒng)計

            • 隨筆 - 461
            • 文章 - 4
            • 評論 - 746
            • 引用 - 0

            常用鏈接

            隨筆分類

            隨筆檔案

            收藏夾

            Blogs

            c#(csharp)

            C++(cpp)

            Enlish

            Forums(bbs)

            My self

            Often go

            Useful Webs

            Xml/Uml/html

            搜索

            •  

            積分與排名

            • 積分 - 1804752
            • 排名 - 5

            最新評論

            閱讀排行榜

            久久婷婷五月综合色奶水99啪| 18禁黄久久久AAA片| 精品久久久久久无码人妻蜜桃| 久久人人爽人人爽AV片| 久久亚洲AV成人无码电影| 丁香五月综合久久激情| 婷婷伊人久久大香线蕉AV | 久久久精品国产亚洲成人满18免费网站 | 国产亚洲精午夜久久久久久| 一级A毛片免费观看久久精品| 久久99精品国产99久久| 欧美久久久久久| 国产2021久久精品| 性欧美大战久久久久久久久| 久久伊人亚洲AV无码网站| 精品久久久久久无码专区不卡 | 久久ww精品w免费人成| 久久精品一区二区影院| 91视频国产91久久久| 中文国产成人精品久久不卡| 欧美日韩精品久久久免费观看| 精品国产VA久久久久久久冰| 老男人久久青草av高清| 久久综合九色综合欧美就去吻 | 日韩精品无码久久久久久| 久久综合亚洲色HEZYO社区| 久久精品国产亚洲7777| 国产成人久久777777| 精品999久久久久久中文字幕| 人妻精品久久久久中文字幕69| 久久九九兔免费精品6| 久久夜色精品国产亚洲| 久久久久久国产a免费观看黄色大片 | 国内精品综合久久久40p| 中文字幕精品久久久久人妻| 国产巨作麻豆欧美亚洲综合久久 | 久久涩综合| 日本久久久久久久久久| 久久综合偷偷噜噜噜色| 久久久久亚洲精品日久生情| 中文字幕乱码人妻无码久久|