今天開始這個系列之前，心里有些恐慌，畢竟園子里的高手關于設計模式的經典文章很多很多，特別是大俠李會軍、呂震宇 老師的文章更是堪稱經典。他們的文筆如行云流水，例子活潑生動，講解深入淺出。好在他們都是用C#描述，也沒有提供必要的源碼下載，所以我這里用C++實 現。首先我想聲明的是我的文筆絕對不如他們的好，例子也沒有他們的形象，不過我打算把C++的代碼實現和類圖提供給大家，就算作為一種補充吧。 開始設計模式自然而然到提到幾個原則：I、開閉法則（OCP）；II、里氏代換法則（LSP）；III、依賴倒置法則(DIP)；IV、接口隔離法則（ISP）；V、合成/聚合復用原則（CARP）；VI、迪米特法則（LoD），這幾個法則在呂震宇 老師的設計模式（二）和設計模式（三）中有非常詳盡的闡述和深入淺出的舉例分析。有興趣的朋友打開鏈接看一下就可以了。補充說明：
- 我這里所以代碼都是用VS2005的C++編譯器實現。所以不能保證在其他IDE中能順利編譯，但是我想如果你使用其他編譯器，也應該不會有太大問題，主要也應該是stdafx.h文件中包含的頭文件問題。
- 里面出行的結構圖都是用微軟的Visio2003 繪制，大家下載后可以直接用Visio打開。
- 在 以后所有的模式例子中都有客戶程序，客戶程序這個角色不是模式本身的內容，它是模式之外的部分，但是正是這個客戶程序完成了對模式的使用，模式本身的結構 是講解的重點，但是客戶程序如何使用模式也是理解模式的一個重要方面，因此在我后續的介紹中都有客戶程序這個角色，并會說明究竟調用模式中的哪些角色完成 對模式的使用。
簡單工廠模式生活例子 吃飯是人的基本需求，如果人類不需要吃飯，可能我們就能活得清閑許多，也就不需要像現在一樣沒日沒夜的工作，學習。我們學習是為了找到更好的工作，好工作 為了賺更多的錢，最終為了吃飽飯，吃好飯。因此可以說吃飯是與人息息相關，下面就從吃飯的例子來引入工廠模式的學習。 如果你想吃飯了，怎么辦自己做嗎？自己做就相當于程序中直接使用new。當然是自己下個指令，別人來做更爽。那就把做飯的任務交給你的老婆吧，那么她就是 一個做飯的工廠了，你告訴她要要吃紅燒肉，等會她就從廚房給你端出來一盤香噴噴的紅燒肉了，再來個清蒸魚吧，大魚大肉不能太多，那就再來個爆炒空心菜，最 后再來個西紅柿雞蛋湯。下圖 1) 就是這個問題的模型。 
（圖1）顯然到了這里，你是Client，你老婆就是工廠，她擁有做紅燒肉的方法，做清蒸魚的方法，做爆炒空心菜、西紅柿雞蛋湯的方法，這些方法返回值就是食物 抽象。紅燒肉、清蒸魚、爆炒空心菜、西紅柿雞蛋湯就是食物的繼承類，到這里你就可以大吃二喝了。簡單工廠模式也成型了。哈哈，娶一個手藝不錯的老婆還真 好，吃的好，吃的爽，又清閑。 下面來看標準的簡單工廠模式的分析。 
意圖 把一系列擁有共同特征的產品的創建封裝 結構圖 （圖2）角色分析產品基類： 工廠創建的所有產品的基類, 它負責描述所有實例所共有的公共接口。它用來作為工廠方法的返回參數。代碼實現： //---這時一個系列的產品基類
1 class Product
2 {
3 protected:
4 Product(void);
5 public:
6 virtual ~Product(void);
7 public:
8 virtual void Function() = 0;
9 };
10 //cpp
11 Product::Product(void)
12 {
13 }
14 Product::~Product(void)
15 {
16 }
具體產品類：產品1和產品2，這個角色實現了抽象產品角色所定義的接口。代碼實現： //產品A
1 class ConcreteProductA:public Product
2 {
3 public:
4 ConcreteProductA(void);
5 public:
6 virtual ~ConcreteProductA(void);
7 public:
8 virtual void Function();
9 };
10 //cpp
11 ConcreteProductA::ConcreteProductA()
12 {
13 cout<<"創建 A 產品"<<endl;
14 }
15 ConcreteProductA::~ConcreteProductA()
16 {
17 cout<<"釋放 A 產品"<<endl;
18 }
19 void ConcreteProductA::Function()
20 {
21 cout<<"這是產品 A 具有的基本功能"<<endl;
22 }
23 //產品B與A類似不這里不再給出，大家可以下載源碼
工廠類：負責具體產品的創建，有兩種方式實現產品的創建，I、創建不同的產品用不同的方法；II、創建不同產品用相同的方法，然后通過傳遞參數實現不同產品的創建。本實例中兩種模式都給出了，大家自行分析。
1 //簡單工廠，此類不需要繼承，直接硬編碼實現生成的產品
2 class SimpleFactory
3 {
4 public:
5 SimpleFactory(){}
6 public:
7 ~SimpleFactory(){}
8 public:
9 Product *CreateProduct(int ProuctType);
10 Product *CreateProductA();
11 Product *CreateProductB();
12 };
13 //CPP
14 Product * SimpleFactory::CreateProduct(int ProductType=0)
15 {
16 Product *p = 0;
17 switch(ProductType)
18 {
19 case 0:
20 p= new ConcreteProductA();
21 break;
22 case 1:
23 p= new ConcreteProductB();
24 break;
25 default:
26 p= new ConcreteProductA();
27 break;
28 }
29 return p;
30 }
31 Product *SimpleFactory::CreateProductA()
32 {
33 return new ConcreteProductA();
34 }
35 Product *SimpleFactory::CreateProductB()
36 {
37 return new ConcreteProductB();
38 }
客戶端程序：訪問的角色包括產品基類、工廠類。不直接訪問具體產品類。通過基類指針的多態實現產品功能的調用。訪問描述：客戶程序通過調用工廠的方法返回抽象產品，然后執行產品的方法。 //調用代碼
1 SimpleFactory sf;
2 Product *p = sf.CreateProductA();
3 p->Function();
4 delete p;
5 p = sf.CreateProductB();
6 p->Function();
7 delete p;
優缺點說明優點：1) 首先解決了代碼中大量New的問題。為何要解決這個問題，好處的說明我想放到結尾總結中。 2) 用工廠方法在一個類的內部創建對象通常比直接創建對象更靈活。 缺點：對修改不封閉，新增加產品您要修改工廠。違法了鼎鼎大名的開閉法則（OCP）。附加說明
- 大家可以參看 呂震宇 老師的C#設計模式（四）參看這個模式的分析，里面還給出了這個模式的兩個變體，實現比較簡單，有興趣的朋友可以自行用C++實現一下。
- 產 品基類的代碼中構造函數我用了Protected，而沒有使用Public，主要是為了體現編碼中的一個最小權限原則。說明此類不許用戶直接實例化。雖然 這里使用了virtual void Function() = 0;編譯器也會控制不讓用戶直接實例化，不過我依然認為使用私有化構造函數來保護類不直接實例化是一個良好的編程風格。
工廠方法模式生活例子: 人是最貪得無厭的動物，老婆手藝再好，總有不會做的菜，你想吃回鍋肉，怎么辦，讓老婆學唄，于是就給她就新增了做回鍋肉的方法，以后你再想吃一個新菜，就 要給你老婆新加一個方法，顯然用老婆做菜的缺點也就暴露出來了，用程序設計的描述就是對修改永遠不能封閉。當然優點也是有的，你有了老婆這個工廠，這些菜 不用你自己做了，只要直接調用老婆這個工廠的方法就可以了。 面對上面對修改不能封閉的問題，有沒有好的解決方案嗎，如果你有錢，問題就迎刃而解了，把老婆抽象變成一個基類，你多娶幾個具體的老婆，分別有做魚 的，做青菜的，燉湯的老婆，如果你想吃一個新菜，就再新找個女人，從你的老婆基類繼承一下，讓她來做這個新菜。顯然多多的老婆這是所有男人的夢想，沒有辦 法，法律不允許，那么咱們只是為了做飯，老婆這個抽象類咱們不叫老婆了，叫做廚師吧，她的子類也自然而然的該叫做魚的廚師、燉湯的廚師了。現在來看這個模 式發生了變化，結構中多了一個廚師的抽象，抽象并不具體的加工產品了，至于是燉湯還是燉魚，是由這個抽象工廠的繼承子類來實現，現在的模式也就變成工廠方 法模式了，這個上面的結構圖1)就變成了下面的圖3的結構了。 
（圖3） 現在再來分析現在的模式，顯然簡單工廠的缺陷解決了，新增加一個菜只需要新增加一個廚師就行了，原來的廚師還在做原來的工作，這樣你的設計就對修改封 閉了。你看把老婆解放出來，招聘大量的廚師到你家里這個方案多么的完美，你老婆也會愛死你了。當然前提就是你要有多多的錢噢，當然這里的錢的多少在軟件領 域應該看你的客戶軟件投資方的要求。 下面來一下標準的工廠模式的實現 意圖
- 定義一個用戶創建對象的接口，讓子類決定實例化哪一個類。Factory Method使一個類的實例化延遲到其子類。
- 上面是GOF關于此模式的意圖描述，我想補充的是您可以這樣理解：為了改善簡單工廠對修改不能關閉的問題。
結構
圖4角色分析產品基類：同簡單工廠的產品基類，其實就是用和簡單工廠中的是同一個類，這里并沒有重寫。具體產品類：也是用的簡單工廠的具體產品類，為了體現對修改的關閉這里為系統新添加了一個具體產品類，就是“新產品”，代碼中叫做“ConcreteProductANew”工廠基類：定義了工廠創建產品的接口，但是沒有實現，具體創建工作由其繼承類實現。代碼實例
1 //工廠模式，此模式的工廠只定義加工產品的接口，具體生成交予其繼承類實現
2 //只有具體的繼承類才確定要加工何種產品
3 class Factory
4 {
5 public:
6 Factory(void);
7 public:
8 virtual ~Factory(void);
9 public:
10 virtual Product* CreateProduct(int ProductType = 0) =0;
11 };
12 //CPP
13 Factory::Factory(void)
14 {
15 }
16 Factory::~Factory(void)
17 {
18 }
具體工廠類：工廠基類的具體實現，由此類決定創建具體產品，這里 ConcreteFactory1 對于與圖中的 工廠實現，ConcreteFactory2 對于與圖中的新工廠。下面給出實現代碼
1 //工廠實現
2 class ConcreteFactory1:public Factory
3 {
4 public:
5 ConcreteFactory1();
6 public:
7 virtual ~ConcreteFactory1();
8 public :
9 Product* CreateProduct(int ProductType);
10 };
11 //新工廠，當要創建新類是實現此新工廠
12 class ConcreteFactory2:public Factory
13 {
14 public:
15 ConcreteFactory2();
16 public:
17 virtual ~ConcreteFactory2();
18 public :
19 Product* CreateProduct(int ProductType);
20 };
21 //CPP
22 ConcreteFactory1::ConcreteFactory1()
23 {
24 }
25 ConcreteFactory1::~ConcreteFactory1()
26 {
27 }
28 Product * ConcreteFactory1::CreateProduct(int ProductType = 0)
29 {
30 Product *p = 0;
31 switch(ProductType)
32 {
33 case 0:
34 p= new ConcreteProductA();
35 break;
36 case 1:
37 p= new ConcreteProductB();
38 break;
39 default:
40 p= new ConcreteProductA();
41 break;
42 }
43 return p;
44 }
45 ConcreteFactory2::ConcreteFactory2()
46 {
47 }
48 ConcreteFactory2::~ConcreteFactory2()
49 {
50 }
51 Product * ConcreteFactory2::CreateProduct(int ProductType = 0)
52 {
53 return new ConcreteProductANew();
54 }
客戶端調用：訪問角色（產品基類、工廠基類、工廠實現類）調用描述：客戶程序通過工廠基類的方法調用工廠實現類用來創建所需要的具體產品。從而實現產品功能的訪問。代碼實現
1 Factory*fct = new ConcreteFactory1();
2 Product *p = fct->CreateProduct(0);
3 p->Function();
4 delete p;
5 p = fct->CreateProduct(1);
6 p->Function();
7 delete p;
8 delete fct;
9 fct = new ConcreteFactory2();
10 p=fct->CreateProduct();
11 delete p;
12 delete fct;
優缺點分析優點
- 簡單工廠具有的優點
- 解決了簡單工廠的修改不能關閉的問題。系統新增產品，新增一個產品工廠即可，對抽象工廠不受影響。
缺點：對于創建不同系列的產品無能為力 適用性
- 當一個類不知道它所必須創建的對象的類的時候。
- 當一個類希望由它的子類來指定它所創建的對象的時候。
- 當類將創建對象的職責委托給多個幫助子類中的某一個，并且你希望將哪一個幫助子類是代理者這一信息局部化的時候。
其他參考
抽象工廠模式生活例子 世事多變，隨著時間的推移，走過的地方越來越多，你天南海北的朋友也越來越多。你發現菜原來還分了許多菜系，魯菜、粵菜、湘菜等等，它們各有各的風味，同 樣是紅燒肉由不同菜系出來的味道也各不相同， 你招待不同的朋友要用不同的菜系，這下難辦了，你的廚師都是魯菜風味，怎么辦，廣東的朋友來了吃不慣。現在我們再回到簡單工廠模式（就是老婆做菜的模 式），我們把紅燒肉再向下繼承，生成魯菜紅燒肉、粵菜紅燒肉、湘菜紅燒肉；清蒸魚向下繼承為魯菜清蒸魚、粵菜清蒸魚、湘菜清蒸魚，其它也以此類推。我們也 修改一下老婆的這個類，不讓其返回食物基類，而是返回紅燒肉、清蒸魚、爆炒空心菜、西紅柿雞蛋湯這一層次，并把這些方法抽象化，作為菜系工廠基類，然后再 從此基類繼承出，魯菜工廠、粵菜工廠、湘菜工廠等等，再由這些具體工廠實現創建具體菜的工作，哈哈你如果招待廣東朋友就用粵菜工廠，返回的就是一桌粵菜菜 系的紅燒肉、清蒸魚、空心菜和西紅柿雞蛋湯了，你的廣東朋友一定會吃的非常合乎胃口了。噢，非常好，你已經實現了抽象工廠模式了。結構模型圖也變成了下圖 6)的樣子了。
（圖6） 現在可以看到，想新來做一個菜系，只需新聘請一個廚師就可以了，多么完美，但是你先別高興太早，如果你想新增加一個菜就變得非常困難了。意圖 提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。 結構
角色分析產品基類：這里包含產品基類A和產品基類B，實際上在我的示例代碼中，這兩個產品都從共同的基類繼承而來，但是這個繼承關系卻是在這個模式之外的部分，而本身這個模式關心的是這兩個產品基類的差異部分。 代碼實現：這里的代碼就是借用的簡單工廠模式中具體產品類的代碼實現部分，為了大家閱讀方便，下面重新給出一下。
1 //產品A
2 class ConcreteProductA:public Product
3 {
4 public:
5 ConcreteProductA(void);
6 public:
7 virtual ~ConcreteProductA(void);
8 public:
9 virtual void Function();
10 };
11 //cpp
12 ConcreteProductA::ConcreteProductA()
13 {
14 cout<<"創建 A 產品"<<endl;
15 }
16 ConcreteProductA::~ConcreteProductA()
17 {
18 cout<<"釋放 A 產品"<<endl;
19 }
20 void ConcreteProductA::Function()
21 {
22 cout<<"這是產品 A 具有的基本功能"<<endl;
23 }
24 //產品B與A類似不這里不再給出，大家可以下載源碼
具體產品類：這里的具體產品類是產品A1，A2，B1、B2等，代碼實現：A1對應的實現就是“”
1 class ConcreteProductA1:public ConcreteProductA
2 {
3 public:
4 ConcreteProductA1(void);
5 public:
6 virtual ~ConcreteProductA1(void);
7 public:
8 virtual void Function();
9 };
10 //CPP
11 ConcreteProductA1::ConcreteProductA1()
12 {
13 cout<<"創建 A1 產品"<<endl;
14 }
15 ConcreteProductA1::~ConcreteProductA1()
16 {
17 cout<<"釋放 A1 產品"<<endl;
18 }
19 void ConcreteProductA1::Function()
20 {
21 cout<<"這時產品 A1 具有的基本功能"<<endl;
22 }
工廠抽象接口：定義了創建產品的接口，這里返回參數是返回的產品A，產品B，而本身產品A和B的共同基類，小弟認為正是這個特征構成了抽象工廠和工廠模式的區別。代碼實現
1 //抽象工廠模式
2 class AbstractFactory
3 {
4 public:
5 AbstractFactory();
6 public:
7 virtual ~AbstractFactory();
8 public:
9 virtual ConcreteProductA* CreateA() = 0;
10 virtual ConcreteProductB* CreateB() = 0;
11 };
12 //CPP
13 AbstractFactory::AbstractFactory()
14 {
15 }
16 AbstractFactory::~AbstractFactory()
17 {
18 }
具體工廠實現類：工廠1和工廠2。新增加系列，只需新實現一個工廠。代碼實現: 工廠1的就是ConcreteAbsFactory1，工廠2的代碼類似，這里沒有給出，可以在下載代碼中看到
1 ////工廠1-----
2 class ConcreteAbsFactory1:public AbstractFactory
3 {
4 public:
5 ConcreteAbsFactory1();
6 public:
7 virtual ~ConcreteAbsFactory1();
8 public:
9 virtual ConcreteProductA* CreateA();
10 virtual ConcreteProductB* CreateB();
11 };
12 //CPP
13 ConcreteAbsFactory1::ConcreteAbsFactory1()
14 {
15 }
16 ConcreteAbsFactory1::~ConcreteAbsFactory1()
17 {
18 }
19 ConcreteProductA* ConcreteAbsFactory1::CreateA()
20 {
21 return new ConcreteProductA1();
22 }
23 ConcreteProductB * ConcreteAbsFactory1::CreateB()
24 {
25 return new ConcreteProductB1();
26 }
客戶端訪問： 訪問角色（產品基類、抽象工廠、具體工廠實現類）訪問描述： 通過抽象工廠的指針訪問具體工廠實現來創建對應系列的產品，然后通過產品基類指針訪問產品功能。調用代碼：
1 AbstractFactory *absfct = new ConcreteAbsFactory1();
2 ConcreteProductA *cpa = absfct->CreateA();
3 cpa->Function();
4 delete cpa;
5 ConcreteProductB *cpb = absfct->CreateB();
6 cpb->Function();
7 delete cpb;
8 delete absfct;
9 absfct = new ConcreteAbsFactory2();
10 cpa = absfct->CreateA();
11 cpa->Function();
12 delete cpa;
13 cpb = absfct->CreateB();
14 cpb->Function();
15 delete cpb;
和工廠模式的分析比較 現在可以和工廠模式對比一下，抽象工廠返回的接口不再是產品A和產品B的共同基類Product了，而是產品A、產品B基類（在工廠模式中它們為具體實現 類，這里變成了基類）了。此時工廠的抽象和簡單工廠中的工廠方法也很類似，就是這些特征區使其別于工廠模式而變成抽象工廠模式了，因此抽象工廠解決的是創 建一系列有共同風格的產品（魯菜還是粵菜），而工廠方法模式解決的創建有共同特征的一系列產品（紅燒肉、清蒸魚它們都是食物）。當然簡單工廠的缺陷在抽象 工廠中又再次出現了，我要新增加一個產品，工廠抽象接口就要改變了。因此抽象工廠并不比工廠模式完美，只不過是各自的適用領域不同而已。其實，這里如果把 抽象工廠模式的接口返回產品A和產品B的共同基類（工廠模式返回的參數），你會發現，奇怪這個模式怎么這么眼熟，它不是恰恰退化成工廠模式了。類模式與對象模式的區別討論：先看定義類“模式使用繼承關系，把對象的創建延遲的子類，對象模式把對象的創建延遲到另一個對象中”。 分析：首先它們創建對象都不是在基類中完成，都是在子類中實現，因此都符合類模式的概念；但是工廠模式的創建產品對象是在編譯期決定的，要調用某個工廠固 定的，而抽象工廠模式對產品的創建是在運行時動態決定的，只有到運行時才確定要調用那個工廠，調用工廠隨運行環境而改變。（這里我一直很混亂，歡迎大家討 論）適用性
- 一個系統要獨立于它的產品的創建、組合和表示時
- 一個系統要由多個 產品系列中的一個來配置時
- 當你要強調一個系列相關的產品對象的設計以便進行聯合使用時
- 當你提供一個產品類庫，而只想顯示它們的接口而不是實現時。
參考
總結 工廠本質就是用工廠方法替代直接New來創建對象。這里不是指的讓用戶重載一個新操作符號來進行創建對象的操作，而是說把New 操作封裝在一個方法中，等用戶需要創建對象時調用此方法而避免直接使用New而已。這樣做的目的就是之一就是封裝，避免代碼中大量New的運算符，這當然 不是主要目的，因為這樣雖然New少了，CreateObject方法卻多了，但是如果產品類的構造函數變了，我想常用工廠模式的修改源代碼的工作應該簡 便許多吧，當然這算不上這個模式的好處，它的真正強大的功能其實在于適應變化，這也是整個設計模式最根本的目的；還有一點就是體現了抽象于實現的分離，當 然創建型模式都具有這個特點，工廠模式非常明顯吧了，把具體創建工作放置到工廠中，使客戶端程序更專注與業務邏輯的，這樣的代碼結構也更進行合理。
實例代碼下載 結構類圖下載 本文轉自：
http://hi.baidu.com/laocui172/item/0211be1ca50c3af487ad4ed6其他鏈接：
http://blog.csdn.net/wuzhekai1985/article/details/6660462
posted on 2012-07-12 08:44
王海光 閱讀(574)
評論(0) 編輯 收藏 引用 所屬分類:
Design Pattern