设计模式（五）简单工厂模式+工厂方法模式

　　

　　在面向对象编程中, 最通常的方法是一个new操作符产生一个对象实例,new操作符就是用来构造对象实例的。但是在一些情况下, new操作符直接生成对象会带来一些问题。举例来说, 许多类型对象的创造需要一系列的步骤: 你可能需要计算或取得对象的初始设置; 选择生成哪个子对象实例; 或在生成你需要的对象之前必须先生成一些辅助功能的对象。 在这些情况,新对象的建立就是一个 “过程”，不仅是一个操作，像一部大机器中的一个齿轮传动。

模式的问题：你如何能轻松方便地构造对象实例，而不必关心构造对象实例的细节和复杂过程呢？

解决方案：建立一个工厂来创建对象

实现：

一、引言

1）还没有工厂时代：假如还没有工业革命，如果一个客户要一款宝马车,一般的做法是客户去创建一款宝马车，然后拿来用。

2）简单工厂模式：后来出现工业革命。用户不用去创建宝马车。因为客户有一个工厂来帮他创建宝马.想要什么车，这个工厂就可以建。比如想要320i系列车。工厂就创建这个系列的车。即工厂可以创建产品。

3）工厂方法模式时代：为了满足客户，宝马车系列越来越多，如320i，523i,30li等系列一个工厂无法创建所有的宝马系列。于是由单独分出来多个具体的工厂。每个具体工厂创建一种系列。即具体工厂类只能创建一个具体产品。但是宝马工厂还是个抽象。你需要指定某个具体的工厂才能生产车出来。

4）抽象工厂模式时代：随着客户的要求越来越高，宝马车必须配置空调。于是这个工厂开始生产宝马车和需要的空调。

　　最终是客户只要对宝马的销售员说：我要523i空调车，销售员就直接给他523i空调车了。而不用自己去创建523i空调车宝马车.

　　这就是工厂模式。

二、分类

　　工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。 　　

工厂模式可以分为三类： 

　　1）简单工厂模式（Simple Factory） 
　　2）工厂方法模式（Factory Method） 
　　3）抽象工厂模式（Abstract Factory） 

　　这三种模式从上到下逐步抽象，并且更具一般性。 
　　GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与抽象工厂模式（Abstract Factory）。将简单工厂模式（Simple Factory）看为工厂方法模式的一种特例，两者归为一类。 

三、还没有工厂时代

　　从无到有。客户自己创建宝马车，然后拿来用。

　　

/*
@author CodingMengmeng
@datetime:2016-9-29 17:27:51
@description:a client create a BMW car by himself.
*/
#include <iostream>
#include "tchar.h"
using namespace std;

class CBMW320{
public:
    CBMW320()
    {
        cout << "Produce --> BMW320"<< endl;
    }
    ~CBMW320(){};

};

class CBMW523{
public:
    CBMW523()
    {
        cout << "Produce --> BMW523" << endl;
    }
    ~CBMW523(){};
};

int _tmain(int agrc, _TCHAR** argv)
{
    CBMW523* bmw523 = new CBMW523();
    CBMW320* bmw320 = new CBMW320();
    return 0;
}

运行结果：

　　

说明：客户需要知道怎么去创建一款车，客户和车就紧密耦合在一起了.为了降低耦合,就出现了工厂类,把创建宝马的操作细节都放到了工厂里面去,客户直接使用工厂的创建工厂方法,传入想要的宝马车型号就行了,而不必去知道创建的细节。这就是工业革命：简单工厂模式

四、简单工厂模式

　　即我们建立一个工厂类方法来制造新的对象。如图：

　　

/*
@author CodingMengmeng
@datetime:2016-9-29 17:57:34
@description:Simple Factory Pattern.
*/
#include <iostream>
#include "tchar.h"
using namespace std;

//抽象产品角色
class CBMW{
public:
    CBMW(){}
    ~CBMW(){}
};

//具体产品角色
class CBMW320 :public CBMW{
public:
    CBMW320()
    {
        cout << "Produce -->BMW320" << endl;
    }
    ~CBMW320(){};
};

class CBMW523 :public CBMW{
public:
    CBMW523()
    {
        cout << "Produce -->BMW523" << endl;
    }
    ~CBMW523(){};

};

//工厂类角色
class CFactory{
public:
    CFactory(){};
    ~CFactory(){};
    CBMW* createBMW(int type)
    {
        switch (type){
        case 320:    return new CBMW320();
        case 523:    return new CBMW523();

        default:
            break;
        }
        return NULL;
    }
};

//客户操作
int _tmain(int argc, _TCHAR** argv)
{
    CFactory* factory = new CFactory();
    CBMW* bmw320 = factory->createBMW(320);
    CBMW* bmw523 = factory->createBMW(523);

    return 0;
}

运行结果：

　　

　　简单工厂模式又称为静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。

　　先来看看它的组成：

　　 1) 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑，用来创建产品
       2) 抽象产品角色：它一般是具体产品继承的父类或者实现的接口。         
       3) 具体产品角色：工厂类所创建的对象就是此角色的实例。在C++中由一个继承自抽象产品类的子类来实现。　　

　　下面我们从开闭原则（对扩展开放；对修改封闭）上来分析下简单工厂模式。当客户不再满足现有的车型号的时候，想要一种速度快的新型车，只要这种车符合抽象产品制定的合同，那么只要通知工厂类知道就可以被客户使用了。所以对产品部分来说，它是符合开闭原则的；但是工厂部分好像不太理想，因为每增加一种新型车，都要在工厂类中增加相应的创建业务逻辑（createBMW(int type)方法需要新增case），这显然是违背开闭原则的。可想而知对于新产品的加入，工厂类是很被动的。对于这样的工厂类，我们称它为全能类或者上帝类。 

　　我们举的例子是最简单的情况，而在实际应用中，很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品，所以这可能会把我们的上帝累坏了，也累坏了我们这些程序员。
　　于是工厂方法模式作为救世主出现了。 工厂类定义成了接口,而每新增的车种类型,就增加该车种类型对应工厂类的实现,这样工厂的设计就可以扩展了,而不必去修改原来的代码。

五、工厂方法模式

　　工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。

　　工厂模式使用的频率非常高，其定义为：

　　 Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses。定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

　　工厂方法模式的通用类图如下图所示。

　　　

工厂方法模式组成：

1）抽象工厂角色：这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在C++中它由抽象类来实现。

2）具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。

3）抽象产品角色：它是具体产品继承的父类或者是实现的接口。在C++中一般由抽象类来实现。

4）具体产品角色：所创建的对象就是此角色的实例。在C++中由具体的类来实现。

　　工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说，这样便分担了对象承受的压力；而且这样使得结构变得灵活 起来——当有新的产品产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就可以被客户使用，而不必去修改任何已有的代码。可以看出工厂角色的结构也是符合开闭原则的！

代码如下：

/*
@author CodingMengmeng
@datetime:2016-9-29 18:25:08
@description:Factory Method Pattern.
*/
#include <iostream>
#include "tchar.h"
using namespace std;

//抽象产品角色
//定义了一个抽象类
class CBMW{
public:
    CBMW(){}
    ~CBMW(){}
    virtual void getStyle(void) = 0;
};

//具体产品角色
//子类1
class CBMW320 :public CBMW{
public:
    CBMW320()
    {
    }
    ~CBMW320(){};
    void getStyle(void)
    {
        cout << "Produce -->BMW320" << endl;
    }
};
//子类2
class CBMW523 :public CBMW{
public:
    CBMW523()
    {
    }
    ~CBMW523(){};
    void getStyle(void)
    {
        cout << "Produce -->BMW523" << endl;
    }

};

//抽象工厂角色
class CFactory{
public:
    CFactory()
    {
    }
    ~CFactory()
    {
    }
    virtual CBMW* createBMW(void) = 0;
    
};

//具体工厂角色
//工厂1
class CFactoryBMW320 :public CFactory{
public:
    CFactoryBMW320()
    {
    }
    ~CFactoryBMW320()
    {
    }
    
    CBMW* createBMW(void)
    {
        return new CBMW320();
    }
};

//工厂2
class CFactoryBMW523 :public CFactory{
public:
    CFactoryBMW523()
    {
    }
    ~CFactoryBMW523()
    {
    }
    CBMW* createBMW(void)
    {
        return new CBMW523();
    }
};
//客户操作
int _tmain(int argc, _TCHAR** argv)
{
    CFactory* factoryBMW320 = new CFactoryBMW320();//new一个生产BMW320的工厂
    CBMW* bmw320 = factoryBMW320->createBMW();//生产BMW320
    bmw320->getStyle();

    CFactory* factoryBMW523 = new CFactoryBMW523();//new一个生产BMW523的工厂
    CBMW* bmw523 = factoryBMW523->createBMW();//生产BMW523
    bmw523->getStyle();

    return 0;
    
}

运行结果：

　　

六、总结

　　总的来说，工厂方法模式是一个很好的设计模式，它遵循了一个“尽可能让事情保持抽象”的原则，松耦合的设计原则也能够很好地符合开闭原则，将类的实例化推迟到子类，同时也摒弃了简单工厂模式的缺点。

　　但是同时工厂模式也有一些缺点，每次我们为工厂方法添加新的产品时就要编写一个新的产品类，同时还要引入抽象层，当产品种类非常多时，会出现大量的与之对应的工厂对象，这必然会导致类结构的复杂化，所以对于简单的情况下，使用工厂方法模式就需要考虑是不是有些“重”了。

参考：http://blog.csdn.net/jason0539/article/details/23020989