遊戲開發中常用的設計模式
使用設計模式來提高程序庫的重復利用性是大型程序項目開發必須的。但是在“四人幫”的設計模式概述中提到了23種標準設計模式，不但難以記住，而且有些設計模式更多的適用於應用程序開發，對遊戲項目引擎設計並沒有很多的利用價值。根據經驗，精挑細選後，篤誌在這裏記錄一些自認為有利用價值的設計模式，以便之後自己設計時使用。
一：觀察者Observer
觀察者的設計意圖和作用是： 它將對象與對象之間創建一種依賴關系，當其中一個對象發生變化時，它會將這個變化通知給與其創建關系的對象中，實現自動化的通知更新。
遊戲中觀察者的適用環境有：
1：UI控件管理類。當我們的GUI控件都使用觀察者模式後，那麽用戶的任何界面相關操作和改變都將會通知其關聯對象-----我們的UI事件機。
2：動畫管理器。很多時候我們在播放一個動畫楨的時候，對其Frame有很大興趣，此時我們設置一個FrameLister對象對其進行監視，獲得我們關心的事件進行處理是必須的。
觀察者偽代碼：
// 被觀察對象目標類 Class Subject { // 對本目標綁定一個觀察者 Attach( Observer ); // 解除一個觀察者的綁定 DeleteAttach( Observer ); // 本目標發生改變了，通知所有的觀察者，但沒有傳遞改動了什麽 Notity() { For ( …遍歷整個ObserverList …) { pObserver->Update(); } } // 對觀察者暴露的接口，讓觀察者可獲得本類有什麽變動GetState(); } //------------------------------------------------------------------------------------------------------- // 觀察者/監聽者類 Class Observer { // 暴露給對象目標類的函數，當監聽的對象發生了變動，則它會調用本函數通知觀察者 Void Update () { pSubject->GetState(); // 獲取監聽對象發生了什麽變化 TODO：DisposeFun(); // 根據狀態不同，給予不同的處理 } }
非程序語言描述：
A是B的好朋友，對B的行為非常關心。B要出門，此時A給了B一個警報器，告訴B說：“如果你有事，立刻按這個警報器告訴我。”。結果B在外面遇上了麻煩，按下警報器（Update()），B就知道A出了事，於是就調查一下B到底遇到了什麽麻煩(GetState())，當知道B原來是因為被人打了，於是立刻進行處理DisposeFun()，派了一群手下幫B打架。
當然關心A的人可以不止一個，C，D可能也對A很關心，於是A這裏保存一個所有關心它的人的鏈表，當遇到麻煩的時候，輪流給每個人一份通知。
二：單件模式Singleton
單件模式的設計意圖和作用是： 保證一個類僅有一個實例，並且，僅提供一個訪問它的全局訪問點。
遊戲中適用於單件模式的有：
1：所有的Manger。在大部分的流行引擎中都存在著它的影子，例如SoundManager, ParticeManager等。
2：大部分的工廠基類。這一點在大部分引擎中還是見不到的，實際上，我們的父類工廠采用唯一實例的話，我們子類進行擴展時也會有很大方便。
單件模式偽代碼：
Class Singleton { Static MySingleton; // 單件對象，全局唯一的。 Static Instance(){ return MySingleton;} // 對外暴露接口 }
三：叠代器Iterator
叠代器設計意圖和作用是： 提供一個方法，對一個組合聚合對象內各個元素進行訪問，同時又不暴露該對象類的內部表示。
遊戲中適用於叠代器模式的有： 因為STL的流行，這個設計已經廣為人知了，我們對任何形式的資源通一管理時，不免會將其聚合起來，或者List，或者Vector，我們都需要一個對其進行訪問的工具，叠代器無疑是一個利器。
叠代器偽代碼：
// 叠代器基類 Class Iterator { Virtual First(); Virtual Next(); Virtual End(); Virtual CurrentItem(); // 返回當前Item信息 } //----------------------------------------------------------------------------------- // 聚合體的基類 Class ItemAggregate { Virtual CreateIterator(); // 創建訪問自身的一個叠代器 } //----------------------------------------------------------------------------------- // 實例化的項目聚合體 Class InstanceItemAggregate : public ItemAggregate { CreateIterator(){ return new InstanceIterator(this); } }
四：訪問者模式Visitor：
訪問者設計意圖和作用是： 當我們希望對一個結構對象添加一個功能時，我們能夠在不影響結構的前提下，定義一個新的對其元素的操作。（實際上，我們只是把對該元素的操作分割給每個元素自身類中實現了而已）
遊戲中適用於訪問者模式的有： 任何一個比較靜態的復雜結構類中都適合采用一份訪問者。這裏的“比較靜態的復雜結構類”意思是，該結構類中元素繁多且種類復雜，且對應的操作較多，但類很少進行變化，我們就能夠將，對這個結構類元素的操作獨立出來，避免汙染這些元素對象。
1：例如場景管理器中管理的場景節點，是非常繁多的，而且種類不一，例如有Ogre中的Root, Irrchit中就把攝象機，燈光，Mesh，公告版，聲音都做為一種場景節點，每個節點類型是不同的，雖然大家都有共通的Paint(),Hide()等方法，但方法的實現形式是不同的，當我們外界調用時需要統一接口，那麽我們很可能需要需要這樣的代碼
Hide( Object )
{ if (Object == Mesh) HideMesh(); if (Object == Light) HideLight(); … }
此時若我們需要增加一個Object新的類型對象，我們就不得不對該函數進行修正。而我們可以這樣做，讓Mesh,Light他們都繼承於Object,他們都實現一個函數Hide(),那麽就變成
Mesh::Hide( Visitor ) { Visitor.Hide (Mesh); }
Light::Hide(Visitor ){ Visitor.Hide (Light); }
我們在調用時只需要Object.Hide(Visitor){ return Visitor.Hide(Object); }
這樣做的好處，我們免去了對重要函數的修正，Object.Hide(Visitor){}函數我們可以永久不變，但是壞處也是很明顯的，因為將方法從對象集合結構中抽離出來，就意味著我們每增加一個元素，它必須繼承於一個抽象的被訪問者類，實現其全部函數，這個工作量很大。
所以，訪問者是僅適合於一個裝載不同對象的大容器，但同時又要求這個容器的元素節點不應當有大的變動時才使用。另外，廢話一句，訪問者破壞了OO思想的。
訪問者偽代碼：
// 訪問者基類 Class Visitor { Virtual VisitElement( A ){ … }; // 訪問的每個對象都要寫這樣一個方法 Virtual VisitElement( B ){ … }; } // 訪問者實例A Class VisitorA { VisitElement( A ){ … }; // 實際的處理函數 VisitElement( B ){ … }; // 實際的處理函數 } // 訪問者實例B Class VisitorB { VisitElement( A ){ … }; // 實際的處理函數 VisitElement( B ){ … }; // 實際的處理函數 } // 被訪問者基類 Class Element { Virtual Accept( Visitor ); // 接受訪問者 } // 被訪問者實例A Class ElementA { Accecpt( Visitor v ){ v-> VisitElement(this); }; // 調用註冊到訪問者中的處理函數 } // 被訪問者實例B Class ElementB { Accecpt( Visitor v ){ v-> VisitElement(this); }; // 調用註冊到訪問者中的處理函數 }
五：外觀模式Facade
外觀模式的設計意圖和作用是： 將用戶接觸的表層和內部子集的實現分離開發。實際上，這個模式是個紙老虎，之後我們看偽代碼立刻就會發現，這個模式實在用的太頻繁了。
遊戲中需要使用外觀模式的地方是： 這個非常多了，舉幾個比較重要的。
1：實現平臺無關性。跨平臺跨庫的函數調用。
2：同一個接口去讀取不同的資源。
3：硬件自動識別處理系統。
外觀模式偽代碼
// 用戶使用的接口類 Class Interface { // 暴露出來的函數接口函數，有且僅有一個，但內部實現是調用了兩個類 Void InterfaceFun() { // 根據某種條件，底層自主的選擇使用A或B的方法。用戶無須關心底層實現 If ( XXX ) { ActualA->Fun(); } Else { ActualB->Fun(); } }; } // 實際的實現，不暴露給用戶知道 Class ActualA { Void Fun(); } // 實際的實現，不暴露給用戶知道 Class ActualB { Void Fun(); }
怎麽樣，紙老虎吧，看起來很高深摸測的命名而已。
六：抽象工廠模式AbstractFactory
抽象工廠的設計意圖和作用是： 封裝出一個接口，這個接口負責創建一系列互相關聯的對象，但用戶在使用接口時不需要指定對象所在的具體的類。從中文命名也很容易明白它是進行批量生產的一個生產工廠的作用。
遊戲中使用抽象工廠的地方有： 基本上任何有批量的同類形式的子件地方就會有工廠的存在。（補充一句：下面代碼中的ConcreteFactory1實例工廠就是工廠，而抽象工廠僅僅是工廠的一個抽象層而已。）
1：例如，在音頻方面，一個音頻的抽象工廠派生出不同的工廠，有音樂工廠，音效工廠。音效工廠中又有一個創建3D音效節點的方法，一個創建普通音效節點的方法。最終用戶只需要SoundFactory->Create3DNode( pFileName );就可以創建一個節點了。
2：場景對象。
3：渲染對象。
4：等等……
工廠與單件，管理器Manager關系一定是非常緊密的。
抽象工廠偽代碼：
class AbstractProductA {}; // 抽象的產品A基類 class AbstractProductB {}; //抽象的產品B基類 // 抽象工廠基類 class AbstractFactory { public: virtual AbstractProductA* CreateProductA() = 0 ;// 創建ProductA virtual AbstractProductB* CreateProductB() = 0 ;// 創建ProductB } ; class ProductA1 : public AbstractProductA {}; // 產品A的實例1 class ProductA2 : public AbstractProductA {}; // 產品A的實例2 class ProductB1 : public AbstractProductB {}; // 產品B的實例1 class ProductB2 : public AbstractProductB {}; // 產品B的實例2 // 實例工廠1 class ConcreteFactory1 : public AbstractFactory { virtual AbstractProductA* CreateProductA() { return new ProductA1() ; } virtual AbstractProductB* CreateProductB() { return new ProductB1() ; } static ConcreteFactory1* Instance() { } // 實例工廠盡量使用單件模式 } ; // 實例工廠2 class ConcreteFactory2 : public AbstractFactory { virtual AbstractProductA* CreateProductA() { return new ProductA2() ; } virtual AbstractProductB* CreateProductB() { return new ProductB2() ; } static ConcreteFactory2* Instance() {} // 實例工廠盡量使用單件模式 } ; }
客戶端代碼：
Void main() { AbstractFactory *pFactory1 = ConcreteFactory1::Instance() ; AbstractProductA *pProductA1 = pFactory1->CreateProductA() ; AbstractProductB *pProductB1 = pFactory1->CreateProductB() ; AbstractFactory *pFactory2 = ConcreteFactory2::Instance() ; AbstractProductA *pProductA2 = pFactory2->CreateProductA() ; AbstractProductB *pProductB2 = pFactory2->CreateProductB() ; }
遊戲開發中常用的設計模式