C++設計模式之原廠模式_C 語言

由遇到的問題引出原廠模式

在物件導向系統設計中經常可以遇到以下的兩類問題：

◆ 1.為了提高內聚（Cohesion）和松耦合（Coupling），我們經常會抽象出一些類的公用介面以形成抽象基類或者介面。這樣我們可以通過聲明一個指向基類的指標來指向實際的子類實現，達到了多態的目的。這裡很容易出現的一個問題 n 多的子類繼承自抽象基類，我們不得不在每次要用到子類的地方就編寫諸如 new ×××;的代碼。這裡帶來兩個問題：
客戶程式員必須知道實際子類的名稱（當系統複雜後，命名將是一個很不好處理的問題，為了處理可能的名字衝突，有的命名可能並不是具有很好的可讀性和可記憶性，就姑且不論不同程式員千奇百怪的個人偏好了）。
程式的擴充性和維護變得越來越困難。

◆ 2.還有一種情況就是在父類中並不知道具體要執行個體化哪一個具體的子類。這裡的意思為：假設我們在類 A 中要使用到類 B，B 是一個抽象父類，在 A 中並不知道具體要執行個體化那一個 B 的子類，但是在類 A 的子類 D 中是可以知道的。在 A 中我們沒有辦法直接使用類似於 new ×××的語句，因為根本就不知道×××是什麼。

以上兩個問題也就引出了原廠模式的兩個最重要的功能：

1. 定義建立對象的介面，封裝了對象的建立；
2. 使得具體化類的工作延遲到了子類中。

模式選擇

我們通常使用原廠模式來解決上面給出的兩個問題。在第一個問題中，我們經常就是聲明一個建立對象的介面，並封裝了對象的建立過程。工廠這裡類似於一個真正意義上的工廠（生產對象）。在第二個問題中，我們需要提供一個對象建立對象的介面，並在子類中提供其具體實現（因為只有在子類中可以決定到底執行個體化哪一個類）。

第一中情況的工廠的結構示意圖為：

圖 1 所以的原廠模式經常在系統開發中用到，但是這並不是原廠模式的最大威力所在（因為這可以通過其他方式解決這個問題）。原廠模式不單是提供了建立對象的介面，其最重要的是延遲了子類的執行個體化（第二個問題），以下是這種情況的一個工廠的結構示意圖：

圖 2 中關鍵中原廠模式的應用並不是只是為了封裝對象的建立，而是要把對象的建立放到子類中實現：工廠中只是提供了對象建立的介面，其實現將放在工廠的子類Concrete工廠中進行。這是圖 2 和圖 1 的區別所在。

原廠模式的實現

完整程式碼範例（code）：原廠模式的實現比較簡單，這裡為了方便初學者的學習和參考，將給出完整的實現代碼（所有代碼採用 C++實現，並在 VC 6.0 下測試回合）。

代碼片斷 1：Product.h

//Product.h#ifndef _PRODUCT_H_#define _PRODUCT_H_class Product{ public: virtual ~Product() =0; protected: Product(); //屏蔽建構函式 private:};class ConcreteProduct:publicProduct{ public: ~ConcreteProduct(); ConcreteProduct(); protected: private:};#endif //~_PRODUCT_H_

代碼片斷 2：Product.cpp

//Product.cpp#include "Product.h"#include<iostream>using namespace std;Product::Product(){}Product::~Product(){}ConcreteProduct::ConcreteProduct(){ cout<<"ConcreteProduct...."<<endl;}ConcreteProduct::~ConcreteProduct(){}

代碼片斷 3：Factory.h

//Factory.h#ifndef _FACTORY_H_#define _FACTORY_H_class Product;class Factory{ public: virtual ~Factory() = 0; virtual Product* CreateProduct() = 0; protected: Factory(); private:};class ConcreteFactory:public Factory{ public: ~ConcreteFactory(); ConcreteFactory(); Product* CreateProduct(); protected: private:};#endif //~_FACTORY_H_

代碼片斷 4：Factory.cpp

//Factory.cpp#include "Factory.h"#include "Product.h"#include <iostream>using namespace std;Factory::Factory(){}Factory::~Factory(){}ConcreteFactory::ConcreteFactory(){ cout<<"ConcreteFactory....."<<endl;}ConcreteFactory::~ConcreteFactory(){}Product* ConcreteFactory::CreateProduct(){ return new ConcreteProduct();}

代碼片斷 5：main.cpp

//main.cpp#include "Factory.h"#include "Product.h"#include <iostream>using namespace std;int main(int argc,char* argv[]){ Factory* fac = new ConcreteFactory(); Product* p = fac->CreateProduct(); return 0;}

代碼說明：範例程式碼中給出的是原廠模式解決父類中並不知道具體要執行個體化哪一個具體的子類的問題，至於為建立對象提供介面問題，可以由工廠中附加相應的建立操作例如Create***Product（）即可。具體請參加討論內容。

關於原廠模式的討論

原廠模式在實際開發中應用非常廣泛，物件導向的系統經常面臨著對象建立問題：要建立的類實在是太多了。而工廠提供的建立對象的介面封裝（第一個功能），以及其將類的執行個體化延遲到子類（第二個功能）都部分地解決了實際問題。一個簡單的例子就是筆者開開發 VisualCMCS 系統的語義分析過程中，由於要為文法中的每個非終結符構造一個類處理，因此這個過程中對象的建立非常多，採用原廠模式後系統可讀性性和維護都變得elegant 許多。

原廠模式也帶來至少以下兩個問題：

1. 如果為每一個具體的 ConcreteProduct 類的執行個體化提供一個函數體，那麼我們可能不得不在系統中添加了一個方法來處理這個建立的 ConcreteProduct，這樣工廠的介面永遠就不肯能封閉（Close）。當然我們可以通過建立一個工廠的子類來通過多態實現這一點，但是這也是以建立一個類作為代價的。
2. 在實現中我們可以通過參數化Factory 方法，即給 工廠Method（）傳遞一個參數用以決定是建立具體哪一個具體的 Product（實際上筆者在 VisualCMCS 中也正是這樣做的）。當然也可以通過模板化避免 1）中的子類建立子類，其方法就是將具體 Product 類作為模板參數，實現起來也很簡單。

可以看出，原廠模式對於對象的建立給予開發人員提供了很好的實現策略，但是原廠模式僅僅局限於一類類（就是說 Product 是一類，有一個共同的基類），如果我們要為不同類的類提供一個對象建立的介面，那就要用 Abstract工廠了。