Strategy Pattern

身為一位程式設計者，你是否曾面臨條件判斷式繁殖過盛的困擾？經常用折疊不完的 N 層 if-else 結構來考驗自己的腦力？或是只能瞪著超過 500 行的 switch-case 條件判斷式舉手投降？您的困擾我瞭解，請容許我向您引薦本篇文章的雙主打星——Strategy 與 State 範式，讓它們帶領我們一同邁向美妙動人的範式之道吧！

首先要瞭解的是，為什麼要將 Strategy 與 State 範式放在同一篇文章裡介紹？因為兩者雖然在設計層面的動機與出發點有所差異，但是在實際的應用面中非常地相近。根據《物件導向設計模式》(Design Patterns) 書中的定義，只要將右圖中的 Strategy、ConcreteStrategyA 與 ConcreteStrategyB 角色，更改為 State、ConcreteStateA 與 ConcreteStateB，就會變成 State 範式的結構圖，可以說兩者就像是孿生兄弟般密切相關。

如果真的要區分出 Strategy 與 State 範式之間的差異，可以參考《重構——向範式前進》中論述的內容：

State pattern 對「必須在一整族 state classes 的實體之間輕鬆轉換」的 class 有益，而 Strategy pattern 則是有助於讓 class 把演算法執行任務委託給「一整族 Strategy classes 的某一個實體」。

從我理解的角度來解釋，Strategy 範式比較著重於包裝相同派系的演算法，而 State 範式則特別注重在各狀態之間的轉換邏輯。所以只要瞭解 Strategy 或 State 範式兩者之一，就等於學會了兩種設計模式，真的是太划算太值得啦！雖然 Strategy 與 State 範式非常單純而且易於理解，但這兩項看似不起眼的小小範式，卻經常能夠在程式系統中發揮很好的應用效果，絕對是程式設計者不可不學的必備基礎知識。本文中將以 Strategy 範式為主，說明兩者在遊戲系統中的相關應用。

如上面的 UML 結構圖所示，Strategy 範式由三種角色的交互作用而生：

• Strategy：制訂出一組共通的介面，使 Context 能夠透過此介面呼叫由 ConcreteStrategy 所實做的演算法。
• ConcreteStrategy：根據 Strategy 所制訂的介面，具體實做出合適的演算法。
• Context：Strategy 的操作者，另可定義介面以供 Strategy 存取自己的資料。

讓我們直接來看看，單純的條件判斷式在遊戲系統中產生的問題，以及 Strategy 範式如何解決問題。

在遊戲系統的程式碼中，特別是與遊戲邏輯相關的部分，經常會面臨需依照各項條件要素，切換不同控制邏輯的情況。以一般的遊戲主迴圈流程為例，多半由偵測鍵盤滑鼠等輸入裝置、更新遊戲世界，以及繪製遊戲世界三項程序組成：

while (m_GameIsRunning) {
	// 處理輸入裝置訊息
	ProcessInput();
	// 更新遊戲邏輯
	Update();
	// 繪製遊戲世界
	Render();
}

但是對於一個完整的遊戲來說，光是區分為上述這三項處理程序，無法完整滿足遊戲中的各種設計需求以及狀態轉換。例如，在剛啟動遊戲時、進入遊戲主選單時，以及遊戲運行中時，可能就會需要三種完全不同的偵測、更新與繪製程序，所以在此可以宣告一些列舉值，用來區分各種遊戲狀態，接著再以 if-else 條件判斷句在處理程序中分項處理：

enum GameState
{
	GameState_Init,
	GameState_Menu,
	GameState_InGame,
};

void ProcessInput()
{
	if (m_State == GameState_Init) {
		// 處理剛啟動遊戲時的輸入偵測邏輯
	}
	else if (m_State == GameState_Menu) {
		// 處理進入遊戲主選單時的輸入偵測邏輯
	}
	else if (m_State == GameState_InGame) {
		// 處理遊戲運行時的輸入偵測邏輯
	}
}

除了 ProcessInput() 函式以外，Update() 與 Render() 函式也以同樣的方法區分成不同的流程控制邏輯。如此一來，只要我們在程式執行的過程中改變 m_State 的數值，當遊戲主迴圈下次進入這三項程序時，自然就會切換至不同的處理流程中了。這樣的程式邏輯看起來完全無害，不是嗎？

但實際上，使用 if-else 敘述句的作法不夠直覺化，有另外一位控制結構的候選者更合適於擔綱這項任務。只要是熟習程式語言基本語法的讀者，應該不難想到可以將上面的 if-else 敘述句，轉換成另外一種作用相同的 switch-case 敘述句：

void ProcessInput()
{
	switch (m_State)	{
		case GameState_Init: {
			// 處理剛啟動遊戲時的輸入偵測邏輯
			break;
		}
		case GameState_Menu: {
			// 處理進入遊戲主選單時的輸入偵測邏輯
			break;
		}
		case GameState_InGame: {
			// 處理遊戲運行時的輸入偵測邏輯
			break;
		}
	}
}

相較於 if-else 敘述句，使用 switch-case 敘述句的優點，在於每個分支選項都會擁有同等的重要性。所以對於程式設計者來說，只要一見到 switch-case，首先就會聚焦在控制變數 m_State 的身上，並且直覺化地理解其中的各項 case 程序，都是具有同等重要性的程式碼。而也正因為 switch-case 比較符合程式設計者的直覺觀感，所以在遊戲系統的程式碼中，switch-case 敘述句也是最常被濫用與誤用的條件判斷式。

當遊戲專案剛啟始，同時整個程式系統仍處於萌芽階段時，使用前述 switch-case 的方法並不會產生任何問題。然而，隨著與日俱增的專案進度與設計需求，程式系統也會無可避免地越來越加錯綜複雜。可能一開始時，程式設計者只是單純想使用一個最簡單明快的方法，以解決切換控制邏輯的需求；然而，隨之而來的程式碼增修幅度，總是遠遠超過原先的預期程度。即使只是偶爾增加個十幾行程式碼，到了專案中後期時，卻有可能使一個小小的 switch-case 敘述句膨脹至 500 行以上的巨型怪物。

為了避免 switch-case 毫無節制地接受程式設計者的餵食，最終成為體態臃腫的大傢伙，我們立即可想到的一項改善方式，就是把原來散落在 case 敘述句中的程式碼，依照功能分門別類，包裝成一個個的中小型函式：

void Update()
{
	switch (m_State)
	{
		case GameState_Init:
		{
			UpdateNetwork();
			UpdateGameWorld();
			UpdatePhysicsEngine();
			UpdateAudioEngine();
			UpdateGraphicsEngine();
			break;
		}
		case GameState_Menu:
		{
			break;
		}
		case GameState_InGame:
		{
			break;
		}
	}
}

有些奉「效能」兩字為最高指導原則的程式設計者，可能會因為遊戲執行效能上的疑慮，而不願意將原來的程式碼包裝成一個個的小型函式。但事實上，這不僅是沒有必要的顧慮，也是一種「過早進行最佳化」的錯誤觀念。在最低限度的情況下，甚至只需要妥善利用 inline 方式來宣告函式，就能夠大幅降低函式呼叫的成本了。

雖然將 case 敘述句中的程式碼分裝處理是個好的開始，但是仍然沒有解決根本上的條件判斷式過多的問題，而且使用 switch-case 敘述句，就像是中了流行性感冒病毒一樣，會不斷地在整個程式系統中傳染擴散開來，讓程式設計者越來越難以擺脫。以上述的幾個分裝函式為例，除了在原有的 Update() 函式中判斷不同的運作條件之外，UpdateNetwork() 是不是同樣也需要進行判斷？還有 UpdateGameWorld()、UpdatePhysicsEngine() 和 UpdateGraphicsEngine() 函式呢？應該也免不了需要切換不同的控制流程吧！

所以，分裝函式最終經常會長出像這樣的程式碼：

void UpdateNetwork()
{
	switch (m_State) {
		case GameState_Init: {
			break;
		}
		case GameState_Menu: {
			break;
		}
		case GameState_InGame: {
			break;
		}
	}
}

void UpdateGameWorld()
{
	switch (m_State)	{
		case GameState_Init: {
			break;
		}
		case GameState_Menu: {
			break;
		}
		case GameState_InGame: {
			break;
		}
	}
}

還有 UpdatePhysicsEngine()、UpdateGraphicsEngine()、UpdateAudioEngine() 和 UpdateOOXX() 等等，到處都是 switch-case 敘述句，想躲也躲不了！

而除了近乎無性繁殖的 switch-case 程式碼以外，更令人頭痛的是，當程式設計者需要加入一項全新的遊戲狀態，例如 GameState_Pause 來控制遊戲暫停時的邏輯運作時，我們必須得回過頭來，前往每一個與 m_State 變數相關的 switch-case 敘述句中，加上一則新的 case 敘述句使 GameState_Pause 狀態能夠正確運作。或許你會認為：「用 Copy-Paste 的方式很快就可以完成，不是嗎？」但是人為干預的動作越多，也就代表疏忽犯錯的可能性越高。

清楚瞭解濫用 if-else 與 switch-case 的種種問題之後，就輪到本篇的英雄主角上場，拯救我們程式設計者的世界啦！為了能夠妥善管理各種不同遊戲狀態之間的運作邏輯，首先可以利用純虛擬函式，宣告一個無法直接具現化的抽象類別 GameState，來扮演最前面所提到的 Strategy 角色：

class GameState
{
public:
	virtual void Update() = 0;
	virtual void Render() = 0;
	virtual void ProcessInput() = 0;
};

將 GameState 宣告為抽象類別，優點在於強制使用者必須自行定義子類別的實做細節，藉此可避免對於 GameState 類別的誤用情形。接著，就可以依照遊戲系統的需求，自 GameState 衍生出一個個獨特的 ConcreteStrategy 角色：

class GameInitState : public GameState
{
public:
	virtual void Update() {
		// 處理剛進入遊戲時的更新程序
	}

	virtual void Render() {
		// 處理剛進入遊戲時的繪製程序
	}

	virtual void ProcessInput() {
		// 處理剛進入遊戲時的輸入偵測程序
	}
};

class GameMenuState : public GameState
{
public:
	virtual void Update() {
		// 處理遊戲主選單的更新程序
	}

	virtual void Render() {
		// 處理遊戲主選單的繪製程序
	}

	virtual void ProcessInput() {
		// 處理遊戲主選單的輸入偵測程序
	}
};

依此方式製作出 GameInitState、GameMenuState 與 GameInGameState 類別後，就可以快樂地和 switch-case 說再見囉！原來的 ProcessInput()、Update() 與 Render() 三項程序就可以修改為：

void ProcessInput()
{
	m_CurrentState->ProcessInput();
}

void Update()
{
	m_CurrentState->Update();
}

void Render()
{
	m_CurrentState->Render();
}

是的，你沒看錯！就這麼容易！先前由一個 m_State 變數以及 switch-case 敘述句控制的條件判斷式，轉換成僅需要一個 m_CurrentState 物件進行操控的程式碼邏輯。程式設計者只需要依條件更換 m_CurrentState 所指向的 ConcreteStrategy 物件，就能夠輕鬆地享受後續的免費服務而無須費心。所以只要我們能夠善加利用 C++ 語言的「虛擬」與「多型」特性，就能夠為程式設計者節省下許多非常珍貴的腦容量與腦細胞，使用在其他更有意義的難題上。

而 Strategy 與 State 範式，不僅能夠用在遊戲主迴圈的流程控制程序中，更可以運用在人工智慧等許多不同的系統中。像遊戲系統中常見的角色狀態機制，同樣也可以利用 State 範式的方式來實作。首先定義好基礎的 State 類別之後，就可以進一步衍生出 IdleState、MoveState、CombatState 等等不同用途的狀態類別：

class Character;

class State
{
public:
	State(Character* context);
};

class IdleState : public State
{
public:
	IdleState(Character* context);
};

class MoveState : public State
{
public:
	MoveState(Character* context);
};

class CombatState : public State
{
public:
	CombatState(Character* context);
};

「萬里長城萬里長～」如同萬里長城般綿延不絕而且橫跨數個頁面的 if-else 或 switch-case 敘述句，絕對是任何一位程式設計者最不願意見到的程式碼結構之一。當你爽快地揮舞著 if-else 與 switch-case 連段 Combo 招式時，請先暫停片刻，冷靜下來想想這樣的做法是否合適？是否有其他方法可以簡化條件判斷式？

另外，如果你習慣於撰寫動輒六、七層以上的條件判斷式深度，不但是在考驗自己的邏輯思考空間，同時也是在殘害程式碼的閱讀者與維護者——而很有可能你自己就是那位可憐的閱讀者與維護者。為了避免寫出深達地底三萬呎的迷宮結構，我們可以多加利用 return、break 敘述句，或者判斷反向的 boolean 值，以減少條件判斷式的巢狀深度。

平時要如何自我檢查是否已經中了條件判斷式的流行性感冒？通常當你發現自己反覆用著 Copy-Paste 在程式碼檔案之間，處理某些「大部分相同而小部分相異」的程式碼時，很可能就是一種濫用條件判斷式的徵兆。請記得，早期發現早期治療的效果最好，否則當程式碼日益增長茁壯，重構的痛苦也會越來越厚重。當你發現自己在兩個地方以上寫著相同的條件判斷式時，可能就是就是 Strategy 與 State 範式該出馬的時候了！

體認完 Strategy 與 State 如何拯救世界之後，最後也該瞭解它們可能產生的副作用。若從效能層面考量，比起單純的 switch-case 敘述句，使用 Strategy 或 State 範式需要一次額外的 virtual table 提領步驟，多少會造成某種程度的效能衝擊。然而，就像之前所提到的「不要過早進行最佳化」，程式設計者應該先以 80/20 法則確認系統的效能瓶頸所在，然後再開始動手改善，才能獲得最佳的優化效益。另外要注意的是，Strategy 與 State 範式並不是任何狀況都適用的銀子彈，如果用在錯誤的地方，將會產生過多小型的物件類別，反而可能降低類別階層的耦合性與內聚力。

只要善加利用 Strategy 與 State 範式，就可以大幅簡化遊戲系統的運作邏輯，使程式碼更加易於閱讀與維護，同時也會變成一種無須太多註解與文件說明，就能夠在程式設計者間達到良好成效的溝通方式。以後再見到 switch-case 敘述句或是準備下手使用之前，不妨先仔細分析一下，想想是否能夠使用 Strategy 或者 State 範式取而代之吧！這樣可以讓你自己也讓其他人過得更快樂唷～

延伸閱讀：

• 《重構——改善既有程式的設計》：
  〈8.15〉以 State/Strategy 取代型別代碼
• 《重構——向範式前進》：
  〈7.2〉以 Strategy 替代條件邏輯
  〈7.4〉以 State 替代「狀態變換」條件句

Prototype，原意為原型或雛形，與工廠模式接收到使用者命令之後即時生產物件的方式不同，在 Prototype 模式中，我們需要先打造出物件的原型樣版，待鑄模程序完成以後，接下來就能夠輕易地以此原型複製產生出全新的物件。複製，也可以是一種生成物件的方法。如 UML 圖所示，在 Prototype 設計模式中，定義了三個參與角色：

• Prototype：宣告自我複製的介面。
• ConcretePrototype：具體實作出自我複製的操作。
• Client：叫原型個體自我複製一份，以生出新的物件。

按照上述的責任關係，程式系統的使用者 Client 只需要指涉到基礎的 Prototype 介面，就能夠以此 Prototype 介面所宣告的 Clone() 方法，複製出類別的物件成品；而 ConcretePrototype 們衍生自 Prototype 介面，是 Client 進行 Operation() 方法後將會獲得的實際成品，所以必須一肩扛起實作 Clone() 內容細節的重責大任。

以遊戲中的角色系統架構為例，可以由角色的基底類別 Actor 扮演上述的 Prototype 角色，而分別衍生自 Actor 類別的 Player 與 Monster 類別則是屬於其中的 ConcretePrototype 角色。只要在 Actor 類別中宣告了 Clone() 介面，再經由 Player 與 Monster 類別實作出 Clone() 方法的細節以後，在遊戲程式中就能夠輕鬆地使用 Actor 類別的 Clone() 介面，複製出所需的玩家物件與怪物物件：

// 創建玩家原型
Player* playerPrototype = new Player();
// 以原型複製方法，產生玩家物件
Actor* playerCloned = playerPrototype->Clone();

// 創建怪物原型，並且設定原型的初始數值
Monster* monsterPrototype = new Monster();
monsterPrototype->SetHP(100);
monsterPrototype->SetMP(50);
monsterPrototype->SetExp(250);
// 以原型複製方法，產生怪物物件
Actor* monster1 = monsterPrototype->Clone();
Actor* monster2 = monsterPrototype->Clone();
Actor* monster3 = monsterPrototype->Clone();

Prototype 設計模式的基本結構與應用概念非常易於理解；然而，使用 Prototype 設計模式的困難之處，就在於如何實作複製方法。

首先，先重溫一下創造物件的其他方法。在物件導向程式設計中，若要達到生成物件的目標，除了以建構式傳入相關參數，或是使用預設建構式創造物件後再進行 Initialize() 或 Setup() 等初始程序以外，還有另外兩個常見的方法：使用複製建構式 (Copy Constructor) 或賦值運算子 (Assignment Operator)。

// 以預設建構式建立 player1 物件
Player player1;
// 以複製建構式建立 player2 物件
Player player2(player1);
// 以賦值運算子將 player2 物件的內容複製給 player1 物件
player1 = player2;

以複製建構式與賦值運算子創建物件的方法，都是藉由已建立完成的物件進行成員資料的複製程序。但是一般來說，由於這兩項方法很容易被使用者誤用而且難以察覺，所以在遊戲程式中，除非有不得不使用的良好理由，否則我們會盡量避免使用複製建構式與賦值運算子的方法，而應該以明確的 Clone() 或者 Copy() 方法清楚標示出複製行為的操作方法，以避免造成誤用的可能性。另外，也可以將類別的複製建構式與賦值運算子宣告為私有成員，就能夠有效禁止這兩項方法的操作行為：

class Player
{
public:
    Player();
    Player(int hp, int mp);

private:
    // 宣告為私有成員，禁止外部程式碼使用
    Player(const Player& p);
    Player& operator=(const Player& p);
};

在談到複製機制時非提不可的議題，就是著名的淺層複製 (Shallow Copy) 與深層複製 (Deep Copy) 問題。簡單來說，淺層複製只會拷貝物件的參考，而深層複製才會完完整整地拷貝物件的一切內容物。對於遊戲系統的應用面來說，如果只有淺層複製機制通常並不足夠；舉個例子來說，如果在 Monster 類別中，內含了一個 Transform 類別用來處理怪物的位移、旋轉與縮放功能，然後我們使用了淺層複製的方式實作 Monster 類別的 Clone() 方法：

Actor* Monster::Clone()
{
    Monster* monster = new Monster();
    monster->SetHP(m_MaxHP);
    monster->SetMP(m_MaxMP);
    monster->SetExp(m_Exp);

    // 將物件指標傳入新建立的 monster 物件中
    monster->SetTransform(m_Transform);

    return monster;
}

如上所示，這樣的複製程序，就等於將所有複製出來的怪物物件與原來的怪物物件，全部指向同一個 Transform 物件，所以只要移動其中一隻怪物的位置，所有的怪物都會跟著位移到相同的位置上。正確的深層複製 Clone() 程序如下：

Actor* Monster::Clone()
{
    Monster* monster = new Monster();
    monster->SetHP(m_MaxHP);
    monster->SetMP(m_MaxMP);
    monster->SetExp(m_Exp);

    // 創建新的 Transform 物件
    Transform* transform = new Transform();
    transform->SetPosition(m_Transform.GetPosition());
    transform->SetRotation(m_Transform.GetRotation());
    transform->SetScale(m_Transform.GetScale());
    // 新的 Monster 物件使用新的 Transform 物件
    monster->SetTransform(transform);

    return monster;
}

只要為類別物件實作出深層複製的 Clone() 方法，就能夠建立出一整組的 Prototype 物件，接下來就可以使用一個 PrototypeManager 類別來管理這些 Prototype 物件。以管理特效原型物件的類別為例：

// @file EffectPrototypeManager.h
#include "Dictionary.h"

class EffectPrototypeManager
{
public:
    Effect* CreateEffect(std::string& fileName)
    {
        Effect* effect = NULL;

        // 先在 Prototypes Pool 中尋找該特效的原型是否存在
        if (!m_PrototypesPool->GetAt(fileName, effect)) {
            // 若不存在，則創建新的特效原型
            effect = new Effect(fileName);
            // 將原型物件存入 Prototypes Pool 中
            m_PrototypesPool->SetAt(fileName, effect);
        }

        // 以原型物件複製產生新的特效物件
        return effect->Clone();
    }

private:
    Dictionary< std::string, Effect*, true >* m_PrototypesPool;
};

在遊戲引擎以及繪圖引擎中，Prototype 設計模式具有相當重要的地位。舉例來說，假設遊戲中的每個技能特效物件，都儲存在個別的實體檔案中，當遊戲需要產生出 10 個相同檔案名稱的特效物件時，是不是表示系統也需要讀取相同的檔案 10 次之多？如果在程式系統中，能夠先建立起這些特效物件的原型，就不需要重複進行開啟檔案與讀取檔案的程序，只要執行一次 I/O 程序，後續的物件就可以全部交由 CPU 進行複製操作。另外，還能夠藉此機制實作出預先載入遊戲資源的功能。

在 Java 與 C# 語言中，都存在著 ICloneable 介面類別，使用者能夠繼承此介面以實作出合適的可複製類別 (Cloneable Class)。但是在 C++ 語言中，並沒有提供類似 ICloneable 介面的機制，因此以 C++ 語言撰寫的遊戲引擎與繪圖引擎，就必須自行打造出適當的 Clone 架構與機制。以 OGRE 繪圖引擎為例，OGRE 目前並沒有符合 Prototype 設計模式的架構與介面，僅有少部分的類別如 Animation、Entity、Material 與 Mesh 等等擁有複製方法；其中，Entity 類別的 clone() 程序如下所示：

// @file OgreEntity.cpp

Entity* Entity::clone(const String& newName) const
{
    Entity* newEnt = mManager->createEntity(newName, getMesh()->getName());

	if (mInitialised) {
		// Copy material settings
		SubEntityList::const_iterator i;
		unsigned int n = 0;
		for (i = mSubEntityList.begin(); i != mSubEntityList.end(); ++i, ++n) {
			newEnt->getSubEntity(n)->setMaterialName((*i)->getMaterialName());
		}

		if (mAnimationState) {
			delete newEnt->mAnimationState;
			newEnt->mAnimationState = new AnimationStateSet(*mAnimationState);
		}
	}

    return newEnt;
}

在之前介紹 OGRE 引擎的文章裡，曾經提到關於資源物件名稱唯一性的問題，所以在 OGRE 中複製物件時，必須傳入一個全新的物件名稱做為複製方法的參數值。如上述程式碼所示，OGRE 的 Entity 類別複製方法是先由 SceneManager 建立出全新的 Entity 物件後，再逐一拷貝 Material 與 AnimationState 物件的設定值。雖然 Entity 類別有提供 clone() 方法，但很可惜的是，更為關鍵重要的 Node 與 SceneNode 類別都沒有提供相對應的 clone() 方法，對於以建構大型遊戲系統為目標的程式設計者來說，將會造成許多資源管理層面的困擾。

在如同 OGRE 般使用 Scene Graph 架構的遊戲引擎或者繪圖引擎裡，大多數遊戲中的物件，都是以 Node 與 Entity 物件層層堆疊連結所建立而成的一棵「樹」。所以對於 Scene Graph 架構的引擎來說，如果要達到深層複製的功能，必須要能夠複製某個 Node 物件底下的整個結構樹；也就是說，除了複製物件本體以外，還需要複製物件的連結性。因此，想要實作出完整的 Clone() 方法，往往不是只用 memcpy() 複製某一區塊的記憶體就能夠單純解決的問題，而必須以遞迴的方式層層向下複製物件的結構與連結關係。

Prototype，就是這樣一個概念簡單而實作細節令人費盡思量的設計模式。如果程式設計者能夠善加利用 Prototype 模式，並且實作出合適的物件複製方法，將能夠為遊戲引擎與遊戲系統帶來很大的助益！

在複雜的軟體系統架構中，將原來雜亂無章的組件加以分門別類，然後從中取出性質相似與功能相近的物件，使其集中群聚，就能夠大幅地簡化程式系統組件的複雜度。而 Abstract Factory 模式，正是用來協助程式設計者將物件分門別類與集中管理的好方法。

Abstract Factory 的「工廠」，與 Factory Method 的「工廠」目的相同，同樣屬於「生成模式」的分類，都是用來產生出物件成品的製造者。對於設計模式的入門者來說，很容易將 Factory Method 模式與 Abstract Factory 模式兩者的使用目的以及使用時機搞混；雖然都是屬於工廠類型的作業模式，然而 Abstract Factory 與 Factory Method 的不同之處在於，抽象工廠模式是將一組性質相關或相依的物件，放在同一個工廠裡生產。例如對於食品工廠來說，能夠生產的包含飲料、零食與泡麵三項食品類的產品；而皮件工廠，則能夠生產出皮包、皮帶與皮鞋等皮製產品。也就是在一個工廠之內有數個不同的生產線，能夠同時進行不同成品的生產作業。在實際程式系統的應用中，可以說 Abstract Factory 經常是一堆 Factory Method 的組合。

以 Abstract Factory 設計模式的 UML 結構圖來看，根據《物件導向設計模式》(Design Patterns) 書中所述，其中定義了參與抽象工廠模式的幾個角色：

• AbstractFactory：此介面宣告出可生成各抽象成品物件的操作。
• ConcreteFactory：具體實作出可建構具象成品物件的操作。
• AbstractProduct：宣告某成品物件類型之介面。
• ConcreteProduct：是 ConcreteFactory 所建構的成品物件；也是 AbstractFactory 介面的具象實作。
• Client：只觸及 AbstractFactory 和 AbstractProduct 兩抽象類別所訂之介面。

與 Factory Method 的結構相似，首先由 AbstractFactory 宣告出創建物件的抽象介面，然後再由繼承而來的子類別 ConcreteFactory 具體實作出對應於各實體成品的操作細節。AbstractProduct 與 ConcreteProduct 之間的關係亦然類似；AbstractProduct 屬於抽象基底產品，而 ConcreteProduct 是衍生而來的實體產品。對於系統外部的使用者 Client 來說，無須瞭解 ConcreteFactory 與 ConcreteProduct 的實作細節，僅需接觸 AbstractFactory 與 AbstractProduct 兩者的介面，就能夠產生出相對應的實體成品。

以常見的遊戲程式情境為例，假設在我們的 MMO 遊戲世界中，存在著三種不同類型的生物體，分別是玩家角色、怪物角色，以及非玩家角色。做為一位聰明的遊戲程式設計者，很自然地能夠將這三個類別的共同概念，抽取出來成為一個基礎的 Actor 父類別。有了 Actor 類別定義一般生物體的基礎屬性與行為後，就能分別衍生出遊戲生物體的三個子類別：玩家角色的 Player 類別、怪物角色的 Monster 類別，以及非玩家角色的 NPC 類別。

在 MMO 遊戲中，Client 端程式需要接收 Server 端程式的指令，才能夠在玩家的電腦中呈現出遊戲的互動世界。所以在 Client 端接收到 Server 端傳送來的指令，命令 Client 端程式要在遊戲世界的某個位置產生某種生物體時，可以這麼寫：

// @file NetworkProtocol.cpp
#include "Player.h"
#include "Monster.h"
#include "NPC.h"

void NetworkProtocol::CreateActor(int _iType, Vector3 _tPos)
{
    Actor* pkActor = NULL;

    if (_iType == 1) {
        pkActor = new Player(_tPos);
    }
    else if (_iType == 2) {
        pkActor = new Monster(_tPos);
    }
    else if (_iType == 3) {
        pkActor = new NPC(_tPos);
    }
    else {
        // Unknown type, Error!
    }

    // Process actor object
}

NetworkProtocol 是用來接受網路命令的類別，其中的 CreateActor() 成員函式專門處理遊戲角色物件的生成程序。在此以一個整數型別數值取決要創建的生物體是玩家、怪物或非玩家角色，是最簡單而直覺的實作方法。

然而如果只是達到這樣的程度，絕對無法令求知若渴的程式設計者得到滿足感。所以為了消除 if 敘述句中使用的萬惡 Magic Number，可以進一步利用 Enumeration 的宣告與 switch 敘述句將程式結構變得更加清楚易懂：

// @file NetworkProtocol.cpp
#include "Player.h"
#include "Monster.h"
#include "NPC.h"

void NetworkProtocol::CreateActor(int _iType, Vector3 _tPos)
{
    enum ActorType
    {
        Actor_Null = 0,
        Actor_Player = 1,
        Actor_Monster = 2,
        Actor_NPC = 3,
    };

    Actor* pkActor = NULL;

    switch (_iType) {
        case Actor_Player: {
            pkActor = new Player(_tPos);
            break;
        }
        case Actor_Monster: {
            pkActor = new Monster(_tPos);
            break;
        }
        case Actor_NPC: {
            pkActor = new NPC(_tPos);
            break;
        }
        default: {
            // Unknown type, Error!
        }
    }

    // Process actor object
}

啊哈！這樣的程式結構是不是看起來清楚許多了？未來如果要加入新類型的生物體，只需要新增一個列舉值，然後在 switch 敘述句中增加對應的 case 結構即可，程式區塊的修改方式也變得更加方便而直覺許多。

然而，即使經過上述的改善程序，已經變得比較易於進行修改與新增的動作，對於這個函式中所產生的 Player、Monster 與 NPC 物件仍然不便於進行集中管理。如果在其他類別中，也需要依參數創建出不同的生物體時，是不是需要把上述的程式碼，照抄一份複製到新的類別成員函式中？萬一不幸又有第三個類別需要進行創建生物體的程序時，就再來一份？如此的情況之下，原來顯而易見的程式結構修改，已經逐漸失去控制了。

利用 Abstract Factory 模式，我們有更好的設計模式與實作方法。在此創建出一個新的 ActorFactory 類別，將產生角色物件程序的實做細節隱藏起來，用以產生各種角色物件：

// @file ActorFactory.h
class Actor;
class Player;
class Monster;
class NPC;

class ActorFactory
{
public:
    ActorFactory();
    virtual ~ActorFactory();

    virtual Player* CreatePlayer(Vector3 _tPos);
    virtual Monster* CreateMonster(Vector3 _tPos);
    virtual NPC* CreateNPC(Vector3 _tPos);
};

將這些相關性很高的類別聚集在同一個工廠中，既能夠達到集中管理的目的，也能夠使未來的系統擴充性更加具有彈性。所以在 ActorFactory 類別的定義中，就能夠對這些物件進行創建的程序：

// @file ActorFactory.cpp
#include "Player.h"
#include "Monster.h"
#include "NPC.h"

Actor* ActorFactory::CreatePlayer(Vector3 _tPos)
{
    return new Player(_tPos);
}

Actor* ActorFactory::CreateMonster(Vector3 _tPos)
{
    return new Monster(_tPos);
}

Actor* ActorFactory::CreateNPC(Vector3 _tPos)
{
    return new NPC(_tPos);
}

需要 Player 物件？沒問題！交給 CreatePlayer() 窗口就對了。需要 Monster 物件呢？那就交給 CreateMonster() 負責。如果是 NPC 物件呢？當然就是屬於 CreateNPC() 的管轄範圍囉。此後不論在程式系統中，有多少不同的類別需要使用創建生物體的程序，都只要向唯一一個 ActorFactory 類別提出要求就可以了！

只要有一項產品，就有相對應的一項操作方法；產品與操作，存在著一對一的對應關係。是不是覺得這個概念有些熟悉？如本文前言所述，在抽象工廠模式中，最常見的做法就是為每一項產品分別定義一個 Factory Method。這裡的程式架構就是利用了這樣的做法，使同一個工廠之中，能夠生產出性質相近但是實體不相同的產品。

更進一步，如果在遊戲系統中，人類與非人類型態的角色，存在著非常大的差異性，並不適合集中於同一個工廠進行管理，就可以將 ActorFactory 類別抽象化，形成一個基底的抽象類別，然後分別衍生出處理人類角色的 HumanActorFactory 工廠類別，以及處理非人類角色的 NonHumanActorFactory 工廠類別：

// @file HumanActorFactory.h
#include "ActorFactory.h"

class HumanActorFactory : public ActorFactory
{
public:
    HumanActorFactory();
    virtual ~HumanActorFactory();

    virtual Player* CreatePlayer(Vector3 _tPos);
    virtual NPC* CreateNPC(Vector3 _tPos);
};

// @file NonHumanActorFactory.h
#include "ActorFactory.h"

class NonHumanActorFactory : public ActorFactory
{
public:
    NonHumanActorFactory();
    virtual ~NonHumanActorFactory();

    virtual Monster* CreateMonster(Vector3 _tPos);
};

於是每次要新增一種新的生物體角色，只要在 ActorFactory 類別中新增一個 CreateXXX() 的虛擬成員函式，然後在對應的實作工廠中定義產品的實作生產細節，就能在妥善分類與集中管理的情形下，得到良好的物件生成系統架構。

為了管理這些物件，非常合適於使用改良版的 STL 容器；以 HumanActorFactory 類別為例，可以在其中新增兩個 Dictionary 用來存放與索引 Player 及 NPC 的物件指標：

// @file HumanActorFactory.h
#include "ActorFactory.h"
#include "Dictionary.h"

class HumanActorFactory : public ActorFactory
{
public:
    HumanActorFactory();
    virtual ~HumanActorFactory();

    virtual Player* CreatePlayer(Vector3 _tPos);
    virtual NPC* CreateNPC(Vector3 _tPos);

private:
    Dictionary< int, Actor*, TRUE >* m_pkPlayersPool;
    Dictionary< int, Actor*, TRUE >* m_pkNPCsPool;
};

至此，就完成了一套以抽象工廠管理物件家族的系統架構了。

而除了上述每一種物件都有一個相對應的函式 CreateXXX() 的做法，Abstract Factory 模式的另一種實作方法，是僅定義唯一的一個函式介面，然後藉由使用者傳入的整數數值或字串數值，用以決定所要創造的產品。以 HumanActorFactory 類別為例，原有的實作方式可以修改成：

// @file HumanActorFactory .h
#include "ActorFactory.h"

class HumanActorFactory : public ActorFactory
{
public:
    HumanActorFactory();
    virtual ~HumanActorFactory();

    virtual Actor* CreateActor(int _iType, Vector3 _tPos);
};

// @file HumanActorFactory.cpp
#include "HumanActorFactory.h"

Actor* HumanActorFactory::CreateActor(int _iType, Vector3 _tPos)
{
    Actor* pkActor = NULL;

    switch (_iType) {
        case Actor_Player: {
            pkActor = new Player(_tPos);
            break;
        }
        case Actor_NPC: {
            pkActor = new NPC(_tPos);
            break;
        }
        default: {
            // Error!
        }
    }

    return pkActor;
}

使用上述這個實作方法的優點在於，工廠的抽象類別與實體類別不必隨著新增的產品需求，而需要不斷地增加相對應的成員函式 CreateXXX()，僅需要唯一的一個 CreateActor() 成員函式，藉由傳入一個參數值指定出要創造的物件類型，而能夠達到更便利的工廠擴充性。

然而如果使用這個方法來實作 Abstract Factory 的話，CreateActor() 函式需要嚴格檢查傳入的參數值，確保萬一傳入不明的值也不會產生出例外的錯誤狀況。另外的問題，在於 CreateActor() 函式不論創建了什麼種類的物件，回傳值都是基底抽象類別 Actor，系統使用者需要自行將這個值進行向下轉型 (Downcast) 以進行後續的操作處理，需要注意轉型時可能發生的錯誤情形。

根據《物件導向設計模式》(Design Patterns) 書中所述，在程式架構中使用 Abstract Factory 模式的效果如下：

• 將具象類別隔離開來。
• 易於將整族成品物件抽換掉。
• 增進成品物件的一致性。

回頭檢視上述的程式範例，是不是能夠瞭解使用 Abstract Factory 模式所達成的這三項效果了？

再舉一個例子，回到前篇 Factory Method 的文章中所提到的創建貼圖範例，如果使用 Abstract Factory 模式加以延伸，甚至能夠將所有相關於繪圖渲染程序的物件，例如：Texture、Light、Material、Camera、Font 等等物件，全部聚集在 GraphicsRenderer 類別中；

class GraphicsRenderer
{
public:
    GraphicsRenderer();
    virtual ~GraphicsRenderer();

    Texture* CreateTexture();
    Light* CreateLight();
    Material* CreateMaterial();
};

由上述類別架構所產生的 UML 結構如圖所示。對程式系統撰寫者來說，在這樣的系統架構之下，就能夠簡化這群高度相依物件的管理與生滅關係；而對於程式系統的使用者來說，也能夠很清楚地意識到：如果我需要創建與繪圖程序相關的物件，找 GraphicsRenderer 這位負責人就一定不會錯了！

至此，結合「Factory Method：工廠化的物件生產方法」與本篇文章中的知識，就能夠習得生成設計模式中，兩大工廠的基本概念與應用。

對於 Factory 相關的設計模式，還有許多進階的延伸設計模式與變形實作方法；例如很直覺地能夠將上述的 HumanActorFactory 與 NonHumanActorFactory 類別實作成為 Singleton 模式以利使用。另外像是 Manager Pattern 之類的設計模式，把物件家族全權交由一位專業經理人打點系統內部的管理與外部的溝通行為，也是很常見的作法。

程式碼範例下載：AbstractFactory_SampleCode.zip (下載次數： 538 )

想要熟悉 Factory Method 設計模式，首先要瞭解下列幾項問題：

• 這個設計模式的目的是什麼？
• 這個設計模式能夠用來解決什麼樣的問題？
• 這個設計模式要如何應用在遊戲程式之中？

或許對於程式設計者來說，十個人之中有九個半討厭聽到「工廠」或「工廠化管理」的相關術語，但是在軟體設計模式的領域中，工廠化的生產作業方式反而是相當實際而且管用的方法。Factory Method 是軟體領域中，非常基礎同時也非常重要的設計模式之一，或許你從來沒有在書本中學習過相關的知識，但是已經在撰寫程式的經驗過程中，處處使用著這樣的設計方法而不自知。如果能夠進一步瞭解這些前人思維架構的心血結晶，將有助於改善現有的程式架構，並且提升未來撰寫程式系統架構的能力。

在 Factory Method 中的「工廠」，意指製造具體「成品」的場所，也就是在程式中創建出具體物件的創造者。所以 Factory Method 在設計模式的分類中屬於「生成模式」的一種，目的是將物件的具現化過程加以抽象化而提取出來，用來處理與物件相關的創建行為與毀滅行為。根據《物件導向設計模式》(Design Patterns) 書中 Factory Method 的 UML 結構圖描述，定義了參與工廠方法模式的四個角色：

• Product：定義 Factory Method 所造物件的介面。
• ConcreteProduct：具體實作出 Product 介面。
• Creator：宣告 Factory Method，它會傳回 Product 型別之物件。
• ConcreteCreator：覆寫 Factory Method 以傳回 ConcreteProduct 的物件個體。

這裡的 Creator 扮演著抽象化工廠的角色，僅宣告出可供衍生類別覆寫的成員函式；而真正要製作出實體成品的實做細節，則是交由繼承自 Creator 的實作工廠 ConcreteCreator 所定義。如 UML 結構圖所示，在 ConcreteCreator 中，就可以指涉並且生成真正的實體成品 ConcreteProduct。就像是鞋子工廠只能製造鞋子，帽子工廠只能製造帽子，在工廠方法模式中，通常是一個「創造者」搭配一項「產品」，所以「實體工廠」與「實體產品」的類別定義，經常會以成對的模式出現在程式系統之中。

以 3D 程式設計中的創建貼圖 (Create Texture) 程序為例，由於貼圖生成動作是與繪圖渲染器 (Renderer) 高度相依的行為，所以在一般的情況之下，程式設計者多半會選擇將貼圖相關的程序包含在 Renderer 類別的定義中；假設我們使用 Direct3D 的繪圖 API 進行從檔案創建貼圖的程序，程式碼應該會像是：

// Direct3D version
void GraphicsRenderer::CreateTexture(std::string& _rkTextureName)
{
    D3DXCreateTextureFromFile(m_pD3DDevice, _rkTextureName.c_str(), m_ppkTexture);
}

GraphicsRenderer 是繪圖渲染器的處理類別，在 CreateTexture() 函式中，直接使用 D3DX Library 的輔助函式 D3DXCreateTextureFromFile() 就能夠順利地讀取檔案並且建立貼圖。這是看起來沒有任何問題的程式碼。

然而，如果在某些不可抗力的情況之下，需要將原本使用的繪圖 API 由 Direct3D 轉換至 OpenGL 時，該怎麼做？

不管是因為進行全新的第二個專案，還是因為換了 OpenGL 派的程式主管，甚至是因為微軟突然間被惡性併購倒閉。要換成 OpenGL 的繪圖程序？很簡單，只要把相關的貼圖處理程式碼置換掉就沒問題了：

// OpenGL version
void GraphicsRenderer::CreateTexture(std::string& _rkTextureName)
{
    m_pvImageData = LoadImage(_rkTextureName);
    glGenTextures(1, &m_iTextureID);
}

OK，同樣沒有任何問題。由於你的傑出表現，前面的兩個遊戲專案都相當地成功而且賣座，到了第三個專案，終於有足夠的經費可以購買 3D 引擎來開發遊戲了！

要如何能夠把原有的程式碼，轉換成適用外部 3D 引擎的用法呢？同樣地，把之前 OpenGL 相關的部分刪除，新增外部 3D 引擎的 API 即可，函式介面完全沒變：

// SuperEngine version
void GraphicsRenderer::CreateTexture(std::string& _rkTextureName)
{
    SuperEngine::LoadImage(_rkTextureName);
    SuperEngine::CreateTexture(_rkTextureName);
}

看起來一切正常。然而，在上述的情境中，雖然保全了函式介面的不變性與重複利用性 (Reusablility)，但每次更換繪圖 API 時，程式設計者卻不得不在新舊的程式碼的函式實作版本間，使用 Ctrl-C 與 Ctrl-V 進行大量的複製、貼上、刪除與修改的動作。以上述的程式碼範例來看，複製貼上且進行必要的修改並不是什麼困難的事情，但是當專案的規模成長到某種程度，例如數百個程式碼檔案、數萬行程式碼的時候，往往會令程式設計者望而生畏。與其大興土木地從舊有的程式碼中挖牆修補，許多程式設計者最後會選擇將程式架構整個打掉重建，而很遺憾地無法達到程式碼的重複利用性。

在此如果運用 Factory Method 設計模式，就能夠妥善並且優雅地解決這個貼圖物件生成模式的難題。根據《物件導向設計模式》所述，Factory Method 的使用時機有下列三項：

• 當類別無法明指欲生成的物件類別時。
• 當類別希望讓子類別去指定欲生成的物件類型時。
• 當類別將權力下放給一個或多個輔助用途的子類別，你又希望將「交付給哪些子類別」的知識集中在一處時。

在這個例子中，我們需要產生出不同繪圖 API 實作版本的工廠類別，以及與工廠相對應的實體產品類別，因此相當符合第二項的使用時機。在新的程式架構中，首先需要將創建貼圖的程序導向化設計，改變成物件導向化的設計，也就是將所有與貼圖相關的屬性和操作封裝成為一個 Texture 類別。在此 GraphicsRenderer 所扮演的是 Factory Method 中的創造者角色，而 Texture 就是由 GraphicsRenderer 所創建出來的產品。

// @file Texture.h
class Texture
{
public:
    Texture();
    virtual ~Texture();

    virtual void Load(std::string& _rkFileName);
    std::string GetFileName() const;

protected:
    std::string m_kFileName;
};

基本上，由於 Texture 扮演的是抽象化的角色，所以類別的內容非常簡單，除了記錄檔案名稱的屬性之外，最重要的是宣告用來讀取檔案的虛擬成員函式 Load()。

接著是 GraphicsRenderer 類別，對於創建貼圖的操作也非常簡單，只要接受一個字串參數，然後回傳創建完成的 Texture 物件指標即可：

// @file GraphicsRenderer.h
class Texture;

class GraphicsRenderer
{
public:
    GraphicsRenderer();
    virtual ~GraphicsRenderer();

    virtual Texture* CreateTexture(std::string& _rkTextureName);
}

// @file GraphicsRenderer.cpp
#include "Texture.h"
Texture* GraphicsRenderer::CreateTexture(std::string& _rkTextureName)
{
    return NULL;
}

按照 Factory Method 的 UML 結構圖所示，有了抽象化的 Product 類別與 Creator 類別之後，就可以開始依實作需求創造出不同版本的 ConcreteProduct 類別與 ConcreteCreator 了。以 Direct3D 的實作版本為例，把與 Direct3D 相關的結構都存放在這個新建的 D3DTexture 類別中：

// @file D3DTexture.h
class D3DTexture : public Texture
{
public:
    D3DTexture();
    virtual ~D3DTexture();

    virtual void Load(std::string& _rkFileName);

private:
    LPDIRECT3DTEXTURE9* m_ppkTexture;
};

// @file D3DTexture.cpp
void D3DTexture::Load(std::string& _rkFileName)
{
    D3DXCreateTextureFromFile(m_pD3DDevice, _rkFileName.c_str(), m_ppkTexture);
}

Direct3D 版本的渲染器類別 D3DGraphicsRenderer 繼承自抽象化的 GraphicsRenderer 類別，定義如下：

// @file D3DGraphicsRenderer.h
class D3DGraphicsRenderer : public GraphicsRenderer
{
public:
    D3DGraphicsRenderer ();
    virtual ~D3DGraphicsRenderer ();

    virtual Texture* CreateTexture(std::string& _rkFileName);
}

// @file D3DGraphicsRenderer.cpp
#include "D3DTexture.h"

Texture* D3DGraphicsRenderer::CreateTexture(std::string& _rkFileName)
{
    return new D3DTexture(_rkFileName);
}

有了抽象化的 Texture 類別與 GraphicsRenderer 類別，再衍生出 D3DTexture 類別與 D3DGraphicsRenderer 類別之後，就完成了一組 Factory Method 的類別組成架構。可以開始輕鬆簡單地生產 Direct3D 版本的 Texture 物件了：

// @file FactoryMethod.cpp
void main()
{
    // Create D3D renderer
    GraphicsRenderer* pkD3DRenderer= new D3DGraphicsRenderer();

    // Create textures
    std::string kFileName1 = "123.jpg";
    Texture* pkTex1 = pkD3DRenderer->CreateTexture(kFileName1);
    std::string kFileName2 = "abc.png";
    Texture* pkTex2 = pkD3DRenderer->CreateTexture(kFileName2);
    std::string kFileName3 = "tree.bmp";
    Texture* pkTex3 = pkD3DRenderer->CreateTexture(kFileName3);

    // Destroy textures
    pkD3DRenderer->DestroyTexture(pkTex3);
    pkD3DRenderer->DestroyTexture(pkTex2);
    pkD3DRenderer->DestroyTexture(pkTex1);

    // Destroy D3D renderer
    delete pkD3DRenderer;
}

如果要增加 OpenGL 版本的創建貼圖程序，只要仿照上述的方式，再定義出一組新的 OGLTexture 類別與 OGLGraphicsRenderer 類別，就能夠輕易地達成更換實作版本的目標。除了一開始對於實體工廠的選擇，需要明確指定出要使用的是 D3DGraphicsRenderer 工廠或 OGLGraphicsRenderer 工廠之外，往後就能夠完全忽略實作層面的細節，僅需要對抽象化工廠 GraphicsRenderer 所提供的介面進行與貼圖相關的操作行為。

有了 Factory Method 設計模式，就不必再將與應用場合高度相依的類別寫死在主程式裡。主程式只須面對 Product 介面，因此可和任何未知的 ConcreteProduct 類別合作無間。

而在上述的例子中，有了創建貼圖的設計模式後，很自然地能夠再增加如 DestroyTexture() 的成員函式處理貼圖毀滅的程序。怎麼來的就怎麼回去；由工廠所創造出來的產品，就交由工廠進行毀滅的程序。所以在新增了 DestroyTexture() 成員函式之後，就能夠讓使用者傳入 Texture 物件指標或是 Texture 的名稱，於實體工廠中對貼圖資源進行毀滅或暫時回收的動作。而同樣地，使用者無須去操心煩惱相關的處理細節，只要全部丟給工廠處理就沒問題了！另外，當然也可以在工廠類別內部，使用改良版的 STL 容器存放這些貼圖物件，以達到集中管理的功用。

不論工廠內部的管理方法、製造流程如何地更換變動，都不會影響到系統外部使用者的操作行為，這就是使用 Factory Method 模式所帶來的程式架構益處。對於系統外部的使用者來說，以 Factory Method 實現出來的程式組件，就像是真實的工廠般準確無誤的運作：只要將事先約定好的資訊（貼圖檔案名稱）交遞給工廠，它就能夠生產出使用者所要求的產品（貼圖物件）。使用者通常並不會也不需要關心成品的生產過程或生成模式，因此利用 Factory Method 創建物件產品，正好能夠完善地封裝隱藏物件生成過程的實做細節。如同黑盒子的工作程序一樣，使用者不需要去瞭解產品究竟是使用 new operator 配置記憶體，或是利用資源回收系統產生出要求的物件，只管直接使用創建出來的物件即可。

左圖就是上述創建貼圖範例的 UML 結構圖示，不妨與文章開頭的 Factory Method UML 結構圖兩相比對。是不是能夠對於這個有趣又實用的設計模式有了基礎的認識？

在這裡瞭解了 Factory Method 設計模式的實現目的，以及運用在遊戲程式難題中的實用性之後，其實只完成了對於工廠設計模式的一半認識。

工廠設計模式的另外半部知識，也就是 Factory Method 的好兄弟——Abstract Factory 模式，即將在續篇中接力上場，欲知結局如何，靜待續集分曉！

程式碼範例下載：FactoryMethod_SampleCode.zip (下載次數： 549 )