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