2021-09-08 14:35:02 +00:00
|
|
|
|
# 1.简单工厂模式简介
|
|
|
|
|
创建型模式关注对象的创建过程,在软件开发中应用非常广泛。创建型模式描述如何将对象的创建和使用分离,让用户在使用对象过程中无须关心对象的创建细节,从而降低系统耦合度,并且让系统易于修改和扩展。
|
|
|
|
|
|
|
|
|
|
简单工厂模式是最简单的设计模式之一,其实它并不属于Gof的23种设计模式,但应用也十分频繁,同时也是其余创建模式的基础,因此有必要先学习简单工厂模式。
|
|
|
|
|
|
|
|
|
|
## 1.1.简单工厂应用举例
|
2021-09-09 03:35:43 +00:00
|
|
|
|
![avatar](.//1.Picture//简单工厂.png)
|
2021-09-08 14:35:02 +00:00
|
|
|
|
什么是简单工厂模式呢?举个例子:如上图,一个体育用品生产厂(这即是一个工厂Factory),该工厂可以根据客户需求生产篮球、足球和排球。篮球、足球和排球被成为产品(Product),产品的名称可以被成为参数。**客户Jungle需要时可以向工厂提供产品参数,工厂根据产品参数生产对应产品,客户Jungle并不需要关心产品的生产过程细节**。
|
|
|
|
|
|
|
|
|
|
## 1.2.简单工厂基本实现流程
|
|
|
|
|
由上述例子,可以很容易总结出简单工厂的实现流程:
|
|
|
|
|
|
|
|
|
|
- 设计一个抽象产品类,它包含一些公共方法的实现;
|
|
|
|
|
- 从抽象产品类中派生出多个具体产品类,如篮球类、足球类、排球类,具体产品类中实现具体产品生产的相关代码;
|
|
|
|
|
- 设计一个工厂类,工厂类中提供一个生产各种产品的工厂方法,该方法根据传入参数(产品名称)创建不同的具体产品类对象;
|
|
|
|
|
- 客户只需调用工厂类的工厂方法,并传入具体产品参数,即可得到一个具体产品对象。
|
|
|
|
|
|
|
|
|
|
## 1.3.简单工厂定义
|
|
|
|
|
**简单工厂模式:**
|
|
|
|
|
```
|
|
|
|
|
定义一个简单工厂类,它可以根据参数的不同返回不同类的实例,被创建的实例通常都具有共同的父类
|
|
|
|
|
```
|
|
|
|
|
从简单工厂模式的定义和例子可以看出,在简单工厂模式中,大体上有3个角色:
|
|
|
|
|
- **工厂(Factory)**:根据客户提供的具体产品类的参数,创建具体产品实例;
|
|
|
|
|
- **抽象产品(AbstractProduct)**:具体产品类的基类,包含创建产品的公共方法;
|
|
|
|
|
- **具体产品(ConcreteProduct)**:抽象产品的派生类,包含具体产s品特有的实现方法,是简单工厂模式的创建目标。
|
|
|
|
|
简单工厂模式UML类图如下:
|
|
|
|
|
![avatar](.//1.Picture//简单工厂模式.png)
|
|
|
|
|
|
|
|
|
|
代码结构如下:
|
|
|
|
|
```
|
|
|
|
|
//抽象产品类AbstractProduct
|
|
|
|
|
class AbstractProduct
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
//抽象方法:
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
//具体产品类Basketball
|
|
|
|
|
class ConcreteProduct :public AbstractProduct
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
//具体实现方法
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
class Factory
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
AbstractProduct createProduct(string productName)
|
|
|
|
|
{
|
|
|
|
|
AbstractProduct pro = NULL;
|
|
|
|
|
if (productName == "ProductA"){
|
|
|
|
|
pro = new ProductA();
|
|
|
|
|
}
|
|
|
|
|
else if (productName == "ProductB"){
|
|
|
|
|
pro = new ProductB();
|
|
|
|
|
}
|
|
|
|
|
...
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
```
|
|
|
|
|
客户端在使用时,只需要创建一个工厂对象,调用工厂对象的createProduct方法,并传入所需要的产品参数,即可得到所需产品实例对象,而无需关心产品的创建细节。
|
|
|
|
|
|
|
|
|
|
# 3.简单工厂模式代码实例
|
|
|
|
|
考虑有以下一个场景:
|
|
|
|
|
```
|
|
|
|
|
Jungle想要进行户外运动,它可以选择打篮球、踢足球或者玩排球。它需要凭票去体育保管室拿,票上写着一个具体球类运动的名字,比如“篮球”。体育保管室负责人根据票上的字提供相应的体育用品。然后Jungle就可以愉快地玩耍了。
|
|
|
|
|
```
|
|
|
|
|
我们采用简单工厂模式来实现上述场景。首先,体育保管室是工厂,篮球、足球和排球是具体的产品,而抽象产品可以定义为“运动球类产品SportProduct”.Jungle作为客户只需要提供具体产品名字,工厂就可“生产”出对应产品。
|
|
|
|
|
|
|
|
|
|
## 3.1.定义抽象产品类AbstractProduct,抽象方法不提供实现
|
|
|
|
|
```
|
|
|
|
|
//抽象产品类AbstractProduct
|
|
|
|
|
class AbstractSportProduct
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
AbstractSportProduct(){
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
//抽象方法:
|
|
|
|
|
void printName(){};
|
|
|
|
|
void play(){};
|
|
|
|
|
};
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## 3.2.定义三个具体产品类
|
|
|
|
|
```
|
|
|
|
|
//具体产品类Basketball
|
|
|
|
|
class Basketball :public AbstractSportProduct
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
Basketball(){
|
|
|
|
|
printName();
|
|
|
|
|
play();
|
|
|
|
|
}
|
|
|
|
|
//具体实现方法
|
|
|
|
|
void printName(){
|
|
|
|
|
printf("Jungle get Basketball\n");
|
|
|
|
|
}
|
|
|
|
|
void play(){
|
|
|
|
|
printf("Jungle play Basketball\n");
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
//具体产品类Football
|
|
|
|
|
class Football :public AbstractSportProduct
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
Football(){
|
|
|
|
|
printName();
|
|
|
|
|
play();
|
|
|
|
|
}
|
|
|
|
|
//具体实现方法
|
|
|
|
|
void printName(){
|
|
|
|
|
printf("Jungle get Football\n");
|
|
|
|
|
}
|
|
|
|
|
void play(){
|
|
|
|
|
printf("Jungle play Football\n");
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
//具体产品类Volleyball
|
|
|
|
|
class Volleyball :public AbstractSportProduct
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
Volleyball(){
|
|
|
|
|
printName();
|
|
|
|
|
play();
|
|
|
|
|
}
|
|
|
|
|
//具体实现方法
|
|
|
|
|
void printName(){
|
|
|
|
|
printf("Jungle get Volleyball\n");
|
|
|
|
|
}
|
|
|
|
|
void play(){
|
|
|
|
|
printf("Jungle play Volleyball\n");
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## 3.3.定义工厂类和工厂方法
|
|
|
|
|
```
|
|
|
|
|
class Factory
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
AbstractSportProduct *getSportProduct(string productName)
|
|
|
|
|
{
|
|
|
|
|
AbstractSportProduct *pro = NULL;
|
|
|
|
|
if (productName == "Basketball"){
|
|
|
|
|
pro = new Basketball();
|
|
|
|
|
}
|
|
|
|
|
else if (productName == "Football"){
|
|
|
|
|
pro = new Football();
|
|
|
|
|
}
|
|
|
|
|
else if (productName == "Volleyball"){
|
|
|
|
|
pro = new Volleyball();
|
|
|
|
|
}
|
|
|
|
|
return pro;
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## 3.4.客户端使用方法示例
|
|
|
|
|
```
|
|
|
|
|
#include <iostream>
|
|
|
|
|
#include "SimpleFactory.h"
|
|
|
|
|
|
|
|
|
|
int main()
|
|
|
|
|
{
|
|
|
|
|
printf("简单工厂模式\n");
|
|
|
|
|
|
|
|
|
|
//定义工厂类对象
|
|
|
|
|
Factory *fac = new Factory();
|
|
|
|
|
AbstractSportProduct *product = nullptr;
|
|
|
|
|
|
|
|
|
|
product = fac->getSportProduct("Basketball");
|
|
|
|
|
delete product;
|
|
|
|
|
product = nullptr;
|
|
|
|
|
|
|
|
|
|
product = fac->getSportProduct("Football");
|
|
|
|
|
delete product;
|
|
|
|
|
product = nullptr;
|
|
|
|
|
|
|
|
|
|
product = fac->getSportProduct("Volleyball");
|
|
|
|
|
delete product;
|
|
|
|
|
product = nullptr;
|
|
|
|
|
|
|
|
|
|
system("pause");
|
|
|
|
|
|
|
|
|
|
delete fac;
|
|
|
|
|
fac = nullptr;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## 3.5.效果
|
|
|
|
|
```
|
|
|
|
|
简单工厂模式
|
|
|
|
|
Jungle get Basketball
|
|
|
|
|
Jungle play Basketball
|
|
|
|
|
Jungle get Football
|
|
|
|
|
Jungle play Football
|
|
|
|
|
Jungle get Volleyball
|
|
|
|
|
Jungle play Volleyball
|
|
|
|
|
```
|
|
|
|
|
可以看到,在客户端使用时,只需要提供产品名称作为参数,传入工厂的方法中,即可得到对应产品。抽象产品类中并没有提供公共方法的实现,而是在各个具体产品类中根据各自产品情况实现。
|
|
|
|
|
|
|
|
|
|
# 4.简单工厂模式总结
|
|
|
|
|
简单工厂模式的优点在于:
|
|
|
|
|
|
|
|
|
|
- 工厂类提供创建具体产品的方法,并包含一定判断逻辑,客户不必参与产品的创建过程;
|
|
|
|
|
- 客户只需要知道对应产品的参数即可,参数一般简单好记,如数字、字符或者字符串等。
|
|
|
|
|
|
|
|
|
|
当然,简单工厂模式存在明显的不足(想想我们之前介绍的面向对象设计原则???)。**假设有一天Jungle想玩棒球了,该怎么办呢?你肯定会说,这还不容易吗?再从抽象产品类派生出一个Baseball类,并在工厂类的getSportProduct方法中增加“productName == "Baseball”的条件分支即可。**的确如此,但是这明显违背了开闭原则(对扩展开放,对修改关闭),即在扩展功能时修改了既有的代码。另一方面,简单工厂模式所有的判断逻辑都在工厂类中实现,一旦工厂类设计故障,则整个系统都受之影响!
|
|
|
|
|
|
|
|
|
|
那该这么办呢?请看下集!
|
|
|
|
|
|
|
|
|
|
|
2021-09-09 03:35:43 +00:00
|
|
|
|
原文链接:https://blog.csdn.net/sinat_21107433/article/details/102598181
|