Posted on 2011-01-19 17:11
點點滴滴 閱讀(898)
評論(0) 編輯 收藏 引用 所屬分類:
10 服務器
有關State模式的設計意圖及實現就不從設計模式中摘抄了，我們只來看看游戲服務器編程中如何使用State設計模式。
首先還是從mangos的代碼開始看起，我們注意到登錄服在處理客戶端發來的消息時用到了這樣一個結構體：
struct AuthHandler
{
eAuthCmd cmd;
uint32 status;
bool (AuthSocket::*handler)(void);
};
該結構體定義了每個消息碼的處理函數及需要的狀態標識，只有當前狀態滿足要求時才會調用指定的處理函數，否則這個消息碼的出現是不合法的。這個status狀態標識的定義是一個宏，有兩種有效的標識，STATUS_CONNECTED和STATUS_AUTHED，也就是未認證通過和已認證通過。而這個狀態標識的改變是在運行時進行的，確切的說是在收到某個消息并正確處理完后改變的。
我們再來看看設計模式中對State模式的說明，其中關于State模式適用情況里有一條，當操作中含有龐大的多分支的條件語句，且這些分支依賴于該對象的狀態，這個狀態通常用一個或多個枚舉變量表示。
描述的情況與我們這里所要處理的情況是如此的相似，也許我們可以試一試。那再看看State模式提供的解決方案是怎樣的，State模式將每一個條件分支放入一個獨立的類中。
由于這里的兩個狀態標識只區分出了兩種狀態，所以，我們僅需要兩個獨立的類，用以表示兩種狀態即可。然后，按照State模式的描述，我們還需要一個Context類，也就是狀態機管理類，用以管理當前的狀態類。稍作整理，大概的代碼會類似這樣：
狀態基類接口：
StateBase
{
void Enter() = 0;
void Leave() = 0;
void Process(Message* msg) = 0;
};
狀態機基類接口：
MachineBase
{
void ChangeState(StateBase* state) = 0;
StateBase* m_curState;
};
我們的邏輯處理類會從MachineBase派生，當取出數據包后交給當前狀態處理，前面描述的兩個狀態類從StateBase派生，每個狀態類只處理該狀態標識下需要處理的消息。當要進行狀態轉換時，調用MachineBase的ChangeState()方法，顯示地告訴狀態機管理類自己要轉到哪一個狀態。所以，狀態類內部需要保存狀態機管理類的指針，這個可以在狀態類初始化時傳入。具體的實現細節就不做過多描述了。
使用狀態機雖然避免了復雜的判斷語句，但也引入了新的麻煩。當我們在進行狀態轉換時，可能會需要將一些現場數據從老狀態對象轉移到新狀態對象，這需要在定義接口時做一下考慮。如果不希望執行拷貝，那么這里公有的現場數據也可放到狀態機類中，只是這樣在使用時可能就不那么優雅了。
正如同在設計模式中所描述的，所有的模式都是已有問題的另一種解決方案，也就是說這并不是唯一的解決方案。放到我們今天討論的State模式中，就拿登錄服所處理的兩個狀態來說，也許用mangos所采用的遍歷處理函數的方法可能更簡單，但當系統中的狀態數量增多，狀態標識也變多的時候，State模式就顯得尤其重要了。