0 引言
0.1 目的
本文檔給出設(shè)計(jì)模式之——Factory模式的簡化詮釋，并給出其C++實(shí)現(xiàn)。
0.2 說明
|
Project
|
Design Pattern Explanation（By K_Eckel）
|
|
Authorization
|
Free Distributed but Ownership Reserved
|
|
Date
|
|
|
Test Bed
|
MS Visual C++ 6.0
|
0.3 參考
在本文檔的寫作中，參考了以下的資源，在此列出表示感謝：
u 書籍
[GoF 2000]：GoF,Design Patterns-Elements of Reusable Object-Oriented Software Addison-Wesley 2000/9.
[Martine 2003]：Robert C.Martine, Agile Software Development Principles, Patterns, and Practices, Pearson Education, 2003.
u 網(wǎng)頁
0.4 聯(lián)系作者
|
Author
|
K_Eckel
|
|
State
|
Candidate for Master’s Degree School of
|
|
E_mail
|
frwei@whu.edu.cn
|
2 Factory模式
2.1 問題
在面向?qū)ο笙到y(tǒng)設(shè)計(jì)中經(jīng)常可以遇到以下的兩類問題：
1）為了提高內(nèi)聚（Cohesion）和松耦合（Coupling），我們經(jīng)常會(huì)抽象出一些類的公共接口以形成抽象基類或者接口。這樣我們可以通過聲明一個(gè)指向基類的指針來指向?qū)嶋H的子類實(shí)現(xiàn)，達(dá)到了多態(tài)的目的。這里很容易出現(xiàn)的一個(gè)問題n多的子類繼承自抽象基類，我們不得不在每次要用到子類的地方就編寫諸如new ×××;的代碼。這里帶來兩個(gè)問題1）客戶程序員必須知道實(shí)際子類的名稱（當(dāng)系統(tǒng)復(fù)雜后，命名將是一個(gè)很不好處理的問題，為了處理可能的名字沖突，有的命名可能并不是具有很好的可讀性和可記憶性，就姑且不論不同程序員千奇百怪的個(gè)人偏好了。），2）程序的擴(kuò)展性和維護(hù)變得越來越困難。
2）還有一種情況就是在父類中并不知道具體要實(shí)例化哪一個(gè)具體的子類。這里的意思為：假設(shè)我們?cè)陬怉中要使用到類B，B是一個(gè)抽象父類，在A中并不知道具體要實(shí)例化那一個(gè)B的子類，但是在類A的子類D中是可以知道的。在A中我們沒有辦法直接使用類似于new ×××的語句，因?yàn)楦揪筒恢?#215;××是什么。
以上兩個(gè)問題也就引出了Factory模式的兩個(gè)最重要的功能：
1）定義創(chuàng)建對(duì)象的接口，封裝了對(duì)象的創(chuàng)建；
2）使得具體化類的工作延遲到了子類中。
2.2 模式選擇
我們通常使用Factory模式來解決上面給出的兩個(gè)問題。在第一個(gè)問題中，我們經(jīng)常就是聲明一個(gè)創(chuàng)建對(duì)象的接口，并封裝了對(duì)象的創(chuàng)建過程。Factory這里類似于一個(gè)真正意義上的工廠（生產(chǎn)對(duì)象）。在第二個(gè)問題中，我們需要提供一個(gè)對(duì)象創(chuàng)建對(duì)象的接口，并在子類中提供其具體實(shí)現(xiàn)（因?yàn)橹挥性谧宇愔锌梢詻Q定到底實(shí)例化哪一個(gè)類）。第一中情況的Factory的結(jié)構(gòu)示意圖為：
圖1：Factory模式結(jié)構(gòu)示意圖1
圖1所以的Factory模式經(jīng)常在系統(tǒng)開發(fā)中用到，但是這并不是Factory模式的最大威力所在（因?yàn)檫@可以通過其他方式解決這個(gè)問題）。Factory模式不單是提供了創(chuàng)建對(duì)象的接口，其最重要的是延遲了子類的實(shí)例化（第二個(gè)問題），以下是這種情況的一個(gè)Factory的結(jié)構(gòu)示意圖：
圖2：Factory模式結(jié)構(gòu)示意圖1
圖2中關(guān)鍵中Factory模式的應(yīng)用并不是只是為了封裝對(duì)象的創(chuàng)建，而是要把對(duì)象的創(chuàng)建放到子類中實(shí)現(xiàn)：Factory中只是提供了對(duì)象創(chuàng)建的接口，其實(shí)現(xiàn)將放在Factory的子類ConcreteFactory中進(jìn)行。這是圖2和圖1的區(qū)別所在。
2.3 實(shí)現(xiàn)
|
代碼片斷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;
}
|
2.4 討論
Factory
模式在實(shí)際開發(fā)中應(yīng)用非常廣泛，面向?qū)ο蟮南到y(tǒng)經(jīng)常面臨著對(duì)象創(chuàng)建問題：要?jiǎng)?chuàng)建的類實(shí)在是太多了。而Factory提供的創(chuàng)建對(duì)象的接口封裝（第一個(gè)功
能），以及其將類的實(shí)例化推遲到子類（第二個(gè)功能）都部分地解決了實(shí)際問題。一個(gè)簡單的例子就是筆者開開發(fā)Visual
CMCS系統(tǒng)的語義分析過程中，由于要為文法中的每個(gè)非終結(jié)符構(gòu)造一個(gè)類處理，因此這個(gè)過程中對(duì)象的創(chuàng)建非常多，采用Factory模式后系統(tǒng)可讀性性和
維護(hù)都變得elegant許多。
Factory模式也帶來至少以下兩個(gè)問題：
1）如果為每一個(gè)具體的ConcreteProduct類的實(shí)例化提供一個(gè)函數(shù)體，那么我們可能不得不在系統(tǒng)中添加了一個(gè)方法來處理這個(gè)新建的
ConcreteProduct，這樣Factory的接口永遠(yuǎn)就不肯能封閉（Close）。當(dāng)然我們可以通過創(chuàng)建一個(gè)Factory的子類來通過多態(tài)實(shí)
現(xiàn)這一點(diǎn)，但是這也是以新建一個(gè)類作為代價(jià)的。
2）在實(shí)現(xiàn)中我們可以通過參數(shù)化工廠方法，即給FactoryMethod（）傳遞一個(gè)參數(shù)用以決定是創(chuàng)建具體哪一個(gè)具體的Product（實(shí)際上筆者在
Visual
CMCS中也正是這樣做的）。當(dāng)然也可以通過模板化避免1）中的子類創(chuàng)建子類，其方法就是將具體Product類作為模板參數(shù)，實(shí)現(xiàn)起來也很簡單。
可以看出，F(xiàn)actory模式對(duì)于對(duì)象的創(chuàng)建給予開發(fā)人員提供了很好的實(shí)現(xiàn)策略，但是Factory模式僅僅局限于一類類（就是說Product是一類，
有一個(gè)共同的基類），如果我們要為不同類的類提供一個(gè)對(duì)象創(chuàng)建的接口，那就要用Abstract Factory了。