Factory 模式-GoF 23 种设计模式精解系列-附 C++实现源码

前言

尊重原创，本系列文本解析部分主要基于Candidate for Master’s Degree School of Computer Wuhan University的K_Eckel（[email protected]）《设计模式精解-GoF 23 种设计模式解析附 C++实现源码》。为了避免重造轮子，本系列博文对源码在ubuntu16.04下做了验证并上传到了gitee，再次感谢。

如有问题，可邮件联系我([email protected])并共同探讨解决方案。

Factory模式简介：

简单工厂模式是属于创建型模式，又叫做静态工厂方法(static Factory Method)模式，简单工厂模式是由一个工厂对象决定创建出来哪一种产品类的实例.

简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一类产品类(这些产品类继承自一个父类或接口)的实例。打个比方——

假设有一个工厂，他能生产出A、B两种产品。当客户需要产品的时候一定要告诉工厂是哪种产品，是A还是B。当新增加一种新产品的时候，那么就要去修改工厂的类。

问题：

在面向对象系统设计中经常可以遇到以下的两类问题:

为了提高内聚(Cohesion)和松耦合(Coupling),我们经常会抽象出一些类的公共接口以形成抽象基类或者接口。这样我们可以通过声明一个指向基类的指针来指向实际的子类实现,达到了多态的目的。这里很容易出现的一个问题：n 多的子类继承自抽象基类,我们不得不在每次要用到子类的地方就编写诸如 new ×××;的代码。这里带来两个问题：1)客户程序员必须知道实际子类的名称(当系统复杂后,命名将是一个很不好处理的问题,为了处理可能的名字冲突,有的命名可能并不是具有很好的可读性和可记忆性,就姑且不论不同程序员千奇百怪的个人偏好了);2)程序的扩展性和维护变得越来越困难。
还有一种情况就是在父类中并不知道具体要实例化哪一个具体的子类。这里的意思为:假设我们在类 A 中要使用到类 B, B 是一个抽象父类,在 A 中并不知道具体要实例化那一个 B 的子类,但是在类 A 的子类 D 中是可以知道的。在 A 中我们没有办法直接使用类似于 new ×××的语句,因为根本就不知道×××是什么。

以上两个问题也就引出了 Factory 模式的两个最重要的功能:
1)定义创建对象的接口,封装了对象的创建;
2)使得具体化类的工作延迟到了子类中。

模式选择

我们通常使用 Factory 模式来解决上面给出的两个问题。在第一个问题中,我们经常就是声明一个创建对象的接口,并封装了对象的创建过程。Factory 这里类似于一个真正意义上的工厂(生产对象)。在第二个问题中,我们需要提供一个对象创建对象的接口,并在子类中提供其具体实现(因为只有在子类中可以决定到底实例化哪一个类)。

第一中情况的 Factory 的结构示意图为:

图 1:Factory 模式结构示意图 1

图 1 所谓的 Factory 模式经常在系统开发中用到,但是这并不是 Factory 模式的最大威力所在(因为这可以通过其他方式解决这个问题)。Factory 模式不单是提供了创建对象的接口,其最重要的是延迟了子类的实例化(第二个问题),以下是这种情况的一个 Factory 的结构示意图:

图 2:Factory 模式结构示意图 1

图 2 中 Factory 模式的应用并不是只是为了封装对象的创建,而是要把对象的创建放到子类中实现:Factory 中只是提供了对象创建的接口,其实现将放在 Factory 的子类ConcreteFactory 中进行。这是图 2 和图 1 的区别所在。

实现

完整代码示例(code)

Factory 模式的实现比较简单,这里为了方便初学者的学习和参考,将给出完整的实现代码(所有代码采用 C++实现,并在 Visual Studio Code，Version: 1.36.1 下测试运行)。

源码gitee地址：点击这里

代码目录结构：

patten@patten-hp:~/workspace/others/cpp/src$ tree ../
../
├── include
│   ├── Factory.h
│   └── Product.h
└── src
    ├── Factory.cpp
    ├── main.cpp
    └── Product.cpp

2 directories, 5 files

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(/* args */);
  ~ConcreteFactory();
  Product* CreateProduct();

 protected:
 private:
  /* data */
};
#endif //~_FACTORY_H_

Factory.cpp

//Factory.cpp

#include "../include/Factory.h"
#include "../include/Product.h"
#include <iostream>

using namespace std;

Factory::Factory(){}

Factory::~Factory(){};

ConcreteFactory::ConcreteFactory(){
    cout<<"ConcreteFactory in Factory.cpp"<<endl;
}

ConcreteFactory::~ConcreteFactory(){

}

Product* ConcreteFactory::CreateProduct(){
    return new ConcreteProduct();
}

Product.h：

// Product.h
#ifndef _PRODUCT_H_
#define _PRODUCT_H_

class Product {
 public:
  virtual ~Product() = 0;

 protected:
  Product();

 private:
};

class ConcreteProduct : public Product {
 public:
  ~ConcreteProduct();
  ConcreteProduct();

 protected:
 private:
};
#endif  //~_PRODUCT_H_

Product.cpp

// Product.cpp

#include "../include/Product.h"
#include <iostream>

using namespace std;

Product::Product() {}

Product::~Product() {}

ConcreteProduct::ConcreteProduct() { cout << "ConcreteProduct in Product.cpp" << endl; }

ConcreteProduct::~ConcreteProduct() {}

main.cpp

// main.cpp
#include <iostream>
#include "../include/Factory.h"
#include "../include/Product.h"
using namespace std;

int main(int argc, char* argv[]) {
  Factory* fac = new ConcreteFactory();
  Product* p = fac->CreateProduct();

  return 0;
}

代码说明

示例代码中给出的是 Factory 模式解决父类中并不知道具体要实例化哪一个具体的子类的问题,至于为创建对象提供接口问题,可以由 Factory 中附加相应的创建操作例如Create***Product()即可。具体请参加讨论内容。

编译运行结果：

patten@patten-hp:~/workspace/others/cpp/src$ 
patten@patten-hp:~/workspace/others/cpp/src$ g++ *.cpp -std=c++11
patten@patten-hp:~/workspace/others/cpp/src$ ./a.out 
ConcreteFactory in Factory.cpp
ConcreteProduct in Product.cpp
patten@patten-hp:~/workspace/others/cpp/src$

讨论

Factory 模式在实际开发中应用非常广泛,面向对象的系统经常面临着对象创建问题:要创建的类实在是太多了。而 Factory 提供的创建对象的接口封装(第一个功能),以及其将类的实例化推迟到子类(第二个功能)都部分地解决了实际问题。一个简单的例子就是笔者开开发 VisualCMCS 系统的语义分析过程中,由于要为文法中的每个非终结符构造一个类处理,因此这个过程中对象的创建非常多,采用 Factory 模式后系统可读性性和维护都变得elegant 许多。

Factory 模式也带来至少以下两个问题:

如果为每一个具体的 ConcreteProduct 类的实例化提供一个函数体,那么我们可能不得不在系统中添加了一个方法来处理这个新建的 ConcreteProduct,这样 Factory 的接口永远就不肯能封闭(Close)。当然我们可以通过创建一个 Factory 的子类来通过多态实现这一点,但是这也是以新建一个类作为代价的。
在实现中我们可以通过参数化工厂方法,即给 FactoryMethod()传递一个参数用以决定是创建具体哪一个具体的 Product(实际上笔者在 VisualCMCS 中也正是这样做的)。当然也可以通过模板化避免 1)中的子类创建子类,其方法就是将具体 Product 类作为模板参数,实现起来也很简单。

可以看出,Factory 模式对于对象的创建给予开发人员提供了很好的实现策略,但是
Factory 模式仅仅局限于一种类(就是说 Product 是一类,有一个共同的基类),如果我们要
为不同类的类提供一个对象创建的接口,那就要用 AbstractFactory 模式了。

前言

目录

创建型模式(Creating Pattern)

结构型模式（Structrual Pattern）

行为型模式（Behavioral Pattern）