久久亚洲熟女cc98cm,精品国产99久久久久久麻豆,欧美精品乱码99久久蜜桃

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

名稱	State
結構
意圖	允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它的類。
適用性	一個對象的行為取決于它的狀態, 并且它必須在運行時刻根據狀態改變它的行為。一個操作中含有龐大的多分支的條件語句，且這些分支依賴于該對象的狀態。這個狀態通常用一個或多個枚舉常量表示。通常, 有多個操作包含這一相同的條件結構。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();

?????? // ?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

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 回復更多評論

刷新評論列表

只有注冊用戶登錄后才能發表評論。
【推薦】100%開源！大型工業跨平臺軟件C++源碼提供，建模，組態！

相關文章: 本博客所有精華隨筆索引策略模式（policy）設計模式隨筆分類 MFC與設計模式接口模式 -- 接口中為什么不能包含delegate .net中更好的使用設計模式的DLL(Commonly Used .NET Coding Patterns in CodeDom)(轉) 模式設計c#－－行為型－－visitor 模式設計c#－－行為型－－strategy 模式設計c#－－行為型－－state 模式設計c#－－行為型－－observer

網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

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

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

C++ Programmer's Cookbook

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

所有的state應該被一個類（State Manager Class）管理:

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

state應該實現為一個singleton:

應該做一個state么？這是一個問題：

例如：

評論

公告

導航

統計

常用鏈接

隨筆分類

隨筆檔案

收藏夾

Blogs

c#(csharp)

C++(cpp)

Enlish

Forums(bbs)

My self

Often go

Useful Webs

Xml/Uml/html

搜索

積分與排名

最新評論

閱讀排行榜