设计模式C++实现（1）——(创建型)工厂模式

男娘i 2022-06-03 22:57 137阅读 0赞

**一 工厂模式**

软件领域中的设计模式为开发人员提供了一种使用专家设计经验的有效途径。设计模式中运用了面向对象编程语言的重要特性：封装、继承、多态，真正领悟设计模式的精髓是可能一个漫长的过程，需要大量实践经验的积累。最近看设计模式的书，对于每个模式，用C++写了个小例子，加深一下理解。主要参考《大话设计模式》和《设计模式:可复用面向对象软件的基础》两本书。本文介绍工厂模式的实现。

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

\[cpp\]  [view plain][]  [copy][view plain]

1.  **enum** CTYPE \{COREA, COREB\};     
2.  **class** SingleCore    
3.  \{    
4.  **public**:    
5.      **virtual** **void** Show() = 0;  
6.  \};    
7.  //单核A    
8.  **class** SingleCoreA: **public** SingleCore    
9.  \{    
10. **public**:    
11.     **void** Show() \{ cout<<"SingleCore A"<<endl; \}    
12. \};    
13. //单核B    
14. **class** SingleCoreB: **public** SingleCore    
15. \{    
16. **public**:    
17.     **void** Show() \{ cout<<"SingleCore B"<<endl; \}    
18. \};    
19. //唯一的工厂，可以生产两种型号的处理器核，在内部判断    
20. **class** Factory    
21. \{    
22. **public**:     
23.     SingleCore\* CreateSingleCore(**enum** CTYPE ctype)    
24.     \{    
25.         **if**(ctype == COREA) //工厂内部判断    
26.             **return** **new** SingleCoreA(); //生产核A    
27.         **else** **if**(ctype == COREB)    
28.             **return** **new** SingleCoreB(); //生产核B    
29.         **else**    
30.             **return** NULL;    
31.     \}    
32. \};

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

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

\[cpp\]  [view plain][]  [copy][view plain]

1.  **class** SingleCore    
2.  \{    
3.  **public**:    
4.      **virtual** **void** Show() = 0;  
5.  \};    
6.  //单核A    
7.  **class** SingleCoreA: **public** SingleCore    
8.  \{    
9.  **public**:    
10.     **void** Show() \{ cout<<"SingleCore A"<<endl; \}    
11. \};    
12. //单核B    
13. **class** SingleCoreB: **public** SingleCore    
14. \{    
15. **public**:    
16.     **void** Show() \{ cout<<"SingleCore B"<<endl; \}    
17. \};    
18. **class** Factory    
19. \{    
20. **public**:    
21.     **virtual** SingleCore\* CreateSingleCore() = 0;  
22. \};    
23. //生产A核的工厂    
24. **class** FactoryA: **public** Factory    
25. \{    
26. **public**:    
27.     SingleCoreA\* CreateSingleCore() \{ **return** **new** SingleCoreA; \}    
28. \};    
29. //生产B核的工厂    
30. **class** FactoryB: **public** Factory    
31. \{    
32. **public**:    
33.     SingleCoreB\* CreateSingleCore() \{ **return** **new** SingleCoreB; \}    
34. \};

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

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

\[cpp\]  [view plain][]  [copy][view plain]

1.  //单核    
2.  **class** SingleCore     
3.  \{    
4.  **public**:    
5.      **virtual** **void** Show() = 0;  
6.  \};    
7.  **class** SingleCoreA: **public** SingleCore      
8.  \{    
9.  **public**:    
10.     **void** Show() \{ cout<<"Single Core A"<<endl; \}    
11. \};    
12. **class** SingleCoreB :**public** SingleCore    
13. \{    
14. **public**:    
15.     **void** Show() \{ cout<<"Single Core B"<<endl; \}    
16. \};    
17. //多核    
18. **class** MultiCore      
19. \{    
20. **public**:    
21.     **virtual** **void** Show() = 0;  
22. \};    
23. **class** MultiCoreA : **public** MultiCore      
24. \{    
25. **public**:    
26.     **void** Show() \{ cout<<"Multi Core A"<<endl; \}    
27.     
28. \};    
29. **class** MultiCoreB : **public** MultiCore      
30. \{    
31. **public**:    
32.     **void** Show() \{ cout<<"Multi Core B"<<endl; \}    
33. \};    
34. //工厂    
35. **class** CoreFactory      
36. \{    
37. **public**:    
38.     **virtual** SingleCore\* CreateSingleCore() = 0;  
39.     **virtual** MultiCore\* CreateMultiCore() = 0;  
40. \};    
41. //工厂A，专门用来生产A型号的处理器    
42. **class** FactoryA :**public** CoreFactory    
43. \{    
44. **public**:    
45.     SingleCore\* CreateSingleCore() \{ **return** **new** SingleCoreA(); \}    
46.     MultiCore\* CreateMultiCore() \{ **return** **new** MultiCoreA(); \}    
47. \};    
48. //工厂B，专门用来生产B型号的处理器    
49. **class** FactoryB : **public** CoreFactory    
50. \{    
51. **public**:    
52.     SingleCore\* CreateSingleCore() \{ **return** **new** SingleCoreB(); \}    
53.     MultiCore\* CreateMultiCore() \{ **return** **new** MultiCoreB(); \}    
54. \};

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

简单工厂模式的UML图：

![0_13126164442m1F.gif][]

工厂方法的UML图：

![0_1312616449DlvG.gif][]

抽象工厂模式的UML图：

![0_1312616458PVae.gif][]

**二 关于工厂模式的作用。为什么要用工厂模式？**  
   
 工厂模式的实现方式和原理都不难理解和掌握。但是，在学习完之后，发现网上给的例子，根本体现不了工厂模式的作用。先不说存在有的例子本身就是错误的，主要是例子中的代码太简单，可以说没必要用工厂模式，只不过是为了说明实现方式和原理。所以，会产生一种错觉：还不如直接new 一个对象来的方便，有效。  
  
的确，设计模式本身就有其适用的场景，并不是滥用的，否则还不如不用。  
  
现在，我记录一下在翻阅一些资料后，自己的理解。  
  
首先，工厂模式是为了解耦：把对象的创建和使用的过程分开。就是Class A 想调用 Class B ，那么A只是调用B的方法，而至于B的实例化，就交给工厂类。  
  
其次，工厂模式可以降低代码重复。如果创建对象B的过程都很复杂，需要一定的代码量，而且很多地方都要用到，那么就会有很多的重复代码。我们可以这些创建对象B的代码放到工厂里统一管理。既减少了重复代码，也方便以后对B的创建过程的修改维护。（当然，我个人觉得也可以把这些创建过程的代码放到类的构造函数里，同样可以降低重复率，而且构造函数本身的作用也是初始化对象。不过，这样也会导致构造函数过于复杂，做的事太多，不符合java 的设计原则。）  
  
由于创建过程都由工厂统一管理，所以发生业务逻辑变化，不需要找到所有需要创建B的地方去逐个修正，只需要在工厂里修改即可，降低维护成本。同理，想把所有调用B的地方改成B的子类B1，只需要在对应生产B的工厂中或者工厂的方法中修改其生产的对象为B1即可，而不需要找到所有的new B（）改为new B1()。  
  
另外，因为工厂管理了对象的创建逻辑，使用者并不需要知道具体的创建过程，只管使用即可，减少了使用者因为创建逻辑导致的错误。  
  
  
举个例子：  
  
  
一个数据库工厂：可以返回一个数据库实例，可以是mysql，oracle等。  
  
  
这个工厂就可以把数据库连接需要的用户名，地址，密码等封装好，直接返回对应的数据库对象就好。不需要调用者自己初始化，减少了写错密码等等这些错误。调用者只负责使用，不需要管怎么去创建、初始化对象。  
  
  
还有，如果一个类有多个构造方法（构造的重写），我们也可以将它抽出来，放到工厂中，一个构造方法对应一个工厂方法并命名一个友好的名字，这样我们就不再只是根据参数的不同来判断，而是可以根据工厂的方法名来直观判断将要创建的对象的特点。这对于使用者来说，体验比较好。  
  
  
  
  
工厂模式适用的一些场景（不仅限于以下场景）：  
  
  
1. 对象的创建过程/实例化准备工作很复杂，需要初始化很多参数、查询数据库等。  
  
  
2.类本身有好多子类，这些类的创建过程在业务中容易发生改变，或者对类的调用容易发生改变。

**三 思考**

在所有的工厂模式中，我们都强调一点：两个类A和B之间的关系应该仅仅是A创建B或是A使用B，而不能两种关系都有。将对象的创建和使用分离，也使得系统更加符合“单一职责原则”，有利于对功能的复用和系统的维护。  
  
  
       此外，将对象的创建和使用分离还有一个好处：防止用来实例化一个类的数据和代码在多个类中到处都是，可以将有关创建的知识搬移到一个工厂类中，这在Joshua Kerievsky的《重构与模式》一书中有专门的一节来进行介绍。因为有时候我们创建一个对象不只是简单调用其构造函数，还需要设置一些参数，可能还需要配置环境，如果将这些代码散落在每一个创建对象的客户类中，势必会出现代码重复、创建蔓延的问题，而这些客户类其实无须承担对象的创建工作，它们只需使用已创建好的对象就可以了。此时，可以引入工厂类来封装对象的创建逻辑和客户代码的实例化/配置选项。  
  
  
      使用工厂类还有一个“不是特别明显的”优点，一个类可能拥有多个构造函数，而在Java、C\#等语言中构造函数名字都与类名相同，客户端只能通过传入不同的参数来调用不同的构造函数创建对象，从构造函数和参数列表中也许大家根本不了解不同构造函数所构造的产品的差异。但如果将对象的创建过程封装在工厂类中，我们可以提供一系列名字完全不同的工厂方法，每一个工厂方法对应一个构造函数，客户端可以以一种更加可读、易懂的方式来创建对象，而且，从一组工厂方法中选择一个意义明确的工厂方法，比从一组名称相同参数不同的构造函数中选择一个构造函数要方便很多。如图2所示：  
  
  
  
![20180514230249345][]  
  
  
       在图2中，矩形工厂类RectangleFactory提供了两个工厂方法createRectangle()和createSquare()，一个用于创建长方形，一个用于创建正方形，这两个方法比直接通过构造函数来创建长方形或正方形对象意义更加明确，也在一定程度上降低了客户端调用时出错的概率。  
      那么，有人可能会问，是否需要为设计中的每一个类都配备一个工厂类？答案是：具体情况具体分析。如果产品类很简单，而且不存在太多变数，其构造过程也很简单，此时无须为其提供工厂类，直接在使用之前实例化即可，例如Java语言中的String类，我们就无须为它专门提供一个StringFactory，这样做反而有点像杀鸡用牛刀，大材小用，而且会导致工厂泛滥，增加系统的复杂度。

**本文转自:**

**http://blog.csdn.net/wuzhekai1985/article/details/6660462**

**https://blog.csdn.net/kocscs123/article/details/53243847**

**https://blog.csdn.net/lovelion/article/details/7523392**

[view plain]: http://blog.csdn.net/wuzhekai1985/article/details/6660462#
[0_13126164442m1F.gif]: /images/20220604/49b0354190eb47c899535f35eaba589a.png
[0_1312616449DlvG.gif]: /images/20220604/db2aa365acf0455ebe361d7998655876.png
[0_1312616458PVae.gif]: /images/20220604/d450284f15c846f98e9850d34bb9a392.png
[20180514230249345]: /images/20220604/a349150cebf4461b9e4712f2c251668d.png