c++设计模式之简单工厂模式、工厂方法模式、抽象工厂模式

有两篇文章可以参考：
http://blog.csdn.net/column/details/design.html http://www.cnblogs.com/jiese/tag/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/
软件领域中的设计模式为开发人员提供了一种使用专家设计经验的有效途径。设计模式中运用了面向对象编程语言的重要特性：封装、继承、多态，真正领悟设计模式的精髓是可能一个漫长的过程，需要大量实践经验的积累。最近看设计模式的书，对于每个模式，用C++写了个小例子，加深一下理解。主要参考《大话设计模式》和《设计模式:可复用面向对象软件的基础》两本书。本文介绍工厂模式的实现。

工厂模式属于创建型模式，大致可以分为三类，简单工厂模式、工厂方法模式、抽象工厂模式。听上去差不多，都是工厂模式。下面一个个介绍，首先介绍简单工厂模式，它的主要特点是需要在工厂类中做判断，从而创造相应的产品。当增加新的产品时，就需要修改工厂类。有点抽象，举个例子就明白了。有一家生产处理器核的厂家，它只有一个工厂，能够生产两种型号的处理器核。客户需要什么样的处理器核，一定要显示地告诉生产工厂。下面给出一种实现方案。

[cpp] view
plain copy

print?

enum CTYPE {COREA, COREB};

class SingleCore

{

public:

virtual void Show() = 0;

};

//单核A

class SingleCoreA: public SingleCore

{

public:

void Show() { cout<<"SingleCore A"<<endl; }

};

//单核B

class SingleCoreB: public SingleCore

{

public:

void Show() { cout<<"SingleCore B"<<endl; }

};

//唯一的工厂，可以生产两种型号的处理器核，在内部判断

class Factory

{

public:

SingleCore* CreateSingleCore(enum CTYPE ctype)

{

if(ctype == COREA) //工厂内部判断

return new SingleCoreA(); //生产核A

else if(ctype == COREB)

return new SingleCoreB(); //生产核B

else

return NULL;

}

};

这样设计的主要缺点之前也提到过，就是要增加新的核类型时，就需要修改工厂类。这就违反了开放封闭原则：软件实体（类、模块、函数）可以扩展，但是不可修改。于是，工厂方法模式出现了。所谓工厂方法模式，是指定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。

听起来很抽象，还是以刚才的例子解释。这家生产处理器核的产家赚了不少钱，于是决定再开设一个工厂专门用来生产B型号的单核，而原来的工厂专门用来生产A型号的单核。这时，客户要做的是找好工厂，比如要A型号的核，就找A工厂要；否则找B工厂要，不再需要告诉工厂具体要什么型号的处理器核了。下面给出一个实现方案。

[cpp] view
plain copy

print?

class SingleCore

{

public:

virtual void Show() = 0;

};

//单核A

class SingleCoreA: public SingleCore

{

public:

void Show() { cout<<"SingleCore A"<<endl; }

};

//单核B

class SingleCoreB: public SingleCore

{

public:

void Show() { cout<<"SingleCore B"<<endl; }

};

class Factory

{

public:

virtual SingleCore* CreateSingleCore() = 0;

};

//生产A核的工厂

class FactoryA: public Factory

{

public:

SingleCoreA* CreateSingleCore() { return new SingleCoreA; }

};

//生产B核的工厂

class FactoryB: public Factory

{

public:

SingleCoreB* CreateSingleCore() { return new SingleCoreB; }

};

工厂方法模式也有缺点，每增加一种产品，就需要增加一个对象的工厂。如果这家公司发展迅速，推出了很多新的处理器核，那么就要开设相应的新工厂。在C++实现中，就是要定义一个个的工厂类。显然，相比简单工厂模式，工厂方法模式需要更多的类定义。

既然有了简单工厂模式和工厂方法模式，为什么还要有抽象工厂模式呢？它到底有什么作用呢？还是举这个例子，这家公司的技术不断进步，不仅可以生产单核处理器，也能生产多核处理器。现在简单工厂模式和工厂方法模式都鞭长莫及。抽象工厂模式登场了。它的定义为提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。具体这样应用，这家公司还是开设两个工厂，一个专门用来生产A型号的单核多核处理器，而另一个工厂专门用来生产B型号的单核多核处理器，下面给出实现的代码。

[cpp] view
plain copy

print?

//单核

class SingleCore

{

public:

virtual void Show() = 0;

};

class SingleCoreA: public SingleCore

{

public:

void Show() { cout<<"Single Core A"<<endl; }

};

class SingleCoreB :public SingleCore

{

public:

void Show() { cout<<"Single Core B"<<endl; }

};

//多核

class MultiCore

{

public:

virtual void Show() = 0;

};

class MultiCoreA : public MultiCore

{

public:

void Show() { cout<<"Multi Core A"<<endl; }

};

class MultiCoreB : public MultiCore

{

public:

void Show() { cout<<"Multi Core B"<<endl; }

};

//工厂

class CoreFactory

{

public:

virtual SingleCore* CreateSingleCore() = 0;

virtual MultiCore* CreateMultiCore() = 0;

};

//工厂A，专门用来生产A型号的处理器

class FactoryA :public CoreFactory

{

public:

SingleCore* CreateSingleCore() { return new SingleCoreA(); }

MultiCore* CreateMultiCore() { return new MultiCoreA(); }

};

//工厂B，专门用来生产B型号的处理器

class FactoryB : public CoreFactory

{

public:

SingleCore* CreateSingleCore() { return new SingleCoreB(); }

MultiCore* CreateMultiCore() { return new MultiCoreB(); }

};

至此，工厂模式介绍完了。利用Rational Rose 2003软件，给出三种工厂模式的UML图，加深印象。

简单工厂模式的UML图：



工厂方法的UML图：



抽象工厂模式的UML图：



本人享有博客文章的版权，转载请标明出处 http://blog.csdn.net/wuzhekai1985

另一篇文章

转自http://blog.csdn.net/lh844386434/article/details/14518243

工厂模式是个系列，分为简单工厂模式， 工厂方法模式， 抽象工厂模式，这三种模式也非常常用。这些模式最最经典的就例子就是设计计算器。

简单工厂模式

严格的说，简单工厂模式并不是23种常用的设计模式之一，它只算工厂模式的一个特殊实现。简单工厂模式在实际中的应用相对于其他2个工厂模式用的还是相对少得多，因为它只适应很多简单的情况，最最重要的是它违背了我们在概述中说的开放-封闭原则。因为每次你要新添加一个功能，都需要在生switch-case 语句（或者if-else 语句）中去修改代码，添加分支条件。

简单工厂模式角色分配：

Creator（产品创建者）

简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。

Product （ 产品抽象类）

简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。

Concrete Product （具体产品）

是简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。

简单工厂模式uml图：



考虑下面一个事例： 加入你是一个商人，你做的的是手机生意。现在你生产Android 手机和iphone等，考虑到以后你可能还会生产其他手机例如ubuntu手机。假定你选择了简单工厂模式来实现。那么显然，我们需要所有产品的抽象基类（Product）
即是Phone类：

[cpp] view
plain copy

class Phone

{

public:

virtual ~Phone(){};//在删除的时候防止内存泄露

virtual void call(string number) = 0;

};

然后我们需要具体的产品类 Concrete Product： AndroidPhone 和 IosPhone

[cpp] view
plain copy

class AndroidPhone : public Phone

{

public:

void call(string number){ cout<<"AndroidPhone is calling..."<<endl;}

};

class IosPhone : public Phone

{

public:

void call(string number) { cout<<"IosPhone is calling..."<<endl;}

};

最后我们需要Creator

[cpp] view
plain copy

class PhoneFactory

{

public:

Phone* createPhone(string phoneName)

{

if(phoneName == "AndroidPhone")

{

return new AndroidPhone();

}else if(phoneName == "IosPhone")

{

return new IosPhone();

}

return NULL;

}

};

客户端这样实现：

[cpp] view
plain copy

void main()

{

PhoneFactor factory;

Phone* myAndroid = factory.createPhone("AndroidPhone");

Phone* myIPhone = factory.createPhone("IosPhone");

if(myAndroid)

{

myAndroid->call("123");

delete myAndroid;

myAndroid = NULL;

}

if(myIPhone)

{

myIPhone->call("123");

delete myIPhone;

myIPhone = NULL;

}

}

这就是简单工厂方法，把所有的创建交给creator,creator 通过switch-case(或者if-else)语句来选择具体创建的对象。简单明了。但是就如上面所说，它最致命的问题的违背了开放-封闭原则。每次你要新添加一个功能，都要修改factor里面的createPhone代码。 但是工厂方法模式可以解决这个问题。

工厂方法模式

个人觉得工厂方法模式在工厂模式家族中是用的最多模式。上面说过了，如果简单工厂模式，要添加一个新功能，比如我现在要增加WinPhone 的生产，那么我要修改PhoneFactory中的createPhone 中的分支判断条件。这违背了开放-封闭原则，那为什么不能将创建方法放到子类中呢？
工厂方法的定义 就是： 定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到其子类。

工厂方法模式角色：
抽象工厂(Creator)角色：是工厂方法模式的核心，与应用程序无关。任何在模式中创建的对象的工厂类必须实现这个接口。

具体工厂(Concrete Creator)角色：这是实现抽象工厂接口的具体工厂类，包含与应用程序密切相关的逻辑，并且受到应用程序调用以创建产品对象。

抽象产品(Product)角色：工厂方法模式所创建的对象的超类型，也就是产品对象的共同父类或共同拥有的接口。

具体产品(Concrete Product)角色：这个角色实现了抽象产品角色所定义的接口。某具体产品有专门的具体工厂创建，它们之间往往一一对应。
工厂方法模式uml图：



看定义看的晕乎乎的？那么我们来看代码：
产品接口，以及其相应的子类。

[cpp] view
plain copy

class Phone

{

public:

virtual ~Phone(){};//在删除的时候防止内存泄露

virtual void call(string number) = 0;

};

class AndroidPhone : public Phone

{

public:

void call(string number){ cout<<"AndroidPhone is calling..."<<endl;}

};

class IosPhone : public Phone

{

public:

void call(string number) { cout<<"IosPhone is calling..."<<endl;}

};

上面这个和简单工厂方法还是一样的。接下来不一样的来了...

[cpp] view
plain copy

class PhoneFactory

{

public:

virtual ~PhoneFactory(){};

virtual Phone* createPhone() = 0;

};

class AndroidPhoneFactory : public PhoneFactory

{

public:

virtual Phone* createPhone()

{

return new AndroidPhone();

}

};

class IosPhoneFactory : public PhoneFactory

{

public:

virtual Phone* createPhone()

{

return new IosPhone();

}

};

工厂方法将PhoneFactory抽象成了基类，PhoneFactory的createPhone不在像以前那样将所有的判断塞到里面。而是改由其子类来实现创建功能，这感觉就是权力下放。
客户端：

[cpp] view
plain copy

void main()

{

PhoneFactory* androidCreator = new AndroidPhoneFactory();

PhoneFactory* iosCreator = new IosPhoneFactory();

Phone* myAndroid = androidCreator->createPhone();

Phone* myIPhone = iosCreator->createPhone();

if(myAndroid)

{

myAndroid->call("123");

delete myAndroid;

myAndroid = NULL;

}

if(myIPhone)

{

myIPhone->call("123");

delete myIPhone;

myIPhone = NULL;

}

delete androidCreator;

delete iosCreator;

}

在工厂方法模式中，核心工厂类不在负责产品的创建，而是将具体的创建工作交给子类去完成。也就是后所这个核心工厂仅仅只是提供创建的接口，具体实现方法交给继承它的子类去完成。当我们的系统需要增加其他新功能时，只需要继承PhoneFactory这个类，并且实现createPhone接口。 不需要对原工厂PhoneFactory进行任何修改，这样很好地符合了“开放-封闭“原则。
虽然工厂方法模式满足了"开放-封闭”原则，但是这个模式也仍然有缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，是的系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。

抽象工厂模式

在工厂方法模式中，其实我们有一个潜在意识的意识。那就是我们生产的都是同一类产品，例如我们生产的都是手机！那么现在假如现在我们又要生产平板了了呢？那么就要用到抽象工厂模式。我抽象工厂模式也用的比较多在工厂模式家族中，仅次于工厂方法模式。在了解抽象工厂模式之前，还是老生常谈的理清下产品等级结构和产品簇的概念。下面的图还是老图。但是我讲讲我的理解：



产品等级结构：产品的等级结构也就是产品的继承结构。我理解就是同一类产品，比如手机是一个系列，有android手机，ios手机，win手机，那么这个抽象类手机和他的子类就构成了一个产品等级结构。那其他的平板显然不是和手机一个系列的，一个平板，一个是手机，所以他们是不同的产品等级结构。

产品族: 在抽象工厂模式中，产品族是指由同一个工厂生产的，位于不同产品等级结构中的一组产品。比如分为android产品，和ios产品。其中一个ios产品包含ios手机和ios平板。显然ios手机和ios平板不是同一个产品等级结构的，因为一个是手机，一个是平板。但他们是同一个产品簇---都是ios产品。
希望大家通过上面的例子大家明白了这两个概念。

抽象工厂模式的Uml 图：



接着上面的话题，现在假如我要增加对平板的支持，那么我们肯定先添加两个产品等级结构，一个是手机，一个是平板：

[cpp] view
plain copy

//产品等级结构--手机

class Phone

{

public:

virtual ~Phone(){};//在删除的时候防止内存泄露

virtual void call(string number) = 0;

};

class AndroidPhone : public Phone

{

public:

void call(string number){ cout<<"AndroidPhone is calling..."<<endl; }

};

class IosPhone : public Phone

{

public:

void call(string number) { cout<<"IosPhone is calling..."<<endl; }

};

//产品等级结构--平板

class Pad

{

public:

virtual ~Pad(){};

virtual void playMovie() = 0;

};

class AndroidPad : public Pad

{

public:

virtual void playMovie(){ cout<<"AndriodPad is playing movie..."<<endl; }

};

class IosPad : public Pad

{

public:

virtual void playMovie(){ cout<<"IosPad is playing movie..."<<endl; }

};

然后具体的工厂我们整个工厂是生产移动设备的所以我们取名为MobileFactory,然后工厂可以生产平板和手机，故有了createPhone 和createPad两个接口。

[cpp] view
plain copy

class MobileFactory

{

public:

virtual ~MobileFactory(){};

virtual Phone* createPhone() = 0;

virtual Pad* createPad() = 0;

};

接着是 android 产品簇 的工厂类，负责生产android 的手机和平板：

[cpp] view
plain copy

class AndroidFactory : public MobileFactory

{

public:

Phone* createPhone()

{

return new AndroidPhone();

}

Pad* createPad()

{

return new AndroidPad();

}

};

接着是ios的产品簇的工厂类，负责生产ios的手机和平板：

[cpp] view
plain copy

class IosFactory : public MobileFactory

{

public:

Phone* createPhone()

{

return new IosPhone();

}

Pad* createPad()

{

return new IosPad();

}

};

最后客户端这样实现：

[cpp] view
plain copy

void main()

{

MobileFactory* androidCreator = new AndroidFactory();

MobileFactory* iosCreator = new IosFactory();

Phone* myAndroidPhone = androidCreator->createPhone();

Pad* myAndroidPad = androidCreator->createPad();

Phone* myIosPhone = iosCreator->createPhone();

Pad* myIosPad = iosCreator->createPad();

myAndroidPhone->call("123");

myAndroidPad->playMovie();

myIosPhone->call("123");

myIosPad->playMovie();

//这里没有做释放和判断，请自己判断和释放

}

总结：
抽象工厂模式适用于那些有多种产品的产品簇，并且每次使用其中的某一产品簇的产品。
缺点 ： 抽象工厂模式的添加新功能也非常麻烦，比工厂方法模式都还要复杂的多。
优点： 当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。