工厂方法模式通过抽象创建过程、利用继承实现解耦，使客户端无需依赖具体产品类，新增产品时只需添加对应工厂子类，符合开闭原则，并结合智能指针与虚析构函数可有效管理资源。
C++中实现工厂模式，特别是工厂方法模式，核心在于将对象的创建过程抽象化，并交由子类决定实例化哪个具体产品。它提供了一个接口来创建对象，但具体的类实例化则由其子类完成，这样一来，客户端代码就无需关心具体产品的创建细节，从而实现了创建者和具体产品之间的解耦。在我看来，这是一种非常优雅地处理对象创建复杂性的方式，尤其当你的系统需要支持多种同类型但具体实现不同的产品时。
解决方案
要实现C++中的工厂方法模式，我们通常会定义一个抽象产品基类，一些具体的子产品类，一个抽象创建者基类，以及一些具体的创建者子类。
我们以一个简单的“文档”系统为例，假设我们有不同类型的文档（比如文本文档和图片文档），并且需要不同的工厂来创建它们。
#include#include // 为了使用智能指针 // 1. 抽象产品 (Abstract Product) // 定义所有产品都应该遵循的接口 class Document { public: virtual ~Document() = default; // 确保多态删除 virtual void open() = 0; virtual void save() = 0; }; // 2. 具体产品 (Concrete Products) // 实现抽象产品接口的具体类 class TextDocument : public Document { public: void open() override { std::cout << "Opening a Text Document." << std::endl; } void save() override { std::cout << "Saving a Text Document." << std::endl; } }; class ImageDocument : public Document { public: void open() override { std::cout << "Opening an Image Document." << std::endl; } void save() override { std::cout << "Saving an Image Document." << std::endl; } }; // 3. 抽象创建者 (Abstract Creator) // 声明工厂方法，并可能包含一些操作，这些操作会使用工厂方法创建的产品 class DocumentCreator { public: virtual ~DocumentCreator() = default; // 工厂方法：返回一个抽象产品指针 // 注意这里使用了std::unique_ptr来管理内存，避免裸指针的内存泄漏问题 virtual std::unique_ptr createDocument() = 0; // 可以在这里定义一些通用的操作，这些操作会用到由工厂方法创建的产品 void operateDocument() { std::unique_ptr doc = createDocument(); // 通过工厂方法创建产品 if (doc) { doc->open(); doc->save(); std::cout << "Document operation completed." << std::endl; } else { std::cout << "Failed to create document." << std::endl; } } }; // 4. 具体创建者 (Concrete Creators) // 实现工厂方法，返回一个具体的具体产品实例 class TextDocumentCreator : public DocumentCreator { public: std::unique_ptr createDocument() override { std::cout << "TextDocumentCreator is creating a TextDocument." << std::endl; return std::make_unique (); } }; class ImageDocumentCreator : public DocumentCreator { public: std::unique_ptr createDocument() override { std::cout << "ImageDocumentCreator is creating an ImageDocument." << std::endl; return std::make_unique (); } }; // 客户端代码 int main() { std::cout << "--- Using Text Document Creator ---" << std::endl; std::unique_ptr textCreator = std::make_unique (); textCreator->operateDocument(); // 客户端只与抽象创建者交互 std::cout << "\n--- Using Image Document Creator ---" << std::endl; std::unique_ptr imageCreator = std::make_unique (); imageCreator->operateDocument(); // 客户端只与抽象创建者交互 return 0; }
这段代码展示了工厂方法模式的核心结构。客户端代码（
main函数）只需要与抽象的
DocumentCreator接口打交道，而无需知道具体创建的是
TextDocument还是
ImageDocument。具体产品的实例化逻辑被封装在各自的
DocumentCreator子类中。
立即学习“C++免费学习笔记（深入）”；
为什么在C++项目中选择工厂方法模式？它解决了哪些常见的开发痛点？
在我看来，工厂方法模式在C++项目中特别有价值，它主要解决了几个我在实际开发中经常遇到的痛点：
首先，它彻底解耦了客户端代码与具体产品类之间的依赖。想象一下，如果你的应用程序需要根据不同的配置或用户输入来创建不同类型的对象，但你又不想在客户端代码里写一大堆
if-else或
switch语句来判断应该
new哪个具体类。工厂方法模式就完美解决了这个问题。客户端只需要知道它需要一个“文档”对象，然后交给一个“文档创建者”去完成，具体是文本文档还是图片文档，客户端根本不需要关心，甚至可以完全不知道这些具体类的存在。这种松耦合的设计，让系统变得更加灵活。
其次，它很好地遵循了“开闭原则”（Open/Closed Principle）。这意味着你的系统对扩展是开放的，对修改是封闭的。当需要引入一个新的产品类型（比如“PDF文档”）时，你只需要创建新的
PdfDocument类和
PdfDocumentCreator类，而无需修改任何已有的客户端代码或抽象创建者接口。这种扩展性对于大型、长期维护的项目来说简直是福音。我记得以前有个项目，每次加新功能都要改动几十个文件，简直是噩梦，后来引入了工厂模式，才慢慢把这种耦合性降下来。
再者，它将对象创建的复杂逻辑集中管理。有时候，一个对象的创建过程可能不仅仅是
new一下那么简单，它可能需要读取配置文件、初始化多个参数、甚至依赖其他服务的状态。如果这些复杂逻辑散落在代码的各个角落，维护起来会非常困难。工厂方法模式把这些创建细节封装在具体的工厂方法里，使得创建逻辑变得清晰、可控，也方便后续的修改和优化。
工厂方法模式与简单工厂、抽象工厂模式有何本质区别？
这三个概念初学者确实容易混淆，我当初也花了点时间才理清。在我看来，它们虽然都和“创建对象”有关，但解决问题的层次和方式却大相径庭。
简单工厂模式（Simple Factory Pattern），严格来说，它不算一个设计模式，更多是一种编程习惯或者说技巧。它的特点是有一个集中的工厂类，通常包含一个静态方法，根据传入的参数来决定创建哪种具体产品。比如，
DocumentFactory::createDocument(type)。它的优点是简单直观，适用于产品种类较少且相对稳定的场景。但缺点也很明显：它违反了开闭原则。每次增加新的产品类型，你都得修改工厂类的静态方法，这在大型项目中是不可接受的。它把所有产品的创建逻辑都耦合在一个地方，职责过重。
工厂方法模式（Factory Method Pattern），就是我们上面讨论的。它的核心在于“多态性”和“继承”。它定义了一个抽象的工厂接口，由子类去实现具体的工厂方法，从而生产出对应的产品。每个具体产品都有一个对应的具体工厂来创建。你看，
TextDocumentCreator只负责创建
TextDocument，
ImageDocumentCreator只负责创建
ImageDocument。这样，当你需要添加
PdfDocument时，你只需要创建
PdfDocument和
PdfDocumentCreator，完全不影响现有的代码。它把创建的职责下放到了子类，实现了更好的解耦和扩展性。
抽象工厂模式（Abstract Factory Pattern），这个模式就更高级一些了，它解决的是创建“产品族”的问题。简单来说，如果你不仅仅需要创建一种产品（比如文档），还需要创建一系列相关的产品（比如文档编辑器、文档查看器、文档打印机），并且这些产品需要保持一致的“风格”（比如都是“Windows风格”的，或者是“Mac风格”的），那么抽象工厂就派上用场了。它提供一个接口，用于创建一系列相关或相互依赖的对象，而无需指定它们具体的类。抽象工厂模式通常会包含多个工厂方法，每个方法负责创建产品族中的一个产品。很多时候，抽象工厂的实现内部，会用到工厂方法模式来创建具体的产品。它就像一个超级工厂，能一次性生产一套完整的、风格一致的产品线。
简单总结一下：
- 简单工厂：一个工厂，一个方法，通过参数创建多种产品，不符合开闭原则。
- 工厂方法：一个抽象工厂，多个具体工厂，每个具体工厂创建一个具体产品，符合开闭原则，通过继承实现。
- 抽象工厂：一个抽象工厂，多个具体工厂，每个具体工厂创建“一族”相关的产品，通过继承和组合实现。
在C++中实现工厂方法模式时，有哪些常见的陷阱或需要注意的地方？
在C++里实现工厂方法模式，虽然概念上很清晰，但有些细节如果不注意，确实容易踩坑，或者写出不够健壮的代码。
一个最常见的，也是最致命的陷阱就是内存管理问题。因为工厂方法通常返回一个指向新创建对象的指针（
Product*），如果你返回的是裸指针，那么客户端代码就必须负责调用
delete来释放内存。如果客户端忘记了，或者在复杂的逻辑路径中没有正确处理异常，就很容易造成内存泄漏。这是C++里最让人头疼的问题之一。所以，我的建议是，强烈推荐使用智能指针，比如
std::unique_ptr或
std::shared_ptr。在上面的例子中，我就使用了
std::unique_ptr，它能自动管理内存，当
unique_ptr超出作用域时，它所指向的对象就会被自动删除。这大大降低了内存泄漏的风险，也简化了客户端代码。
另一个需要注意的点是虚析构函数（Virtual Destructors）。当你的工厂方法返回一个基类指针（
Document*），而实际指向的是一个派生类对象（
TextDocument），如果基类没有虚析构函数，那么通过基类指针
delete对象时，只会调用基类的析构函数，而不会调用派生类的析构函数，这会导致派生类特有的资源（比如文件句柄、网络连接等）无法被正确释放，同样是内存泄漏或资源泄漏。所以，抽象产品基类（
Document）和抽象创建者基类（
DocumentCreator）都应该声明虚析构函数，即使它们是空的。
此外，类的数量可能会增加。工厂方法模式的“代价”就是引入了更多的类。每增加一种产品，你可能需要增加一个产品类和一个对应的工厂类。对于非常简单的场景，这种模式可能会显得有些“杀鸡用牛刀”，增加了不必要的复杂性。所以，在决定使用工厂模式前，最好评估一下项目的规模和未来扩展的可能性。如果产品种类很少且稳定，简单工厂或者直接
new可能更合适。设计模式不是银弹，关键在于何时何地使用。
最后，工厂方法的参数设计。有时候，产品的创建可能需要一些参数。工厂方法可以接受这些参数，比如
createDocument(std::string name)。但如果参数过多或者参数组合复杂，工厂方法本身的签名就会变得很臃肿，甚至可能需要引入其他模式（比如建造者模式）来辅助创建参数复杂的对象。保持工厂方法接口的简洁性，也是一个值得考虑的方面。
总而言之，工厂方法模式是一个非常实用的设计模式，但C++的特性（尤其是内存管理）要求我们在使用时更加细致和严谨。用好智能指针和虚析构函数，能让你的工厂模式代码既灵活又健壮。
