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

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模式。
狀態模式則有所不同,她實現的一個概念可以叫做動態繼承,也就是繼承的子類(每一個狀態)可以發生變化。這些狀態的變化是一個整體,組成了一個狀態變化圖。而一般來說,使用該模式的狀態之間存在著一種線性變化的關系,也就是一個狀態變為另一個,然后是第三個??蛻舸a并不清楚這些狀態在何時發生變化,這樣做的好處是在組成你整個變化過程中某些狀態之間需要插入一個新的狀態,或者狀態的順序之間發生變化,對客戶是不可見。實現模式一方面,修改的也只是相領的狀態。在處于不同的狀態時,客戶代碼可以執行的方法也是不同的。但它的問題就是必須在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

搜索

  •  

積分與排名

  • 積分 - 1811981
  • 排名 - 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>
              亚洲综合视频一区| 亚洲国产小视频在线观看| 亚洲乱码精品一二三四区日韩在线 | 国产精品国产三级国产专播品爱网| 日韩视频第一页| 亚洲美女淫视频| 国产精品v欧美精品v日韩| 亚洲一区日韩在线| 亚洲综合导航| 永久免费视频成人| 亚洲激情成人| 国产精品香蕉在线观看| 久久久99精品免费观看不卡| 久久一区视频| 亚洲婷婷综合久久一本伊一区| 亚洲主播在线| 亚洲承认在线| 国产精品乱码| 日韩视频亚洲视频| 一区二区高清在线观看| 国产乱码精品1区2区3区| 狂野欧美激情性xxxx欧美| 你懂的视频欧美| 亚洲欧美电影院| 久久久精品午夜少妇| 在线视频欧美一区| 性欧美暴力猛交另类hd| 亚洲乱码一区二区| 亚洲欧美日韩久久精品 | 欧美精品一区二区三区一线天视频| 中文欧美日韩| 久久香蕉国产线看观看网| 亚洲无限av看| 欧美黄污视频| 久久久久免费| 国产精品日产欧美久久久久| 欧美国产日韩一区二区| 国产精自产拍久久久久久蜜| 亚洲国产欧美一区二区三区同亚洲 | 亚洲免费高清| 久久国产精品电影| 亚洲欧美日韩在线观看a三区| 久久中文字幕一区| 久久xxxx精品视频| 欧美午夜精品伦理| 亚洲经典三级| 亚洲国产成人精品久久| 午夜激情综合网| 亚洲视频中文| 欧美久久久久免费| 欧美高清视频一二三区| 韩日视频一区| 久久精品国产清自在天天线| 性欧美18~19sex高清播放| 欧美日韩精品二区第二页| 欧美黄色一区二区| 在线观看欧美视频| 久久久久久久国产| 久久久精品网| 国产一区二区中文字幕免费看| 99视频在线精品国自产拍免费观看| 91久久精品国产91久久性色| 久久美女艺术照精彩视频福利播放| 久久精品视频在线看| 国产欧美日本在线| 午夜亚洲激情| 久久久久久伊人| 韩日成人av| 久久婷婷人人澡人人喊人人爽| 久久精品国产亚洲一区二区| 国产情人节一区| 欧美与黑人午夜性猛交久久久| 久久精品免费| 一区二区亚洲精品国产| 久久综合一区二区| 亚洲高清一二三区| 欧美怡红院视频| 一本色道久久99精品综合| 欧美极品一区| 亚洲深夜福利在线| 久久精品91久久久久久再现| 黑人巨大精品欧美一区二区| 久久精品国产免费看久久精品 | 亚洲第一天堂无码专区| 榴莲视频成人在线观看| 亚洲三级视频| 午夜精品久久久久久久99热浪潮 | 亚洲精品乱码久久久久久黑人 | 亚洲欧美激情四射在线日| 欧美一区日本一区韩国一区| 国产日韩一区欧美| 久久综合电影一区| 亚洲精品裸体| 欧美一区二区三区四区在线观看地址| 国产精品永久入口久久久| 久久久精品一区| 91久久久久久久久| 欧美一区二区三区在线观看视频| 国内精品免费在线观看| 欧美极品欧美精品欧美视频| 在线亚洲高清视频| 免费亚洲视频| 亚洲欧美成aⅴ人在线观看| 国内一区二区三区| 欧美日韩国产成人| 久久国产综合精品| 日韩一级黄色av| 麻豆成人av| 亚洲一区精品视频| 亚洲福利在线视频| 国产免费成人av| 欧美精品免费播放| 久久久不卡网国产精品一区| 亚洲精品久久视频| 看片网站欧美日韩| 午夜日韩视频| 一本大道久久精品懂色aⅴ| 国产在线精品二区| 国产精品成人观看视频免费| 老司机免费视频一区二区| 亚洲一区二区三区四区五区午夜 | 久热国产精品| 香蕉久久精品日日躁夜夜躁| 亚洲黄页一区| 欧美成人精品一区| 久久人体大胆视频| 欧美一区二区三区婷婷月色| 99在线视频精品| 亚洲国产视频a| 狠狠色狠狠色综合日日小说| 国产精品久久久| 欧美黄色免费网站| 欧美 亚欧 日韩视频在线| 欧美在线免费观看| 亚洲欧美综合v| 亚洲综合电影| 亚洲制服丝袜在线| 亚洲欧美激情视频在线观看一区二区三区 | 国产区欧美区日韩区| 久久激情综合网| 欧美一级艳片视频免费观看| 亚洲一区二区伦理| 亚洲香蕉成视频在线观看| 在线一区二区三区四区| 在线视频你懂得一区| 一区二区三区精品视频| 一区二区黄色| 亚洲一区二区久久| 亚洲欧美另类国产| 先锋资源久久| 久久久水蜜桃av免费网站| 久久先锋资源| 欧美精品久久久久久久久久| 欧美精品手机在线| 欧美午夜电影完整版| 国产精品美女主播在线观看纯欲| 欧美性猛交xxxx乱大交蜜桃| 国产精品久久久久久妇女6080| 国产精品高清在线| 国产一区二区三区电影在线观看| 国产婷婷色综合av蜜臀av| 狠狠v欧美v日韩v亚洲ⅴ| 亚洲成色www8888| 日韩亚洲欧美一区| 亚洲欧美日韩直播| 久久久美女艺术照精彩视频福利播放| 久久亚洲午夜电影| 亚洲国产免费看| 亚洲网站视频| 久久在线视频| 欧美日韩免费看| 国产欧美亚洲日本| 最新中文字幕亚洲| 亚洲自拍偷拍麻豆| 久久综合给合久久狠狠色| 亚洲国产精品久久久久婷婷老年| 亚洲美女免费精品视频在线观看| 亚洲一区中文字幕在线观看| 久久精品国产免费看久久精品| 欧美成黄导航| 国产毛片一区二区| 亚洲美女色禁图| 久久成人综合视频| 亚洲黄色成人网| 欧美亚洲自偷自偷| 欧美日韩另类丝袜其他| 国产一区三区三区| 一本久道久久综合狠狠爱| 久久久免费av| 中文精品视频| 蜜桃av综合| 国产亚洲日本欧美韩国| 99国产精品99久久久久久粉嫩 | 精品999网站| 亚洲制服欧美中文字幕中文字幕| 蜜桃伊人久久| 香蕉免费一区二区三区在线观看| 欧美日本一区二区三区| 在线播放豆国产99亚洲| 欧美亚洲综合网|