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

C++ Programmer's Cookbook

{C++ 基礎(chǔ)} {C++ 高級(jí)} {C#界面,C++核心算法} {設(shè)計(jì)模式} {C#基礎(chǔ)}

模式設(shè)計(jì)c#--行為型--state

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

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

????}

}


設(shè)計(jì)模式:關(guān)于State模式的一些需要注意的地方

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

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

這個(gè)模式使得操作的state邏輯更加的清楚,省去了無(wú)數(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 )來(lái)統(tǒng)一的管理這些state的切換,例如目標(biāo)state的初始化和申請(qǐng)?zhí)D(zhuǎn)state的結(jié)束處理,以及一些state間共享數(shù)據(jù)的存儲(chǔ)和處理。與其稱這個(gè)Manager 為管理類,不如說(shuō)是一個(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來(lái)管理,那么自然的,這些state都應(yīng)該從一個(gè)父類繼承下來(lái),這樣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è)問(wèn)題:

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

    例如:

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

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

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

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

    就可以,從而避免了state過(guò)多出現(xiàn)的問(wè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 );
????}

??}

}
?

?

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

評(píng)論

# re: 模式設(shè)計(jì)c#--行為型--state 2006-04-25 14:33 夢(mèng)在天涯

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

# re: 模式設(shè)計(jì)c#--行為型--state 2006-04-30 18:39 cxvcx

zxcxzc  回復(fù)  更多評(píng)論   

公告

EMail:itech001#126.com

導(dǎo)航

統(tǒng)計(jì)

  • 隨筆 - 461
  • 文章 - 4
  • 評(píng)論 - 746
  • 引用 - 0

常用鏈接

隨筆分類

隨筆檔案

收藏夾

Blogs

c#(csharp)

C++(cpp)

Enlish

Forums(bbs)

My self

Often go

Useful Webs

Xml/Uml/html

搜索

  •  

積分與排名

  • 積分 - 1816190
  • 排名 - 5

最新評(píng)論

閱讀排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
              99国产成+人+综合+亚洲欧美| 久久久成人精品| 黑人巨大精品欧美一区二区| 欧美精品v国产精品v日韩精品| 亚洲淫片在线视频| 亚洲福利视频二区| 久久国产一二区| 亚洲欧美www| 亚洲乱码国产乱码精品精天堂 | 亚洲黄色av一区| 国产免费亚洲高清| 欧美日韩中文字幕在线视频| 免费在线欧美黄色| 久久乐国产精品| 欧美一区二区三区免费在线看| 夜夜爽av福利精品导航| 亚洲国产欧美不卡在线观看| 美日韩精品免费观看视频| 欧美一区二区高清| 亚洲一区国产一区| 亚洲视频综合| 在线亚洲免费视频| 一本色道久久综合亚洲精品高清 | 韩国视频理论视频久久| 国产精品卡一卡二卡三| 欧美日韩高清免费| 欧美精品成人一区二区在线观看| 久久蜜桃精品| 久久色中文字幕| 久久久国产一区二区| 性欧美办公室18xxxxhd| 亚洲欧美在线aaa| 亚洲免费网址| 羞羞视频在线观看欧美| 亚洲欧美偷拍卡通变态| 亚洲欧美日韩在线一区| 亚洲一区二区三区乱码aⅴ蜜桃女| 日韩视频免费在线| 99热这里只有精品8| 99国内精品久久| 亚洲美女精品久久| 亚洲免费高清视频| 这里只有精品丝袜| 亚洲主播在线| 欧美一区影院| 久久久无码精品亚洲日韩按摩| 久久男人资源视频| 欧美成人国产va精品日本一级| 欧美电影免费观看网站| 欧美日韩成人综合| 欧美午夜久久| 国产老女人精品毛片久久| 国产一区二区三区免费在线观看| 国产视频久久久久| 揄拍成人国产精品视频| 亚洲精品乱码久久久久久蜜桃91| 亚洲美女免费精品视频在线观看| 国产精品99久久99久久久二8 | 欧美亚州一区二区三区 | 欧美一区二区三区精品| 久久精品国产视频| 欧美va天堂| 亚洲免费黄色| 欧美一级片一区| 男人插女人欧美| 欧美视频导航| 韩国一区电影| 日韩亚洲不卡在线| 午夜精品久久久久久久蜜桃app| 久久久91精品国产| 亚洲国产日日夜夜| 国产精品99久久久久久久久| 久久大逼视频| 欧美精品综合| 国产视频在线观看一区| 最新日韩在线视频| 亚洲欧美自拍偷拍| 欧美1区视频| 中日韩在线视频| 久久天天躁夜夜躁狠狠躁2022| 欧美日本一区| 娇妻被交换粗又大又硬视频欧美| 一区二区免费在线观看| 久久在线精品| 国产精品99久久久久久白浆小说| 久久亚洲一区| 国产麻豆91精品| 日韩午夜在线观看视频| 久久午夜国产精品| 在线中文字幕一区| 欧美va天堂| 国语对白精品一区二区| 亚洲一区二区三区激情| 欧美不卡激情三级在线观看| 亚洲欧美精品中文字幕在线| 欧美精品九九| 亚洲电影下载| 久久爱91午夜羞羞| 99视频超级精品| 免费毛片一区二区三区久久久| 国产精品美女久久久久aⅴ国产馆| 亚洲国产美女久久久久| 久久精品亚洲一区二区| 一区二区三区高清在线| 欧美成人一区二区三区| 韩国一区二区三区在线观看| 亚洲一区三区电影在线观看| 欧美成人免费观看| 欧美影院成年免费版| 国产精品久久夜| 夜夜嗨一区二区| 亚洲国产日韩欧美在线动漫| 久久婷婷成人综合色| 国产欧美日韩另类视频免费观看| 一卡二卡3卡四卡高清精品视频| 欧美激情精品久久久久久黑人| 久久超碰97人人做人人爱| 国产日产精品一区二区三区四区的观看方式 | 国产精品高清一区二区三区| 亚洲精品免费电影| 欧美成人免费一级人片100| 久久精品国产69国产精品亚洲| 国产精品网站在线播放| 亚洲综合色激情五月| 日韩一级在线观看| 欧美精品国产一区| 亚洲靠逼com| 亚洲欧洲一区二区三区久久| 麻豆成人综合网| 亚洲国产精品毛片| 欧美大学生性色视频| 麻豆精品在线播放| 亚洲国产日韩一区二区| 欧美激情第五页| 欧美成人精品不卡视频在线观看| 亚洲欧洲精品一区二区三区| 亚洲国产精品黑人久久久| 欧美国产91| 99视频一区二区| 日韩亚洲欧美高清| 欧美图区在线视频| 午夜视频在线观看一区二区三区 | 狠狠色噜噜狠狠狠狠色吗综合| 久久久久国产精品厨房| 久久国产天堂福利天堂| 激情亚洲成人| 欧美超级免费视 在线| 欧美va亚洲va香蕉在线| 日韩视频免费| 日韩一级网站| 国产精品国产亚洲精品看不卡15| 亚洲欧美自拍偷拍| 亚洲一区二区三区777| 国产亚洲va综合人人澡精品| 老司机久久99久久精品播放免费| 免费中文字幕日韩欧美| 99这里只有精品| 亚洲一区二区成人在线观看| 狠狠色综合网站久久久久久久| 欧美高清在线一区| 欧美视频在线免费| 久久精品三级| 欧美91精品| 亚洲欧美国产精品桃花| 久久久国产精品一区二区三区| 亚洲国产成人av好男人在线观看| 亚洲精品三级| 国产午夜精品全部视频在线播放 | 亚洲欧美另类在线| 在线精品视频一区二区| 亚洲日本va午夜在线影院| 国产农村妇女毛片精品久久麻豆| 你懂的视频欧美| 国产精品高潮呻吟久久| 久久躁狠狠躁夜夜爽| 欧美日韩国产三级| 久久久午夜电影| 欧美日韩精品一本二本三本| 久久久久久久999精品视频| 欧美激情一区二区三区在线视频| 性久久久久久久久| 免费在线亚洲| 久久精品色图| 欧美性猛交99久久久久99按摩| 美女日韩欧美| 国产精品丝袜xxxxxxx| 欧美韩日亚洲| 国产一区二区三区四区三区四| 亚洲三级影院| 亚洲第一精品影视| 午夜精品福利在线| 在线午夜精品自拍| 久热爱精品视频线路一| 欧美一区二视频| 欧美视频中文字幕在线| 欧美不卡高清| 国产综合色在线| 亚洲一区二区高清| 99亚洲精品| 狂野欧美一区|