青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

C++ Programmer's Cookbook

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

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

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

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下面呈現出完全不同的特征

  • 不同的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 );
????}

??}

}
?

?

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

評論

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

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

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

zxcxzc  回復  更多評論   

公告

EMail:itech001#126.com

導航

統計

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

常用鏈接

隨筆分類

隨筆檔案

收藏夾

Blogs

c#(csharp)

C++(cpp)

Enlish

Forums(bbs)

My self

Often go

Useful Webs

Xml/Uml/html

搜索

  •  

積分與排名

  • 積分 - 1811983
  • 排名 - 5

最新評論

閱讀排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
              六月天综合网| 日韩视频亚洲视频| 欧美在线观看网址综合| 国内精品久久久久影院优| 久久久久久久久岛国免费| 久久精品国产第一区二区三区最新章节| 国产一区二区三区四区五区美女| 老司机午夜精品视频| 牛牛精品成人免费视频| 一区二区欧美国产| 亚洲中无吗在线| 国内精品久久久久久久影视蜜臀| 欧美成人dvd在线视频| 欧美另类99xxxxx| 亚洲欧美春色| 久久久五月天| 亚洲天堂av电影| 亚洲欧美制服另类日韩| 亚洲人成绝费网站色www| 一区二区三区黄色| 国内成人精品视频| 亚洲乱码国产乱码精品精98午夜| 国产精品亚洲激情| 欧美黄色影院| 国产精品午夜春色av| 欧美顶级艳妇交换群宴| 国产精品美女久久久免费| 国产精品国产自产拍高清av| 亚洲国产导航| 亚洲欧美日韩中文播放| 91久久久久| 欧美一区二区在线| 亚洲在线不卡| 欧美成人综合| 老巨人导航500精品| 国产精品一二三四| 亚洲经典三级| 国产精品视频久久| 亚洲精品一区二区三区在线观看 | 欧美xart系列高清| 久久丁香综合五月国产三级网站| 欧美精品在线视频观看| 久久躁日日躁aaaaxxxx| 国产精品美女久久| av成人福利| 日韩视频免费看| 老色鬼久久亚洲一区二区 | 亚洲国产mv| 欧美一区二区三区久久精品| 午夜精品久久久久久久久久久久久| 免费一级欧美在线大片| 模特精品在线| 激情欧美一区二区三区| 亚洲欧美在线免费| 欧美一区二区三区啪啪| 国产精品久线观看视频| 一本到高清视频免费精品| 亚洲精品免费在线播放| 欧美成人精品不卡视频在线观看| 免费不卡在线视频| 亚洲大胆人体在线| 你懂的视频欧美| 亚洲激情在线播放| 99在线热播精品免费| 欧美区二区三区| 一本大道av伊人久久综合| 一区二区免费在线播放| 欧美日韩国产二区| 一区二区日韩| 欧美一区二区三区日韩视频| 国产精品日韩二区| 欧美一区二区三区久久精品| 久久在线播放| 亚洲国产清纯| 欧美日韩一级大片网址| 亚洲一区二区免费看| 久久精品国语| 亚洲经典在线看| 欧美日韩国产另类不卡| 亚洲一区自拍| 免费久久久一本精品久久区| 亚洲欧洲免费视频| 欧美日韩一区二区视频在线| 亚洲一级在线观看| 久久久噜噜噜久久狠狠50岁| 亚洲高清电影| 欧美午夜电影在线| 欧美专区日韩专区| 亚洲黄色视屏| 欧美中文在线免费| 亚洲国产精品一区二区第四页av | 最近中文字幕日韩精品| 一区二区三区av| 国产手机视频精品| 老司机一区二区三区| 一区二区三区毛片| 免费中文日韩| 午夜免费在线观看精品视频| 伊人狠狠色丁香综合尤物| 欧美激情综合网| 欧美一区综合| 日韩视频免费在线| 免费成人网www| 亚洲中午字幕| 日韩亚洲欧美中文三级| 国产色产综合产在线视频| 欧美精品日韩www.p站| 欧美一区午夜精品| 一本不卡影院| 亚洲激情午夜| 麻豆成人小视频| 亚洲欧美999| 亚洲精品在线二区| 狠狠色狠色综合曰曰| 国产精品免费看| 欧美日本免费一区二区三区| 久久伊人亚洲| 欧美一区二区免费观在线| 一区二区三区精品视频| 亚洲破处大片| 欧美激情一级片一区二区| 久久久精品国产一区二区三区| 夜夜爽www精品| 亚洲人体1000| 一区在线影院| 国产一区二区在线免费观看 | 欧美日韩精品福利| 免费成人黄色片| 久热精品在线| 久久免费99精品久久久久久| 欧美在线观看一区二区三区| 亚洲欧美日韩久久精品| 国产精品99久久久久久有的能看 | 午夜亚洲精品| 香蕉亚洲视频| 欧美一区在线视频| 新67194成人永久网站| 午夜精品一区二区三区在线| 亚洲欧美一区二区三区极速播放| 中文日韩在线| 亚洲欧美激情诱惑| 欧美一区二区免费| 欧美有码视频| 久久亚洲精品视频| 久久人人看视频| 欧美成人免费在线视频| 亚洲成色999久久网站| 亚洲国产精品一区二区久| 亚洲国产日本| 一区二区欧美日韩| 亚洲女女女同性video| 欧美一级片一区| 久久这里有精品视频| 欧美激情aaaa| 国产精品v片在线观看不卡| 国产美女扒开尿口久久久| 国产欧美一区二区精品婷婷| 国产视频在线观看一区| 在线观看日韩av电影| 亚洲精品裸体| 亚洲欧美在线另类| 久久午夜国产精品| 牛夜精品久久久久久久99黑人| 国产日韩欧美在线视频观看| 国产精品久久久久影院亚瑟| 国产欧美日韩高清| 亚洲第一精品久久忘忧草社区| 99爱精品视频| 欧美一区二区三区四区夜夜大片| 久久久九九九九| 亚洲国产精品第一区二区三区| 一区二区欧美在线| 久久深夜福利| 国产精品久久久久永久免费观看 | 日韩视频免费大全中文字幕| 亚洲欧美国产精品桃花| 欧美va亚洲va日韩∨a综合色| 亚洲精品久久久久久下一站 | 裸体一区二区三区| 国产精品福利av| 亚洲国产精品一区在线观看不卡| 亚洲视频图片小说| 老鸭窝91久久精品色噜噜导演| 亚洲精品自在久久| 久久久国产一区二区三区| 欧美视频一区| 亚洲经典三级| 久久久免费av| 亚洲婷婷综合色高清在线| 免费成人av| 黄色日韩精品| 午夜欧美不卡精品aaaaa| 91久久视频| 久久久综合激的五月天| 国产精品青草久久| 一区二区三区精品国产| 欧美成人一二三| 久久久久久久999| 国产视频久久久久| 亚洲一区二区在|