设计模式：简单工厂模式（Simple Factory）
- 设计模式：简单工厂模式（Simple Factory）
- 模式动机
- 模式定义
- 模式结构
- 时序图
- 模式实现
- 测试
- 模式分析
- 实例：Qt 控件类
- 优缺点
- 适用环境
- 模式应用
设计模式：简单工厂模式（Simple Factory）
简单工厂模式（Simple Factory）属于创建型模式（Creational Pattern）的一种。
创建型模式（Creational Pattern）对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰，外界对于这些对象只需要知道它们共同的接口，而不清楚其具体的实现细节，使整个系统的设计更加符合单一职责原则。
创建型模式在创建什么（What），由谁创建（Who），何时创建（When）等方面都为软件设计者提供了尽可能大的灵活性。创建型模式隐藏了类的实例的创建细节，通过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的。
模式动机
意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
考虑一个简单的软件应用场景，一个软件系统可以提供多个外观不同的按钮（如圆形按钮、矩形按钮、菱形按钮等）， 这些按钮都源自同一个基类，不过在继承基类后不同的子类修改了部分属性从而使得它们可以呈现不同的外观，如果我们希望在使用这些按钮时，不需要知道这些具体按钮类的名字，只需要知道表示该按钮类的一个参数，并提供一个调用方便的方法，把该参数传入方法即可返回一个相应的按钮对象，此时，就可以使用简单工厂模式。
模式定义
简单工厂模式（Simple Factory）又称为静态工厂方法（Static Factory Method）模式。
在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
模式结构
简单工厂模式（Simple Factory）包含以下角色：
- 工厂（Factory）：工厂角色负责实现创建所有实例的内部逻辑。
- 抽象产品（Abstract Product）：定义了产品的共同接口或抽象类。它可以是具体产品类的父类或接口，规定了产品对象的共同方法。
- 具体产品（Concrete Product）：实现了抽象产品接口，定义了具体产品的特定行为和属性。具体产品是创建目标，所有创建的对象都充当这个角色的某个具体类的实例。
时序图
模式实现
简单工厂类 SimpleFactory.h：
#ifndef _SIMPLE_FACTORY_H_
#define _SIMPLE_FACTORY_H_
#include <string>
#include "ConcreteProductA.h"
#include "ConcreteProductB.h"
class SimpleFactory
{
public:
static AbstractProduct* createProduct(const std::string& productType)
{
if (productType == "A")
return new ConcreteProductA();
else if (productType == "B")
return new ConcreteProductB();
return nullptr;
}
};
#endif // !_SIMPLE_FACTORY_H_
抽象产品类 AbstractProduct.h：
#ifndef _ABSTRACT_PRODUCT_H_
#define _ABSTRACT_PRODUCT_H_
#include <iostream>
class AbstractProduct
{
public:
virtual void use() = 0;
};
#endif // !_ABSTRACT_PRODUCT_H_
具体产品A类 ConcreteProductA.h：
#ifndef _CONCRETE_PRODUCT_A_H_
#define _CONCRETE_PRODUCT_A_H_
#include "AbstractProduct.h"
class ConcreteProductA : public AbstractProduct
{
public:
void use() override
{
std::cout << "Using Concrete Product A" << std::endl;
}
};
#endif // !_CONCRETE_PRODUCT_A_H_
具体产品B类 ConcreteProductB.h：
#ifndef _CONCRETE_PRODUCT_B_H_
#define _CONCRETE_PRODUCT_B_H_
#include "AbstractProduct.h"
class ConcreteProductB : public AbstractProduct
{
public:
void use() override
{
std::cout << "Using Concrete Product B" << std::endl;
}
};
#endif // !_CONCRETE_PRODUCT_B_H_
测试
测试代码 main.cpp：
#include <stdlib.h>
#include "SimpleFactory.h"
#include "ConcreteProductA.h"
#include "ConcreteProductB.h"
int main()
{
SimpleFactory simpleFactory;
AbstractProduct* productA = simpleFactory.createProduct("A");
AbstractProduct* productB = simpleFactory.createProduct("B");
if (productA)
productA->use();
if (productB)
productB->use();
delete productA;
delete productB;
system("pause");
return 0;
}
运行结果：
模式分析
- 将对象的创建和对象本身业务处理分离可以降低系统的耦合度，使得两者修改起来都相对容易。
- 在调用工厂类的工厂方法时，由于工厂方法是静态方法，使用起来很方便，可通过类名直接调用，而且只需要传入一个简单的参数即可，在实际开发中，还可以在调用时将所传入的参数保存在XML等格式的配置文件中，修改参数时无须修改任何源代码。
- 简单工厂模式最大的问题在于工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，这一点与开闭原则是相违背的。
- 简单工厂模式的要点在于：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。
实例：Qt 控件类
在开发一个用户界面过程中，我需要三种控件类型，分别是按钮、图像和文本。这些控件都有一些工厂的特点，比如都有位置属性（位于界面的哪个地方）、大小属性（长度和宽度）等等。因此创建一个Item（参考Qt）作为它们的父类，Button（按钮）、Image（图像）和Text（文本）都继承于它。
下面是参考代码：
#include <iostream>
#include <memory>
#include <string>
#include <stdlib.h>
using namespace std;
// Item 父类
class Item
{
protected:
int m_width;
int m_height;
public:
Item(int width, int height) : m_width(width), m_height(height) {}
virtual ~Item() {}
};
// Button 子类
class Button : public Item
{
public:
Button(int width, int heght) : Item(width, heght)
{
cout << "用户界面创建了一个按钮" << endl;
}
};
// Image 子类
class Image : public Item
{
public:
Image(int width, int heght) : Item(width, heght)
{
cout << "用户界面创建了一个图像" << endl;
}
};
// Text 子类
class Text : public Item
{
public:
Text(int width, int heght) : Item(width, heght)
{
cout << "用户界面创建了一个文本" << endl;
}
};
// ItemFactory 工厂类
class ItemFactory
{
public:
static unique_ptr<Item> createItem(string itemType)
{
if (itemType == "button")
{
// newItem = new Button(50, 50);
return make_unique<Button>(50, 50);
}
else if (itemType == "image")
{
// newItem = new Image(100, 100);
return make_unique<Image>(100, 100);
}
else if (itemType == "text")
{
// newItem = new Text(100, 30);
return make_unique<Text>(100, 30);
}
return NULL;
}
};
int main()
{
ItemFactory itemFac;
auto pI1 = itemFac.createItem("button"); // 创建了一个 Button
auto pI2 = itemFac.createItem("image"); // 创建了一个 Image
auto pI3 = itemFac.createItem("text"); // 创建了一个 Text
// delete pI1;
// delete pI2;
// delete pI3;
system("pause");
return 0;
}
我们使用简单工厂模式后，创建各种各样的控件，就不用和它们控件本身的类打交道（Button、Image、Text），而是通过ItemFactory的成员函数createFactory，将不同字符串标识传入进去，从而返回不同的控件，这其实就是一种封装变化。
优缺点
优点：
- 封装性好： 简单工厂模式封装了对象创建的细节，客户端不需要直接实例化具体的产品类。这有助于隐藏具体产品类的实现细节，使得客户端代码更加简洁和易于维护。
- 解耦： 简单工厂模式降低了客户端与具体产品类之间的耦合度。客户端只需要与工厂类交互，而不需要知道具体产品类的实现细节。这有助于减少代码的依赖性和提高系统的可维护性。
- 代码复用： 工厂类集中了产品对象的创建逻辑，可以在多个地方重用该工厂类来创建对象，提高了代码的复用性。
- 扩展性好： 当需要添加新的产品类时，只需要在工厂类中添加相应的创建逻辑，而无需修改客户端代码。这符合开闭原则，即对扩展开放，对修改封闭。
缺点：
- 违反单一职责原则： 简单工厂类通常负责创建多种类型的产品对象，这可能导致工厂类的职责过多，违反了单一职责原则。当产品类型较多时，工厂类的代码可能会变得庞大而难以维护。
- 类型判断逻辑复杂： 简单工厂模式通常需要根据客户端提供的参数或类型信息来判断需要创建哪种类型的产品对象。随着产品类型的增加，类型判断逻辑可能会变得复杂和易错。
- 不易于扩展新的产品族： 简单工厂模式是针对一个产品族设计的，如果需要添加新的产品族（即一组具有共同主题的产品），可能需要修改工厂类的代码，这违反了开闭原则。
- 不易于使用继承等面向对象特性： 简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构；由于简单工厂模式通常直接返回具体产品类的实例，而不是通过继承等面向对象特性来创建对象，因此可能无法充分利用面向对象编程的优势。
适用环境
C++ 简单工厂模式的应用场景主要包括以下几种情况：
- 创建对象不需要知道具体类的情况： 客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。
- 需要创建的对象较少且不会经常变动： 由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
模式应用
- JDK类库中广泛使用了简单工厂模式，如工具类java.text.DateFormat，它用于格式化一个本地日期或者时间。
public final static DateFormat getDateInstance(); public final static DateFormat getDateInstance(int style); public final static DateFormat getDateInstance(int style,Locale locale); - Java加密技术。
比如，获取不同加密算法的密钥生成器：public final static DateFormat getDateInstance(); public final static DateFormat getDateInstance(int style); public final static DateFormat getDateInstance(int style,Locale locale);
