工厂模式通过解耦对象创建与使用，提升代码扩展性和维护性；其通用方法为工厂方法模式，定义抽象工厂和产品，由子类决定具体创建类型，适用于需动态创建不同对象的场景。
C++中工厂模式创建对象的通用方法，本质上是为了将对象的创建过程与使用过程解耦。它提供了一种灵活、可扩展的机制，让你可以在运行时决定创建哪种类型的对象，而无需在客户端代码中硬编码具体的类名。这就像你走进一家定制店，你告诉店员你想要什么（比如“一辆跑车”），店员根据你的需求从幕后为你打造并交付，你不需要知道跑车是如何具体制造出来的。
解决方案
谈到C++工厂模式创建对象的通用方法，我个人倾向于将其视为一个设计理念，而非单一的固定模式。最常见的实现方式，也是我认为最“通用”的，通常是工厂方法模式（Factory Method Pattern）。它通过定义一个用于创建对象的接口，让子类决定实例化哪一个类。这听起来有点抽象，但核心思想是：让创建者（Factory）的子类来决定创建具体哪种产品（Product）。
设想一下，你有一个游戏，里面有各种各样的敌人（比如兽人、精灵、恶魔）。如果每次需要一个新敌人，你都直接
new Orc()
或
new Elf()
，那当敌人种类增多，或者创建逻辑变得复杂（比如需要根据难度调整敌人属性）时，你的代码就会变得一团糟，维护起来简直是噩梦。
工厂方法模式的通用实现步骤大致是这样的：
立即学习“C++免费学习笔记（深入）”；
定义抽象产品（Abstract Product）接口或基类： 这是所有具体产品（例如
Orc
、
Elf
）都必须实现或继承的接口/基类。它定义了产品的公共行为。
// Abstract Productclass Enemy {public: virtual ~Enemy() = default; virtual void attack() const = 0; virtual void takeDamage(int amount) = 0; // ... 其他通用行为};
定义具体产品（Concrete Products）： 实现抽象产品接口的具体类。
// Concrete Productsclass 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; }};
定义抽象创建者（Abstract Creator）接口或基类： 这就是工厂的抽象层。它声明了一个工厂方法，用于返回一个产品对象。这个方法通常是虚函数。
// Abstract Creator (Factory)class EnemyFactory {public: virtual ~EnemyFactory() = default; // 工厂方法，返回一个指向抽象产品的指针 virtual std::unique_ptr createEnemy() const = 0;};
定义具体创建者（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对象 }};
客户端使用： 客户端代码通过抽象工厂接口与产品交互，不需要知道具体的工厂和产品类。
// Client Codevoid 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
调用的地方。这大大降低了维护成本和引入bug的风险。
那么，它适用于哪些场景呢？
当一个类不知道它所要创建的对象的类时：这是最直接的场景。比如插件系统，主程序并不知道会加载哪些插件，但它需要一个统一的接口来创建它们。当一个类希望由它的子类来指定它所创建的对象时：这正是工厂方法模式的精髓。基类定义了创建的框架，子类填充具体创建逻辑。当需要根据不同的条件创建不同的对象时：例如，根据配置文件、用户输入、环境变量等动态决定创建哪种对象。当对象的创建过程比较复杂，或者需要进行一些初始化设置时：将这些复杂性封装在工厂中，可以简化客户端代码。需要管理大量相似对象实例的生命周期时：工厂可以与对象池、单例模式等结合使用，进行更精细的资源管理。
总的来说，只要你的系统中有“创建”和“使用”的分离需求，并且希望这个分离能够带来更好的灵活性和可维护性，工厂模式就值得考虑。我个人在处理多平台兼容性（比如不同操作系统下的GUI组件）、配置加载器、或者复杂的业务对象实例化时，都倾向于使用工厂模式。
如何在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++工厂模式并非只有一种，它是一个模式家族，包含几种常见的变体。理解这些变体以及它们各自的优缺点，对于在实际项目中做出明智选择至关重要。我个人在不同场景下会灵活运用它们，因为没有“一招鲜吃遍天”的模式。
简单工厂（Simple Factory）
描述：它不属于GoF（Gang of Four）的23种设计模式之一，但非常常见。一个单独的工厂类负责创建所有具体产品类的实例。通常有一个静态方法或一个单例工厂来完成。实现特点：工厂类内部通常包含一个
switch
或
if-else if
语句，根据传入的参数（如字符串或枚举）来决定创建哪种产品。优点：简单易懂，实现起来最快。客户端代码与具体产品类解耦。缺点：违反开闭原则：每当增加新的产品类型时，都需要修改工厂类的创建逻辑，这可能导致工厂类变得臃肿。工厂职责过重：一个工厂负责所有产品的创建，如果产品种类过多，工厂类会变得难以维护。选择考量：适用于产品种类较少且相对稳定，或者产品创建逻辑相对简单，不需要频繁扩展的场景。比如，一个配置文件解析器，只处理几种固定的配置格式。我通常在项目初期，需求不明确时会先用简单工厂，后期再根据需求演进到工厂方法。
工厂方法模式（Factory Method Pattern）
描述：这是GoF模式之一，也是我在“解决方案”部分详细介绍的。它定义了一个用于创建对象的接口，但让子类决定实例化哪一个类。工厂方法让类的实例化延迟到子类。实现特点：抽象工厂类定义工厂方法（虚函数），具体工厂类继承抽象工厂并实现工厂方法，返回特定的具体产品。优点：符合开闭原则：增加新产品时，只需增加新的具体产品类和新的具体工厂类，无需修改现有代码。客户端与具体产品和具体工厂解耦。可以有多个工厂，每个工厂只负责创建一种产品，职责单一。缺点：类的数量会增多：每增加一种产品，通常需要增加一个具体产品类和一个具体工厂类，导致类层次结构可能变得复杂。初始实现相对简单工厂更复杂。选择考量：这是最常用的工厂模式，适用于产品种类不确定、需要频繁扩展、或者产品创建逻辑复杂且多样化的场景。当一个系统需要提供一个框架，让子系统或用户扩展时，工厂方法模式是理想选择。比如，图形库中的不同形状渲染器，或者游戏中的不同角色生成器。
抽象工厂模式（Abstract Factory Pattern）
描述：GoF模式之一。它提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。它关注的是“产品族”的创建。实现特点：抽象工厂类包含多个工厂方法，每个方法负责创建产品族中的一个产品。具体工厂类实现所有这些工厂方法，创建特定风格的产品族。优点：确保创建出的产品族是相互兼容的。客户端代码与具体工厂和具体产品完全解耦。支持产品族之间的切换，只需切换具体工厂。缺点：增加新的产品种类（即新的产品接口）时，需要修改抽象工厂及其所有具体工厂，违反开闭原则。类的数量更多，结构更复杂。选择考量：适用于系统需要创建一组相关或相互依赖的对象，并且这些对象需要以不同的“风格”或“主题”来呈现时。例如，GUI库中的不同操作系统风格的组件（按钮、文本框等），或者游戏中的不同阵营的单位（兽人阵营的兵营、战士、弓箭手；精灵阵营的兵营、战士、弓箭手）。当你的系统需要支持“换肤”或“换主题”时，抽象工厂模式会非常有用。
总结与选择策略：
我通常会这样思考：
如果产品种类很少且稳定，或者只是想快速实现解耦，我会考虑简单工厂。 它的开销最小，但牺牲了部分扩展性。如果产品种类会频繁增加，且需要保持良好的扩展性，工厂方法模式是我的首选。 它是最平衡的选择，既提供了良好的解耦，又满足了开闭原则。如果我的系统需要创建“一整套”相关联的对象，并且这套对象可能有多种“风格”或“主题”可供选择，那么抽象工厂模式就是不二之选。 它的复杂性最高，但解决了最复杂的产品族创建问题。
在实际开发中，我发现模式之间并非总是独立的，有时它们会结合使用。比如，一个抽象工厂内部的某个工厂方法，可能又是一个简单工厂的实现。理解它们的本质和适用场景，远比死记硬背它们的结构图重要得多。
以上就是C++工厂模式创建对象的通用方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1474868.html
微信扫一扫 
支付宝扫一扫 
