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