C++工厂模式创建对象的通用方法

工厂模式通过解耦对象创建与使用，提升代码扩展性和维护性；其通用方法为工厂方法模式，定义抽象工厂和产品，由子类决定具体创建类型，适用于需动态创建不同对象的场景。

C++中工厂模式创建对象的通用方法，本质上是为了将对象的创建过程与使用过程解耦。它提供了一种灵活、可扩展的机制，让你可以在运行时决定创建哪种类型的对象，而无需在客户端代码中硬编码具体的类名。这就像你走进一家定制店，你告诉店员你想要什么（比如“一辆跑车”），店员根据你的需求从幕后为你打造并交付，你不需要知道跑车是如何具体制造出来的。

解决方案

谈到C++工厂模式创建对象的通用方法，我个人倾向于将其视为一个设计理念，而非单一的固定模式。最常见的实现方式，也是我认为最“通用”的，通常是工厂方法模式（Factory Method Pattern）。它通过定义一个用于创建对象的接口，让子类决定实例化哪一个类。这听起来有点抽象，但核心思想是：让创建者（Factory）的子类来决定创建具体哪种产品（Product）。

设想一下，你有一个游戏，里面有各种各样的敌人（比如兽人、精灵、恶魔）。如果每次需要一个新敌人，你都直接

new Orc()

new Elf()

工厂方法模式的通用实现步骤大致是这样的：

立即学习“C++免费学习笔记（深入）”；

1. 定义抽象产品（Abstract Product）接口或基类： 这是所有具体产品（例如

   Orc

   、

   Elf

   ）都必须实现或继承的接口/基类。它定义了产品的公共行为。

   // Abstract Product
   class Enemy {
   public:
       virtual ~Enemy() = default;
       virtual void attack() const = 0;
       virtual void takeDamage(int amount) = 0;
       // ... 其他通用行为
   };

2. 定义具体产品（Concrete Products）： 实现抽象产品接口的具体类。

   // Concrete Products
   class Orc : public Enemy {
   public:
       void attack() const override {
           std::cout << "Orc charges and attacks with an axe!" << std::endl;
       }
       void takeDamage(int amount) override {
           std::cout << "Orc takes " << amount << " damage." << std::endl;
       }
   };
   
   class Elf : public Enemy {
   public:
       void attack() const override {
           std::cout << "Elf fires an arrow from afar!" << std::endl;
       }
       void takeDamage(int amount) override {
           std::cout << "Elf takes " << amount << " damage." << std::endl;
       }
   };

3. 定义抽象创建者（Abstract Creator）接口或基类： 这就是工厂的抽象层。它声明了一个工厂方法，用于返回一个产品对象。这个方法通常是虚函数。

   // Abstract Creator (Factory)
   class EnemyFactory {
   public:
       virtual ~EnemyFactory() = default;
       // 工厂方法，返回一个指向抽象产品的指针
       virtual std::unique_ptr createEnemy() const = 0;
   };

4. 定义具体创建者（Concrete Creators）： 实现抽象创建者接口的具体工厂类。每个具体工厂负责创建一种或一类具体产品。

   // Concrete Creators (Specific Factories)
   class OrcFactory : public EnemyFactory {
   public:
       std::unique_ptr createEnemy() const override {
           return std::make_unique(); // 创建具体的Orc对象
       }
   };
   
   class ElfFactory : public EnemyFactory {
   public:
       std::unique_ptr createEnemy() const override {
           return std::make_unique(); // 创建具体的Elf对象
       }
   };

5. 客户端使用： 客户端代码通过抽象工厂接口与产品交互，不需要知道具体的工厂和产品类。

   // Client Code
   void gameLoop(const EnemyFactory& factory) {
       std::unique_ptr enemy = factory.createEnemy();
       enemy->attack();
       enemy->takeDamage(10);
       // ... 游戏逻辑
   }
   
   // main 函数中
   // OrcFactory orcFactory;
   // gameLoop(orcFactory); // 创建一个Orc敌人
   
   // ElfFactory elfFactory;
   // gameLoop(elfFactory); // 创建一个Elf敌人

   这种结构的最大好处在于，当你需要添加一个新的敌人类型（比如

   Goblin

   ）时，你只需要创建一个

   Goblin

   类和一个

   GoblinFactory

   类，而无需修改任何现有代码（符合开闭原则）。这比直接在

   gameLoop

   里加

   if-else if

   来判断创建哪个敌人要优雅和健壮得多。

C++工厂模式的核心优势与适用场景是什么？

C++工厂模式的核心优势，在我看来，主要体现在解耦、扩展性和维护性上。它将“谁来创建对象”的责任从客户端代码中剥离出来，交给专门的工厂来处理。这种分离，对于大型、复杂的系统来说，简直是救命稻草。

首先是解耦。客户端代码不再直接依赖于具体的产品类。它只知道抽象产品接口和抽象工厂接口。这意味着，即使具体产品的实现细节发生变化，或者需要替换为另一个具体产品，客户端代码也无需改动。这就像你点外卖，你只需要知道你点的是“披萨”，而不需要关心是哪家店的披萨，也不需要知道披萨是怎么烤出来的。这种松散耦合让系统更加健壮。

其次是扩展性。当系统需要引入新的产品类型时，你只需要创建新的具体产品类和对应的具体工厂类，而无需修改现有的工厂或客户端代码。这完美地遵循了面向对象设计的开闭原则（Open/Closed Principle）——对扩展开放，对修改关闭。比如，在我的游戏例子中，如果我想加入一个“巨魔”敌人，我只需要写

Troll

TrollFactory

Orc

Elf

gameLoop

再者是维护性。集中式的对象创建逻辑使得代码更容易理解和管理。如果某个对象的创建过程很复杂，或者涉及到资源管理（比如对象池、单例），将其封装在工厂中，可以避免在多处重复这些复杂逻辑。当创建逻辑需要调整时，你只需要修改工厂类，而不是在整个代码库中搜索并修改所有

new

那么，它适用于哪些场景呢？

• 当一个类不知道它所要创建的对象的类时：这是最直接的场景。比如插件系统，主程序并不知道会加载哪些插件，但它需要一个统一的接口来创建它们。
• 当一个类希望由它的子类来指定它所创建的对象时：这正是工厂方法模式的精髓。基类定义了创建的框架，子类填充具体创建逻辑。
• 当需要根据不同的条件创建不同的对象时：例如，根据配置文件、用户输入、环境变量等动态决定创建哪种对象。
• 当对象的创建过程比较复杂，或者需要进行一些初始化设置时：将这些复杂性封装在工厂中，可以简化客户端代码。
• 需要管理大量相似对象实例的生命周期时：工厂可以与对象池、单例模式等结合使用，进行更精细的资源管理。

总的来说，只要你的系统中有“创建”和“使用”的分离需求，并且希望这个分离能够带来更好的灵活性和可维护性，工厂模式就值得考虑。我个人在处理多平台兼容性（比如不同操作系统下的GUI组件）、配置加载器、或者复杂的业务对象实例化时，都倾向于使用工厂模式。

EasyCart开源网店系统

Easycart是一款专业的电子商务网站程序，为各大企业提供最适合的电子商务网络销售网站前后台方案。Easycart是Easycart开发团队通 过对现代电子商务以及消费者购物方式进行深入研究，充分了解企业以及消费者的需求后研发的现代电子商务行业使用的程序。面向不同的企业品牌、代理商提出了 不同的方案，用户可根据企业自身特点，调整后台设置，创建最适合自己的网店模版。易学、易用、易管理、易推广，高效

下载

如何在C++中构建一个灵活的工厂方法模式？

构建一个灵活的工厂方法模式，不仅仅是实现上面提到的那些类，更重要的是要考虑如何让它在实际项目中真正“活”起来，适应变化。这里我分享一些我个人在实践中觉得很有效的点，以及一些值得深思的细节。

首先，使用智能指针管理产品生命周期是现代C++的标配。在上面的示例中，我用了

std::unique_ptr

std::shared_ptr

delete

// 示例：工厂方法返回智能指针
class EnemyFactory {
public:
    virtual ~EnemyFactory() = default;
    virtual std::unique_ptr createEnemy() const = 0;
};

其次，注册机制（Registration Mechanism）可以进一步提升工厂的灵活性，尤其是当你面对的是一个简单工厂（Simple Factory），或者希望在运行时动态添加产品类型而无需修改工厂代码时。虽然工厂方法模式通常是每个具体工厂创建一个具体产品，但如果你的需求是“一个工厂可以根据字符串ID创建不同产品”，那么注册机制就很有用。

#include 

这种注册机制让

SimpleEnemyFactory

register

registerEnemy

第三，参数化创建。很多时候，创建对象需要传递参数。工厂方法可以接受参数，并将这些参数传递给产品对象的构造函数。

// 抽象产品，构造函数接受参数
class Enemy {
public:
    Enemy(int health, int damage) : m_health(health), m_damage(damage) {}
    virtual ~Enemy() = default;
    virtual void attack() const = 0;
    virtual void takeDamage(int amount) = 0;
protected:
    int m_health;
    int m_damage;
};

// 抽象工厂，工厂方法接受参数
class ParametrizedEnemyFactory {
public:
    virtual ~ParametrizedEnemyFactory() = default;
    virtual std::unique_ptr createEnemy(int health, int damage) const = 0;
};

// 具体工厂实现
class OrcFactory : public ParametrizedEnemyFactory {
public:
    std::unique_ptr createEnemy(int health, int damage) const override {
        return std::make_unique(health, damage); // 传递参数给Orc构造函数
    }
};

这样，客户端在创建对象时就可以动态地指定对象的属性，而不是工厂只能创建固定属性的对象。

最后，考虑模板化工厂。如果你的产品类型很多，但它们的创建逻辑（比如都需要一个构造函数参数）非常相似，你可以考虑使用模板来减少重复代码。但这会增加一些复杂性，需要权衡。例如，一个通用的

TemplatedFactory

构建灵活的工厂模式，关键在于识别出变化点，并用设计模式来封装这些变化。它不是一蹴而就的，而是随着项目演进和需求变化，不断调整和优化的过程。

C++工厂模式的常见变体与选择考量？

C++工厂模式并非只有一种，它是一个模式家族，包含几种常见的变体。理解这些变体以及它们各自的优缺点，对于在实际项目中做出明智选择至关重要。我个人在不同场景下会灵活运用它们，因为没有“一招鲜吃遍天”的模式。

1. 简单工厂（Simple Factory）

   • 描述：它不属于GoF（Gang of Four）的23种设计模式之一，但非常常见。一个单独的工厂类负责创建所有具体产品类的实例。通常有一个静态方法或一个单例工厂来完成。
   • 实现特点：工厂类内部通常包含一个

     switch

     或

     if-else if

     语句，根据传入的参数（如字符串或枚举）来决定创建哪种产品。
   • 优点：
     • 简单易懂，实现起来最快。
     • 客户端代码与具体产品类解耦。
   • 缺点：
     • 违反开闭原则：每当增加新的产品类型时，都需要修改工厂类的创建逻辑，这可能导致工厂类变得臃肿。
     • 工厂职责过重：一个工厂负责所有产品的创建，如果产品种类过多，工厂类会变得难以维护。
   • 选择考量：适用于产品种类较少且相对稳定，或者产品创建逻辑相对简单，不需要频繁扩展的场景。比如，一个配置文件解析器，只处理几种固定的配置格式。我通常在项目初期，需求不明确时会先用简单工厂，后期再根据需求演进到工厂方法。

2. 工厂方法模式（Factory Method Pattern）

   • 描述：这是GoF模式之一，也是我在“解决方案”部分详细介绍的。它定义了一个用于创建对象的接口，但让子类决定实例化哪一个类。工厂方法让类的实例化延迟到子类。
   • 实现特点：抽象工厂类定义工厂方法（虚函数），具体工厂类继承抽象工厂并实现工厂方法，返回特定的具体产品。
   • 优点：
     • 符合开闭原则：增加新产品时，只需增加新的具体产品类和新的具体工厂类，无需修改现有代码。
     • 客户端与具体产品和具体工厂解耦。
     • 可以有多个工厂，每个工厂只负责创建一种产品，职责单一。
   • 缺点：
     • 类的数量会增多：每增加一种产品，通常需要增加一个具体产品类和一个具体工厂类，导致类层次结构可能变得复杂。
     • 初始实现相对简单工厂更复杂。
   • 选择考量：这是最常用的工厂模式，适用于产品种类不确定、需要频繁扩展、或者产品创建逻辑复杂且多样化的场景。当一个系统需要提供一个框架，让子系统或用户扩展时，工厂方法模式是理想选择。比如，图形库中的不同形状渲染器，或者游戏中的不同角色生成器。

3. 抽象工厂模式（Abstract Factory Pattern）

   • 描述：GoF模式之一。它提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。它关注的是“产品族”的创建。
   • 实现特点：抽象工厂类包含多个工厂方法，每个方法负责创建产品族中的一个产品。具体工厂类实现所有这些工厂方法，创建特定风格的产品族。
   • 优点：
     • 确保创建出的产品族是相互兼容的。
     • 客户端代码与具体工厂和具体产品完全解耦。
     • 支持产品族之间的切换，只需切换具体工厂。
   • 缺点：
     • 增加新的产品种类（即新的产品接口）时，需要修改抽象工厂及其所有具体工厂，违反开闭原则。
     • 类的数量更多，结构更复杂。
   • 选择考量：适用于系统需要创建一组相关或相互依赖的对象，并且这些对象需要以不同的“风格”或“主题”来呈现时。例如，GUI库中的不同操作系统风格的组件（按钮、文本框等），或者游戏中的不同阵营的单位（兽人阵营的兵营、战士、弓箭手；精灵阵营的兵营、战士、弓箭手）。当你的系统需要支持“换肤”或“换主题”时，抽象工厂模式会非常有用。

总结与选择策略：

我通常会这样思考：

• 如果产品种类很少且稳定，或者只是想快速实现解耦，我会考虑简单工厂。 它的开销最小，但牺牲了部分扩展性。
• 如果产品种类会频繁增加，且需要保持良好的扩展性，工厂方法模式是我的首选。 它是最平衡的选择，既提供了良好的解耦，又满足了开闭原则。
• 如果我的系统需要创建“一整套”相关联的对象，并且这套对象可能有多种“风格”或“主题”可供选择，那么抽象工厂模式就是不二之选。 它的复杂性最高，但解决了最复杂的产品族创建问题。

在实际开发中，我发现模式之间并非总是独立的，有时它们会结合使用。比如，一个抽象工厂内部的某个工厂方法，可能又是一个简单工厂的实现。理解它们的本质和适用场景，远比死记硬背它们的结构图重要得多。