1. 项目概述为什么我们需要工厂方法模式在C项目里摸爬滚打久了你肯定遇到过这样的场景代码里到处都是new关键字后面跟着一个具体的类名。比如你要创建一个日志记录器可能是new FileLogger()也可能是new ConsoleLogger()。当需求变动需要增加一个NetworkLogger时你就得把代码里所有创建日志记录器的地方都翻出来改一遍。这不仅仅是体力活更可怕的是你很容易漏掉某个角落或者引入新的错误。这种代码的“坏味道”我们称之为“紧耦合”——创建对象的代码和具体的对象类型死死绑在一起。工厂方法模式要解决的就是这个“创建”的难题。它不是什么高深莫测的黑科技而是一种经过时间考验的设计思路定义一个用于创建对象的接口但让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。听起来有点绕简单说就是把new这个动作封装起来放到一个专门的地方去管理。调用者不需要知道具体创建的是FileLogger还是ConsoleLogger它只跟一个叫“创建日志记录器”的接口打交道。具体创建哪个由对应的“工厂”子类来决定。为什么在C里谈这个特别有感觉因为C没有像Java或C#那样的内置反射机制无法在运行时根据一个字符串类名就轻松创建对象。我们更需要依靠这种清晰、静态类型安全的模式来管理对象的创建。尤其是在构建大型框架、库或者需要支持多种插件、多种配置的项目时工厂方法模式能极大地提升代码的灵活性和可维护性。它让我们的代码在面对变化时不再是“牵一发而动全身”而是具备了优雅的扩展能力。2. 核心概念与UML类图解析在深入代码之前我们必须把工厂方法模式里的几个核心角色搞清楚。这就像搭积木前得先认识每一块积木是干什么的。2.1 模式中的四大角色产品Product 这是所有被创建对象的共同父类或接口。它定义了这些对象共有的方法。在我们的日志例子中这就是Logger基类它可能有一个log(const std::string message)的虚函数。具体产品Concrete Product 实现了产品接口的具体类。比如FileLogger,ConsoleLogger。它们是最终被创建出来的对象。创建者/工厂Creator 声明了“工厂方法”的类这个方法返回一个产品类型的对象。创建者通常包含一些依赖于产品对象的核心业务逻辑。关键点在于创建者并不知道也不关心具体创建的是哪个产品它只和产品接口交互。具体创建者/具体工厂Concrete Creator 重写基类的工厂方法返回一个具体产品的实例。FileLoggerFactory的工厂方法就返回new FileLogger()而ConsoleLoggerFactory返回new ConsoleLogger()。这个模式最精妙的地方在于将对象的“使用”和“创建”解耦了。使用产品的代码在创建者里只依赖于抽象的产品接口而创建具体产品的责任则交给了子类。这样增加一个新的具体产品比如NetworkLogger我们只需要新增一个NetworkLogger类和一个NetworkLoggerFactory类原有的使用代码完全不需要改动。这完美符合了“开闭原则”对扩展开放对修改封闭。2.2 UML类图与关系解读我们可以用文字清晰地描述这个结构这比死记图形更重要interface或基类 Product | | (继承) | -------------------------------- | | ConcreteProductA ConcreteProductB | | -------------------------------- | | (依赖创建) | interface或基类 Creator | (声明工厂方法) | -------------------------------- | | ConcreteCreatorA ConcreteCreatorB FactoryMethod() FactoryMethod() return new ConcreteProductA() return new ConcreteProductB()关系解读继承关系实线空心三角箭头ConcreteProductA/B继承自Product。ConcreteCreatorA/B继承自Creator。依赖关系虚线箭头Creator依赖Product接口因为它工厂方法的返回类型是Product*。ConcreteCreatorA依赖ConcreteProductA因为它在方法内部创建了该类的实例。工厂方法 在Creator中通常是一个纯虚函数如virtual Product* CreateProduct() 0;。在具体创建者中实现它。注意 有些设计把“工厂方法”设计为Creator的非虚方法它调用一个抽象的“钩子”方法来创建产品。这两种变体本质思想一致都是将实例化推迟到子类。我们这里采用更常见的纯虚函数形式。3. 从零开始的C实现一个日志记录器的例子理论说再多不如一行代码。让我们用一个完整的、可编译的C例子把工厂方法模式“焊”在脑子里。我们将实现一个简单的日志系统支持输出到控制台和文件。3.1 第一步定义产品层级首先定义所有日志记录器都要遵守的“契约”——Logger基类。// Product.h #ifndef PRODUCT_H #define PRODUCT_H #include string // 抽象产品日志记录器接口 class Logger { public: virtual ~Logger() default; // 虚析构函数确保正确释放派生类资源 virtual void log(const std::string message) 0; // 纯虚函数核心操作 }; #endif // PRODUCT_H这里使用了 default来声明析构函数这是现代C的好习惯。纯虚函数log使得Logger成为一个抽象类不能直接实例化。接下来实现两个具体产品// ConcreteProducts.h #ifndef CONCRETE_PRODUCTS_H #define CONCRETE_PRODUCTS_H #include “Product.h” #include iostream #include fstream // 具体产品A控制台日志记录器 class ConsoleLogger : public Logger { public: void log(const std::string message) override { std::cout “[Console] “ message std::endl; } }; // 具体产品B文件日志记录器 class FileLogger : public Logger { public: explicit FileLogger(const std::string filename) : outFile_(filename, std::ios::app) { if (!outFile_.is_open()) { throw std::runtime_error(“Failed to open file: “ filename); } } void log(const std::string message) override { if (outFile_.is_open()) { outFile_ “[File] “ message std::endl; } } ~FileLogger() override { if (outFile_.is_open()) { outFile_.close(); } } private: std::ofstream outFile_; }; #endif // CONCRETE_PRODUCTS_HConsoleLogger很简单直接输出到std::cout。FileLogger复杂一些它需要在构造时打开文件并在析构时关闭。这里演示了具体产品可以有自己的状态文件流和特殊的构造逻辑。注意我们抛出了异常这是处理资源打开失败的一种方式在实际工厂中需要妥善处理。3.2 第二步实现创建者层级现在创建负责生产这些日志记录器的工厂。// Creator.h #ifndef CREATOR_H #define CREATOR_H #include “Product.h” #include memory // 抽象创建者日志记录器工厂 class LoggerFactory { public: virtual ~LoggerFactory() default; // 工厂方法返回一个唯一的Logger智能指针 virtual std::unique_ptrLogger createLogger() 0; // 一个可能存在的“模板方法”它使用工厂方法创建的产品 void useLogger(const std::string msg) { auto logger createLogger(); // 调用工厂方法 logger-log(msg); // 使用产品 // ... 可能还有其他使用logger的业务逻辑 } }; #endif // CREATOR_H这里有两个关键点工厂方法createLogger 它是一个纯虚函数具体创建什么由子类决定。模板方法useLogger 这是一个在基类中实现的、使用了工厂方法的方法。它定义了使用日志记录器的标准流程。这是工厂方法模式一个非常强大的应用——父类控制流程框架子类决定具体组件。接着实现具体工厂// ConcreteCreators.h #ifndef CONCRETE_CREATORS_H #define CONCRETE_CREATORS_H #include “Creator.h” #include “ConcreteProducts.h” // 具体创建者A控制台日志工厂 class ConsoleLoggerFactory : public LoggerFactory { public: std::unique_ptrLogger createLogger() override { return std::make_uniqueConsoleLogger(); } }; // 具体创建者B文件日志工厂 class FileLoggerFactory : public LoggerFactory { public: explicit FileLoggerFactory(const std::string filename) : filename_(filename) {} std::unique_ptrLogger createLogger() override { // 注意这里将filename_传递给具体产品的构造函数 return std::make_uniqueFileLogger(filename_); } private: std::string filename_; }; #endif // CONCRETE_CREATORS_HConsoleLoggerFactory的工厂方法直接返回一个ConsoleLogger。FileLoggerFactory需要接收一个文件名参数并在创建FileLogger时传递给它。这展示了工厂可以持有状态并用于配置它创建的产品。3.3 第三步客户端代码与运行示例最后看看客户端代码如何优雅地使用这套体系// main.cpp #include “ConcreteCreators.h” #include vector int main() { // 1. 使用控制台日志工厂 ConsoleLoggerFactory consoleFactory; auto consoleLogger consoleFactory.createLogger(); consoleLogger-log(“Hello from Console Factory!”); // 2. 使用文件日志工厂 FileLoggerFactory fileFactory(“app.log”); auto fileLogger fileFactory.createLogger(); fileLogger-log(“Hello from File Factory!”); // 3. 利用多态和模板方法 std::vectorstd::unique_ptrLoggerFactory factories; factories.push_back(std::make_uniqueConsoleLoggerFactory()); factories.push_back(std::make_uniqueFileLoggerFactory(“app.log”)); std::cout “\nUsing template method:\n”; for (auto factory : factories) { factory-useLogger(“This message is logged via the factory’s template method.”); } // 4. 模拟动态配置例如从配置文件中读取类型 std::string configType “file”; // 模拟配置 std::unique_ptrLoggerFactory configFactory; if (configType “console”) { configFactory std::make_uniqueConsoleLoggerFactory(); } else if (configType “file”) { configFactory std::make_uniqueFileLoggerFactory(“config.log”); } else { std::cerr “Unknown logger type in config!” std::endl; return 1; } auto configuredLogger configFactory-createLogger(); configuredLogger-log(“Log from dynamically configured factory.”); return 0; }这个main函数演示了工厂方法模式的几种典型用法直接使用具体工厂 代码清晰创建逻辑集中。利用多态 将不同工厂放入容器统一调用useLogger模板方法。这是精髓所在客户端代码 (main函数和LoggerFactory::useLogger) 完全不知道ConsoleLogger或FileLogger的存在它只和LoggerFactory与Logger接口交互。动态创建 根据运行时配置如读取文件、用户输入来决定实例化哪个具体工厂。这使得系统非常灵活。实操心得 在这个例子中我全部使用了std::unique_ptr来管理资源。这是现代C的黄金法则之一用智能指针替代裸new/delete。工厂方法返回std::unique_ptrProduct不仅避免了内存泄漏也清晰地表达了所有权的转移——工厂创建了产品并将所有权移交给了调用者。如果你需要共享所有权可以考虑std::shared_ptr但在工厂模式中unique_ptr通常是更合适、更高效的选择。4. 模式变体与进阶应用场景掌握了标准形式我们来看看工厂方法模式在实际项目中那些灵活的变化和典型的用武之地。4.1 参数化工厂方法有时工厂方法需要参数来决定创建哪种产品。一种做法是像我们之前那样通过具体工厂的构造函数传递如FileLoggerFactory的文件名。另一种更直接的方式是给工厂方法本身加参数。class LoggerFactory { public: enum class LoggerType { Console, File }; virtual std::unique_ptrLogger createLogger(LoggerType type, const std::string param “”) { switch (type) { case LoggerType::Console: return std::make_uniqueConsoleLogger(); case LoggerType::File: return std::make_uniqueFileLogger(param); default: return nullptr; } } // ... 此时createLogger可能不是纯虚函数了 };这种变体简化了工厂类的层次结构可能只需要一个具体工厂但牺牲了一些扩展性。增加新的LoggerType需要修改基类中的switch语句违反了开闭原则。它更适合产品类型相对稳定、不会频繁变化的场景。4.2 模板工厂C特色利用C的模板元编程我们可以在编译期就绑定工厂和产品实现类型安全的工厂且无需虚函数开销。template typename T class GenericLoggerFactory { public: std::unique_ptrLogger createLogger() { return std::make_uniqueT(); } }; // 使用 GenericLoggerFactoryConsoleLogger consoleFactory; auto logger consoleFactory.createLogger();这种方式的工厂本身不是多态的它更像一个“创建策略”的包装。它适用于工厂类型在编译时已知且需要极致性能的场景。但它失去了运行时动态替换工厂的能力。4.3 典型应用场景剖析框架与工具库设计 这是工厂方法模式的“主场”。比如一个图形UI框架有一个抽象的Button类以及WindowsButton,MacButton,LinuxButton等具体类。框架定义ButtonFactory接口由平台相关的具体工厂WindowsFactory,MacFactory来创建对应的按钮。应用代码只和Button及ButtonFactory交互实现了跨平台。连接池与资源管理 数据库连接池需要创建不同类型的连接MySQLConnection, PostgreSQLConnection。使用工厂方法池子代码只依赖ConnectionFactory接口具体的连接创建逻辑由MySqlConnectionFactory等实现。更换数据库类型只需更换工厂。游戏开发 游戏中有多种敌人Enemy。一个Level关卡类可能包含一个EnemyFactory成员。不同的关卡ForestLevel,CastleLevel使用不同的具体工厂ForestEnemyFactory,CastleEnemyFactory来生成符合场景的敌人如树妖、骷髅兵。这使得关卡设计和敌人创建逻辑解耦。插件系统与动态加载 虽然C标准不支持直接从类名创建对象但结合动态库DLL/SO和工厂方法可以实现插件系统。主程序定义插件接口Plugin和工厂接口PluginFactory。每个插件动态库导出一个extern “C”函数返回一个PluginFactory实例。主程序加载库获取工厂然后创建插件。这是许多大型软件如GIMP、Blender扩展功能的基础。5. 与简单工厂、抽象工厂的深度对比与选型设计模式常常让人混淆尤其是名字里都带“工厂”的这几个。厘清它们的区别是正确选型的关键。5.1 工厂方法 vs. 简单工厂简单工厂Simple Factory不是一个独立的设计模式更像一种编程习惯。它通常是一个单独的类里面有一个静态方法根据传入的参数用if-else或switch语句来创建并返回不同的产品。class SimpleLoggerFactory { public: static std::unique_ptrLogger createLogger(const std::string type) { if (type “console”) return std::make_uniqueConsoleLogger(); if (type “file”) return std::make_uniqueFileLogger(“default.log”); return nullptr; } };对比与选型结构 简单工厂只有一个具体的工厂类。工厂方法有一个抽象的工厂类和多个具体的工厂类。扩展性 这是核心区别。要增加一个新的产品如NetworkLogger简单工厂必须修改createLogger方法内部的逻辑违反了开闭原则。而工厂方法只需要新增一个NetworkLoggerFactory类原有代码无需改动。复杂度 简单工厂更简单类更少。何时选用简单工厂产品种类很少且几乎确定不会增加或者快速原型开发中追求简单。它把变化控制在一个方法内。工厂方法产品系列可能增长你需要遵循开闭原则希望系统更易于扩展。或者当不同产品的创建过程本身比较复杂、需要不同的初始化时如我们的FileLoggerFactory需要文件名工厂方法能更好地封装这些差异。注意事项 很多初学者会把简单工厂误认为是工厂方法。判断标准是如果新增产品需要修改工厂类的源代码那就是简单工厂如果只需要新增代码那就是工厂方法。5.2 工厂方法 vs. 抽象工厂抽象工厂Abstract Factory模式提供一个接口用于创建一系列相关或依赖的对象家族而无需指定它们具体的类。比如一个UI抽象工厂UIFactory它声明了创建按钮createButton()、创建文本框createTextBox()、创建复选框createCheckBox()等方法。然后有WindowsUIFactory和MacUIFactory分别创建一套风格一致的Windows风格和Mac风格的控件。对比与选型产品维度工厂方法 只关注一种产品的创建。LoggerFactory只创建Logger。抽象工厂 关注多个相关产品的创建。UIFactory创建按钮、文本框等多个产品。抽象层次 抽象工厂的抽象层次更高。它经常使用工厂方法来实现。比如WindowsUIFactory::createButton()内部可能就是return new WindowsButton();这本身就是一个工厂方法。何时选用工厂方法 系统只需要独立地创建某一种产品且未来可能有多种该产品的变体。抽象工厂 系统需要创建一整套产品一个产品家族并且需要保证这些产品是兼容的、一起工作的。例如你不能在一个界面上混用Windows按钮和Mac文本框抽象工厂确保了整套控件风格一致。简单总结 工厂方法是“一对一”一个工厂对应一个产品抽象工厂是“一对多”一个工厂对应多个关联产品。简单工厂是“一锅烩”一个方法创建所有产品。6. 在C中的实现陷阱、性能考量与最佳实践用C实现设计模式除了理解模式本身还得考虑语言特性带来的特定问题和优化点。6.1 对象所有权与生命周期管理这是C实现工厂模式的首要考虑。工厂创建了对象谁负责删除它原始指针不推荐Logger* LoggerFactory::createLogger()。这要求调用者必须记得delete极易导致内存泄漏。除非在非常受限的环境如嵌入式无异常、无STL否则应避免。智能指针强烈推荐std::unique_ptrLogger LoggerFactory::createLogger()。这是现代C的标准答案。unique_ptr明确了所有权从工厂转移到调用者自动管理生命周期。如果产品需要共享工厂可以返回std::shared_ptr但这会引入额外的引用计数开销需谨慎使用。引用或观察者模式 如果产品的生命周期由另一个上下文如一个全局容器、缓存管理工厂可能只是返回一个已存在对象的引用或弱指针。但这不属于典型的工厂模式范畴。最佳实践工厂方法的返回类型优先使用std::unique_ptr。它在接口中清晰地表达了“来源转移”sink语义。6.2 构造函数的封装与异常安全工厂的一个优势是能封装复杂的构造逻辑。比如一个对象的构造可能需要多个步骤依赖其他服务或者可能失败。std::unique_ptrComplexObject ComplexObjectFactory::create() { // 步骤1获取资源 auto resource acquireResource(); // 可能失败 // 步骤2验证状态 if (!validate(resource)) { throw std::runtime_error(“Validation failed”); } // 步骤3创建并初始化对象 auto obj std::make_uniqueComplexObject(resource); obj-initialize(); // 可能抛出异常 // 步骤4执行后置配置 obj-postConfigure(); return obj; }工厂方法将这一系列可能出错的操作封装起来为调用者提供了一个简洁、安全的创建入口。如果initialize()抛出异常由于obj是智能指针之前申请的资源包括resource如果它也被智能指针管理会被正确清理保证了异常安全。6.3 性能考量虚函数开销与对象池虚函数开销 工厂方法模式涉及多态调用工厂方法和产品方法。每次通过基类指针调用虚函数都有一个间接寻址vptr查找vtable的微小开销。对于性能极其敏感的代码如每秒创建数百万次对象的游戏引擎核心循环这可能成为瓶颈。优化策略 考虑使用上面提到的模板工厂在编译期绑定消除虚函数开销。或者如果产品类型在某个上下文中是确定的可以缓存具体工厂的指针直接调用。频繁创建与对象池 如果对象创建成本很高如涉及数据库连接、网络连接、大量内存分配频繁调用工厂方法会成为性能杀手。优化策略 将工厂方法与对象池模式结合。工厂不再每次都new一个新对象而是从对象池中获取一个空闲对象或者回收再利用的对象。这需要产品对象支持重置状态。6.4 注册式工厂实现真正的运行时动态扩展标准的工厂方法模式通过继承来扩展但新增具体工厂仍需修改代码比如在客户端添加#include “NetworkLoggerFactory.h”并new它。注册式工厂Registry Factory可以做到完全动态新增产品时只需编译并加载新的动态库主程序代码一行都不用改。其核心思想是维护一个全局的“工厂注册表”通常是一个std::mapstd::string, std::functionFactoryFunction。具体工厂在库初始化时如全局静态变量构造函数中向这个注册表注册自己的创建函数。客户端只需通过产品名称字符串从注册表中查找并调用对应的创建函数。// 简化示例 class LoggerFactoryRegistry { public: using CreatorFunc std::functionstd::unique_ptrLogger(); static void registerCreator(const std::string name, CreatorFunc func) { getRegistry()[name] std::move(func); } static std::unique_ptrLogger create(const std::string name) { auto it getRegistry().find(name); if (it ! getRegistry().end()) { return it-second(); // 调用注册的创建函数 } return nullptr; } private: static std::mapstd::string, CreatorFunc getRegistry() { static std::mapstd::string, CreatorFunc registry; return registry; } }; // 在每个具体产品的CPP文件中如ConsoleLogger.cpp namespace { bool registered []() - bool { LoggerFactoryRegistry::registerCreator(“console”, [](){ return std::make_uniqueConsoleLogger(); }); return true; }(); }这种方式是许多插件系统和脚本语言绑定的基础实现了最大程度的解耦和灵活性。7. 在现代C项目中的实战融合与测试策略将模式融入真实的现代C项目还需要考虑工程实践和代码质量。7.1 依赖注入与工厂的结合依赖注入Dependency Injection, DI是一种思想强调将依赖项从类外部“注入”进去而不是在类内部硬编码new。工厂方法模式是实现依赖注入的绝佳工具。// 一个需要Logger的服务类 class DataProcessor { public: // 通过构造函数注入Logger工厂 explicit DataProcessor(std::unique_ptrLoggerFactory loggerFactory) : loggerFactory_(std::move(loggerFactory)) {} void process(const Data data) { auto logger loggerFactory_-createLogger(); logger-log(“Start processing data...”); // ... 处理逻辑 } private: std::unique_ptrLoggerFactory loggerFactory_; }; // 在应用组合根如main函数决定使用哪个具体工厂 int main() { auto factory std::make_uniqueFileLoggerFactory(“processor.log”); DataProcessor processor(std::move(factory)); processor.process(someData); }这样DataProcessor对具体的日志实现一无所知它只依赖于LoggerFactory抽象。测试时我们可以轻松注入一个MockLoggerFactory来验证日志行为。这种结合使得代码更加可测试、可配置、可维护。7.2 单元测试如何Mock工厂和产品可测试性是良好设计的重要指标。工厂方法模式让单元测试变得容易。测试具体产品 直接实例化ConsoleLogger调用其log方法验证输出可能需要重定向std::cout或行为。测试使用工厂的客户端代码 这是重点。我们需要Mock模拟工厂和产品。// 使用Google Test和Google Mock的示例 class MockLogger : public Logger { public: MOCK_METHOD(void, log, (const std::string), (override)); }; class MockLoggerFactory : public LoggerFactory { public: MOCK_METHOD(std::unique_ptrLogger, createLogger, (), (override)); }; TEST(DataProcessorTest, ProcessLogsMessage) { auto mockFactory std::make_uniqueMockLoggerFactory(); auto mockLogger std::make_uniqueMockLogger(); // 设置期望当createLogger被调用时返回我们mock的logger EXPECT_CALL(*mockFactory, createLogger()).WillOnce(Return(ByMove(std::move(mockLogger)))); // 设置期望log方法会被以特定消息调用一次 EXPECT_CALL(*mockLogger, log(“Start processing data...”)); DataProcessor processor(std::move(mockFactory)); processor.process(testData); }通过Mock我们可以精确测试客户端代码是否以正确的参数调用了工厂以及是否正确使用了创建出的产品而无需依赖真实的文件系统或控制台输出。7.3 在大型项目中的代码组织建议目录结构/src /core Logger.h (抽象产品) LoggerFactory.h (抽象工厂) /products ConsoleLogger.h/cpp FileLogger.h/cpp /factories ConsoleLoggerFactory.h/cpp FileLoggerFactory.h/cpp /services (使用工厂的客户端类) main.cpp避免循环依赖 确保抽象层core不依赖于具体实现层products,factories。具体实现层单向依赖于抽象层。使用前向声明 在工厂头文件中使用前向声明class Logger;而不是直接#include “Logger.h”如果可能的话。在工厂的CPP文件中再包含具体产品的头文件。这可以减少编译依赖加速编译。考虑使用单例工厂 如果某个具体工厂在整个程序生命周期内是唯一的、无状态的可以将其实现为单例但需谨慎使用单例模式因为它会引入全局状态。不过更推荐通过依赖注入容器来管理工厂的生命周期。工厂方法模式是C开发者工具箱中一件优雅而强大的武器。它通过将“创建什么”和“何时创建”的决策权下放赋予了代码应对变化的弹性。从简单的switch语句重构到工厂方法再到结合依赖注入、注册表等高级技巧是一个代码设计能力不断提升的过程。理解其精髓并在合适的场景运用你的C代码将告别僵化的new拥抱灵活与清晰。记住模式的最终目的不是套用而是写出更易于理解、维护和扩展的代码。
1. 项目概述为什么我们需要工厂方法模式在C项目里摸爬滚打久了你肯定遇到过这样的场景代码里到处都是new关键字后面跟着一个具体的类名。比如你要创建一个日志记录器可能是new FileLogger()也可能是new ConsoleLogger()。当需求变动需要增加一个NetworkLogger时你就得把代码里所有创建日志记录器的地方都翻出来改一遍。这不仅仅是体力活更可怕的是你很容易漏掉某个角落或者引入新的错误。这种代码的“坏味道”我们称之为“紧耦合”——创建对象的代码和具体的对象类型死死绑在一起。工厂方法模式要解决的就是这个“创建”的难题。它不是什么高深莫测的黑科技而是一种经过时间考验的设计思路定义一个用于创建对象的接口但让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。听起来有点绕简单说就是把new这个动作封装起来放到一个专门的地方去管理。调用者不需要知道具体创建的是FileLogger还是ConsoleLogger它只跟一个叫“创建日志记录器”的接口打交道。具体创建哪个由对应的“工厂”子类来决定。为什么在C里谈这个特别有感觉因为C没有像Java或C#那样的内置反射机制无法在运行时根据一个字符串类名就轻松创建对象。我们更需要依靠这种清晰、静态类型安全的模式来管理对象的创建。尤其是在构建大型框架、库或者需要支持多种插件、多种配置的项目时工厂方法模式能极大地提升代码的灵活性和可维护性。它让我们的代码在面对变化时不再是“牵一发而动全身”而是具备了优雅的扩展能力。2. 核心概念与UML类图解析在深入代码之前我们必须把工厂方法模式里的几个核心角色搞清楚。这就像搭积木前得先认识每一块积木是干什么的。2.1 模式中的四大角色产品Product 这是所有被创建对象的共同父类或接口。它定义了这些对象共有的方法。在我们的日志例子中这就是Logger基类它可能有一个log(const std::string message)的虚函数。具体产品Concrete Product 实现了产品接口的具体类。比如FileLogger,ConsoleLogger。它们是最终被创建出来的对象。创建者/工厂Creator 声明了“工厂方法”的类这个方法返回一个产品类型的对象。创建者通常包含一些依赖于产品对象的核心业务逻辑。关键点在于创建者并不知道也不关心具体创建的是哪个产品它只和产品接口交互。具体创建者/具体工厂Concrete Creator 重写基类的工厂方法返回一个具体产品的实例。FileLoggerFactory的工厂方法就返回new FileLogger()而ConsoleLoggerFactory返回new ConsoleLogger()。这个模式最精妙的地方在于将对象的“使用”和“创建”解耦了。使用产品的代码在创建者里只依赖于抽象的产品接口而创建具体产品的责任则交给了子类。这样增加一个新的具体产品比如NetworkLogger我们只需要新增一个NetworkLogger类和一个NetworkLoggerFactory类原有的使用代码完全不需要改动。这完美符合了“开闭原则”对扩展开放对修改封闭。2.2 UML类图与关系解读我们可以用文字清晰地描述这个结构这比死记图形更重要interface或基类 Product | | (继承) | -------------------------------- | | ConcreteProductA ConcreteProductB | | -------------------------------- | | (依赖创建) | interface或基类 Creator | (声明工厂方法) | -------------------------------- | | ConcreteCreatorA ConcreteCreatorB FactoryMethod() FactoryMethod() return new ConcreteProductA() return new ConcreteProductB()关系解读继承关系实线空心三角箭头ConcreteProductA/B继承自Product。ConcreteCreatorA/B继承自Creator。依赖关系虚线箭头Creator依赖Product接口因为它工厂方法的返回类型是Product*。ConcreteCreatorA依赖ConcreteProductA因为它在方法内部创建了该类的实例。工厂方法 在Creator中通常是一个纯虚函数如virtual Product* CreateProduct() 0;。在具体创建者中实现它。注意 有些设计把“工厂方法”设计为Creator的非虚方法它调用一个抽象的“钩子”方法来创建产品。这两种变体本质思想一致都是将实例化推迟到子类。我们这里采用更常见的纯虚函数形式。3. 从零开始的C实现一个日志记录器的例子理论说再多不如一行代码。让我们用一个完整的、可编译的C例子把工厂方法模式“焊”在脑子里。我们将实现一个简单的日志系统支持输出到控制台和文件。3.1 第一步定义产品层级首先定义所有日志记录器都要遵守的“契约”——Logger基类。// Product.h #ifndef PRODUCT_H #define PRODUCT_H #include string // 抽象产品日志记录器接口 class Logger { public: virtual ~Logger() default; // 虚析构函数确保正确释放派生类资源 virtual void log(const std::string message) 0; // 纯虚函数核心操作 }; #endif // PRODUCT_H这里使用了 default来声明析构函数这是现代C的好习惯。纯虚函数log使得Logger成为一个抽象类不能直接实例化。接下来实现两个具体产品// ConcreteProducts.h #ifndef CONCRETE_PRODUCTS_H #define CONCRETE_PRODUCTS_H #include “Product.h” #include iostream #include fstream // 具体产品A控制台日志记录器 class ConsoleLogger : public Logger { public: void log(const std::string message) override { std::cout “[Console] “ message std::endl; } }; // 具体产品B文件日志记录器 class FileLogger : public Logger { public: explicit FileLogger(const std::string filename) : outFile_(filename, std::ios::app) { if (!outFile_.is_open()) { throw std::runtime_error(“Failed to open file: “ filename); } } void log(const std::string message) override { if (outFile_.is_open()) { outFile_ “[File] “ message std::endl; } } ~FileLogger() override { if (outFile_.is_open()) { outFile_.close(); } } private: std::ofstream outFile_; }; #endif // CONCRETE_PRODUCTS_HConsoleLogger很简单直接输出到std::cout。FileLogger复杂一些它需要在构造时打开文件并在析构时关闭。这里演示了具体产品可以有自己的状态文件流和特殊的构造逻辑。注意我们抛出了异常这是处理资源打开失败的一种方式在实际工厂中需要妥善处理。3.2 第二步实现创建者层级现在创建负责生产这些日志记录器的工厂。// Creator.h #ifndef CREATOR_H #define CREATOR_H #include “Product.h” #include memory // 抽象创建者日志记录器工厂 class LoggerFactory { public: virtual ~LoggerFactory() default; // 工厂方法返回一个唯一的Logger智能指针 virtual std::unique_ptrLogger createLogger() 0; // 一个可能存在的“模板方法”它使用工厂方法创建的产品 void useLogger(const std::string msg) { auto logger createLogger(); // 调用工厂方法 logger-log(msg); // 使用产品 // ... 可能还有其他使用logger的业务逻辑 } }; #endif // CREATOR_H这里有两个关键点工厂方法createLogger 它是一个纯虚函数具体创建什么由子类决定。模板方法useLogger 这是一个在基类中实现的、使用了工厂方法的方法。它定义了使用日志记录器的标准流程。这是工厂方法模式一个非常强大的应用——父类控制流程框架子类决定具体组件。接着实现具体工厂// ConcreteCreators.h #ifndef CONCRETE_CREATORS_H #define CONCRETE_CREATORS_H #include “Creator.h” #include “ConcreteProducts.h” // 具体创建者A控制台日志工厂 class ConsoleLoggerFactory : public LoggerFactory { public: std::unique_ptrLogger createLogger() override { return std::make_uniqueConsoleLogger(); } }; // 具体创建者B文件日志工厂 class FileLoggerFactory : public LoggerFactory { public: explicit FileLoggerFactory(const std::string filename) : filename_(filename) {} std::unique_ptrLogger createLogger() override { // 注意这里将filename_传递给具体产品的构造函数 return std::make_uniqueFileLogger(filename_); } private: std::string filename_; }; #endif // CONCRETE_CREATORS_HConsoleLoggerFactory的工厂方法直接返回一个ConsoleLogger。FileLoggerFactory需要接收一个文件名参数并在创建FileLogger时传递给它。这展示了工厂可以持有状态并用于配置它创建的产品。3.3 第三步客户端代码与运行示例最后看看客户端代码如何优雅地使用这套体系// main.cpp #include “ConcreteCreators.h” #include vector int main() { // 1. 使用控制台日志工厂 ConsoleLoggerFactory consoleFactory; auto consoleLogger consoleFactory.createLogger(); consoleLogger-log(“Hello from Console Factory!”); // 2. 使用文件日志工厂 FileLoggerFactory fileFactory(“app.log”); auto fileLogger fileFactory.createLogger(); fileLogger-log(“Hello from File Factory!”); // 3. 利用多态和模板方法 std::vectorstd::unique_ptrLoggerFactory factories; factories.push_back(std::make_uniqueConsoleLoggerFactory()); factories.push_back(std::make_uniqueFileLoggerFactory(“app.log”)); std::cout “\nUsing template method:\n”; for (auto factory : factories) { factory-useLogger(“This message is logged via the factory’s template method.”); } // 4. 模拟动态配置例如从配置文件中读取类型 std::string configType “file”; // 模拟配置 std::unique_ptrLoggerFactory configFactory; if (configType “console”) { configFactory std::make_uniqueConsoleLoggerFactory(); } else if (configType “file”) { configFactory std::make_uniqueFileLoggerFactory(“config.log”); } else { std::cerr “Unknown logger type in config!” std::endl; return 1; } auto configuredLogger configFactory-createLogger(); configuredLogger-log(“Log from dynamically configured factory.”); return 0; }这个main函数演示了工厂方法模式的几种典型用法直接使用具体工厂 代码清晰创建逻辑集中。利用多态 将不同工厂放入容器统一调用useLogger模板方法。这是精髓所在客户端代码 (main函数和LoggerFactory::useLogger) 完全不知道ConsoleLogger或FileLogger的存在它只和LoggerFactory与Logger接口交互。动态创建 根据运行时配置如读取文件、用户输入来决定实例化哪个具体工厂。这使得系统非常灵活。实操心得 在这个例子中我全部使用了std::unique_ptr来管理资源。这是现代C的黄金法则之一用智能指针替代裸new/delete。工厂方法返回std::unique_ptrProduct不仅避免了内存泄漏也清晰地表达了所有权的转移——工厂创建了产品并将所有权移交给了调用者。如果你需要共享所有权可以考虑std::shared_ptr但在工厂模式中unique_ptr通常是更合适、更高效的选择。4. 模式变体与进阶应用场景掌握了标准形式我们来看看工厂方法模式在实际项目中那些灵活的变化和典型的用武之地。4.1 参数化工厂方法有时工厂方法需要参数来决定创建哪种产品。一种做法是像我们之前那样通过具体工厂的构造函数传递如FileLoggerFactory的文件名。另一种更直接的方式是给工厂方法本身加参数。class LoggerFactory { public: enum class LoggerType { Console, File }; virtual std::unique_ptrLogger createLogger(LoggerType type, const std::string param “”) { switch (type) { case LoggerType::Console: return std::make_uniqueConsoleLogger(); case LoggerType::File: return std::make_uniqueFileLogger(param); default: return nullptr; } } // ... 此时createLogger可能不是纯虚函数了 };这种变体简化了工厂类的层次结构可能只需要一个具体工厂但牺牲了一些扩展性。增加新的LoggerType需要修改基类中的switch语句违反了开闭原则。它更适合产品类型相对稳定、不会频繁变化的场景。4.2 模板工厂C特色利用C的模板元编程我们可以在编译期就绑定工厂和产品实现类型安全的工厂且无需虚函数开销。template typename T class GenericLoggerFactory { public: std::unique_ptrLogger createLogger() { return std::make_uniqueT(); } }; // 使用 GenericLoggerFactoryConsoleLogger consoleFactory; auto logger consoleFactory.createLogger();这种方式的工厂本身不是多态的它更像一个“创建策略”的包装。它适用于工厂类型在编译时已知且需要极致性能的场景。但它失去了运行时动态替换工厂的能力。4.3 典型应用场景剖析框架与工具库设计 这是工厂方法模式的“主场”。比如一个图形UI框架有一个抽象的Button类以及WindowsButton,MacButton,LinuxButton等具体类。框架定义ButtonFactory接口由平台相关的具体工厂WindowsFactory,MacFactory来创建对应的按钮。应用代码只和Button及ButtonFactory交互实现了跨平台。连接池与资源管理 数据库连接池需要创建不同类型的连接MySQLConnection, PostgreSQLConnection。使用工厂方法池子代码只依赖ConnectionFactory接口具体的连接创建逻辑由MySqlConnectionFactory等实现。更换数据库类型只需更换工厂。游戏开发 游戏中有多种敌人Enemy。一个Level关卡类可能包含一个EnemyFactory成员。不同的关卡ForestLevel,CastleLevel使用不同的具体工厂ForestEnemyFactory,CastleEnemyFactory来生成符合场景的敌人如树妖、骷髅兵。这使得关卡设计和敌人创建逻辑解耦。插件系统与动态加载 虽然C标准不支持直接从类名创建对象但结合动态库DLL/SO和工厂方法可以实现插件系统。主程序定义插件接口Plugin和工厂接口PluginFactory。每个插件动态库导出一个extern “C”函数返回一个PluginFactory实例。主程序加载库获取工厂然后创建插件。这是许多大型软件如GIMP、Blender扩展功能的基础。5. 与简单工厂、抽象工厂的深度对比与选型设计模式常常让人混淆尤其是名字里都带“工厂”的这几个。厘清它们的区别是正确选型的关键。5.1 工厂方法 vs. 简单工厂简单工厂Simple Factory不是一个独立的设计模式更像一种编程习惯。它通常是一个单独的类里面有一个静态方法根据传入的参数用if-else或switch语句来创建并返回不同的产品。class SimpleLoggerFactory { public: static std::unique_ptrLogger createLogger(const std::string type) { if (type “console”) return std::make_uniqueConsoleLogger(); if (type “file”) return std::make_uniqueFileLogger(“default.log”); return nullptr; } };对比与选型结构 简单工厂只有一个具体的工厂类。工厂方法有一个抽象的工厂类和多个具体的工厂类。扩展性 这是核心区别。要增加一个新的产品如NetworkLogger简单工厂必须修改createLogger方法内部的逻辑违反了开闭原则。而工厂方法只需要新增一个NetworkLoggerFactory类原有代码无需改动。复杂度 简单工厂更简单类更少。何时选用简单工厂产品种类很少且几乎确定不会增加或者快速原型开发中追求简单。它把变化控制在一个方法内。工厂方法产品系列可能增长你需要遵循开闭原则希望系统更易于扩展。或者当不同产品的创建过程本身比较复杂、需要不同的初始化时如我们的FileLoggerFactory需要文件名工厂方法能更好地封装这些差异。注意事项 很多初学者会把简单工厂误认为是工厂方法。判断标准是如果新增产品需要修改工厂类的源代码那就是简单工厂如果只需要新增代码那就是工厂方法。5.2 工厂方法 vs. 抽象工厂抽象工厂Abstract Factory模式提供一个接口用于创建一系列相关或依赖的对象家族而无需指定它们具体的类。比如一个UI抽象工厂UIFactory它声明了创建按钮createButton()、创建文本框createTextBox()、创建复选框createCheckBox()等方法。然后有WindowsUIFactory和MacUIFactory分别创建一套风格一致的Windows风格和Mac风格的控件。对比与选型产品维度工厂方法 只关注一种产品的创建。LoggerFactory只创建Logger。抽象工厂 关注多个相关产品的创建。UIFactory创建按钮、文本框等多个产品。抽象层次 抽象工厂的抽象层次更高。它经常使用工厂方法来实现。比如WindowsUIFactory::createButton()内部可能就是return new WindowsButton();这本身就是一个工厂方法。何时选用工厂方法 系统只需要独立地创建某一种产品且未来可能有多种该产品的变体。抽象工厂 系统需要创建一整套产品一个产品家族并且需要保证这些产品是兼容的、一起工作的。例如你不能在一个界面上混用Windows按钮和Mac文本框抽象工厂确保了整套控件风格一致。简单总结 工厂方法是“一对一”一个工厂对应一个产品抽象工厂是“一对多”一个工厂对应多个关联产品。简单工厂是“一锅烩”一个方法创建所有产品。6. 在C中的实现陷阱、性能考量与最佳实践用C实现设计模式除了理解模式本身还得考虑语言特性带来的特定问题和优化点。6.1 对象所有权与生命周期管理这是C实现工厂模式的首要考虑。工厂创建了对象谁负责删除它原始指针不推荐Logger* LoggerFactory::createLogger()。这要求调用者必须记得delete极易导致内存泄漏。除非在非常受限的环境如嵌入式无异常、无STL否则应避免。智能指针强烈推荐std::unique_ptrLogger LoggerFactory::createLogger()。这是现代C的标准答案。unique_ptr明确了所有权从工厂转移到调用者自动管理生命周期。如果产品需要共享工厂可以返回std::shared_ptr但这会引入额外的引用计数开销需谨慎使用。引用或观察者模式 如果产品的生命周期由另一个上下文如一个全局容器、缓存管理工厂可能只是返回一个已存在对象的引用或弱指针。但这不属于典型的工厂模式范畴。最佳实践工厂方法的返回类型优先使用std::unique_ptr。它在接口中清晰地表达了“来源转移”sink语义。6.2 构造函数的封装与异常安全工厂的一个优势是能封装复杂的构造逻辑。比如一个对象的构造可能需要多个步骤依赖其他服务或者可能失败。std::unique_ptrComplexObject ComplexObjectFactory::create() { // 步骤1获取资源 auto resource acquireResource(); // 可能失败 // 步骤2验证状态 if (!validate(resource)) { throw std::runtime_error(“Validation failed”); } // 步骤3创建并初始化对象 auto obj std::make_uniqueComplexObject(resource); obj-initialize(); // 可能抛出异常 // 步骤4执行后置配置 obj-postConfigure(); return obj; }工厂方法将这一系列可能出错的操作封装起来为调用者提供了一个简洁、安全的创建入口。如果initialize()抛出异常由于obj是智能指针之前申请的资源包括resource如果它也被智能指针管理会被正确清理保证了异常安全。6.3 性能考量虚函数开销与对象池虚函数开销 工厂方法模式涉及多态调用工厂方法和产品方法。每次通过基类指针调用虚函数都有一个间接寻址vptr查找vtable的微小开销。对于性能极其敏感的代码如每秒创建数百万次对象的游戏引擎核心循环这可能成为瓶颈。优化策略 考虑使用上面提到的模板工厂在编译期绑定消除虚函数开销。或者如果产品类型在某个上下文中是确定的可以缓存具体工厂的指针直接调用。频繁创建与对象池 如果对象创建成本很高如涉及数据库连接、网络连接、大量内存分配频繁调用工厂方法会成为性能杀手。优化策略 将工厂方法与对象池模式结合。工厂不再每次都new一个新对象而是从对象池中获取一个空闲对象或者回收再利用的对象。这需要产品对象支持重置状态。6.4 注册式工厂实现真正的运行时动态扩展标准的工厂方法模式通过继承来扩展但新增具体工厂仍需修改代码比如在客户端添加#include “NetworkLoggerFactory.h”并new它。注册式工厂Registry Factory可以做到完全动态新增产品时只需编译并加载新的动态库主程序代码一行都不用改。其核心思想是维护一个全局的“工厂注册表”通常是一个std::mapstd::string, std::functionFactoryFunction。具体工厂在库初始化时如全局静态变量构造函数中向这个注册表注册自己的创建函数。客户端只需通过产品名称字符串从注册表中查找并调用对应的创建函数。// 简化示例 class LoggerFactoryRegistry { public: using CreatorFunc std::functionstd::unique_ptrLogger(); static void registerCreator(const std::string name, CreatorFunc func) { getRegistry()[name] std::move(func); } static std::unique_ptrLogger create(const std::string name) { auto it getRegistry().find(name); if (it ! getRegistry().end()) { return it-second(); // 调用注册的创建函数 } return nullptr; } private: static std::mapstd::string, CreatorFunc getRegistry() { static std::mapstd::string, CreatorFunc registry; return registry; } }; // 在每个具体产品的CPP文件中如ConsoleLogger.cpp namespace { bool registered []() - bool { LoggerFactoryRegistry::registerCreator(“console”, [](){ return std::make_uniqueConsoleLogger(); }); return true; }(); }这种方式是许多插件系统和脚本语言绑定的基础实现了最大程度的解耦和灵活性。7. 在现代C项目中的实战融合与测试策略将模式融入真实的现代C项目还需要考虑工程实践和代码质量。7.1 依赖注入与工厂的结合依赖注入Dependency Injection, DI是一种思想强调将依赖项从类外部“注入”进去而不是在类内部硬编码new。工厂方法模式是实现依赖注入的绝佳工具。// 一个需要Logger的服务类 class DataProcessor { public: // 通过构造函数注入Logger工厂 explicit DataProcessor(std::unique_ptrLoggerFactory loggerFactory) : loggerFactory_(std::move(loggerFactory)) {} void process(const Data data) { auto logger loggerFactory_-createLogger(); logger-log(“Start processing data...”); // ... 处理逻辑 } private: std::unique_ptrLoggerFactory loggerFactory_; }; // 在应用组合根如main函数决定使用哪个具体工厂 int main() { auto factory std::make_uniqueFileLoggerFactory(“processor.log”); DataProcessor processor(std::move(factory)); processor.process(someData); }这样DataProcessor对具体的日志实现一无所知它只依赖于LoggerFactory抽象。测试时我们可以轻松注入一个MockLoggerFactory来验证日志行为。这种结合使得代码更加可测试、可配置、可维护。7.2 单元测试如何Mock工厂和产品可测试性是良好设计的重要指标。工厂方法模式让单元测试变得容易。测试具体产品 直接实例化ConsoleLogger调用其log方法验证输出可能需要重定向std::cout或行为。测试使用工厂的客户端代码 这是重点。我们需要Mock模拟工厂和产品。// 使用Google Test和Google Mock的示例 class MockLogger : public Logger { public: MOCK_METHOD(void, log, (const std::string), (override)); }; class MockLoggerFactory : public LoggerFactory { public: MOCK_METHOD(std::unique_ptrLogger, createLogger, (), (override)); }; TEST(DataProcessorTest, ProcessLogsMessage) { auto mockFactory std::make_uniqueMockLoggerFactory(); auto mockLogger std::make_uniqueMockLogger(); // 设置期望当createLogger被调用时返回我们mock的logger EXPECT_CALL(*mockFactory, createLogger()).WillOnce(Return(ByMove(std::move(mockLogger)))); // 设置期望log方法会被以特定消息调用一次 EXPECT_CALL(*mockLogger, log(“Start processing data...”)); DataProcessor processor(std::move(mockFactory)); processor.process(testData); }通过Mock我们可以精确测试客户端代码是否以正确的参数调用了工厂以及是否正确使用了创建出的产品而无需依赖真实的文件系统或控制台输出。7.3 在大型项目中的代码组织建议目录结构/src /core Logger.h (抽象产品) LoggerFactory.h (抽象工厂) /products ConsoleLogger.h/cpp FileLogger.h/cpp /factories ConsoleLoggerFactory.h/cpp FileLoggerFactory.h/cpp /services (使用工厂的客户端类) main.cpp避免循环依赖 确保抽象层core不依赖于具体实现层products,factories。具体实现层单向依赖于抽象层。使用前向声明 在工厂头文件中使用前向声明class Logger;而不是直接#include “Logger.h”如果可能的话。在工厂的CPP文件中再包含具体产品的头文件。这可以减少编译依赖加速编译。考虑使用单例工厂 如果某个具体工厂在整个程序生命周期内是唯一的、无状态的可以将其实现为单例但需谨慎使用单例模式因为它会引入全局状态。不过更推荐通过依赖注入容器来管理工厂的生命周期。工厂方法模式是C开发者工具箱中一件优雅而强大的武器。它通过将“创建什么”和“何时创建”的决策权下放赋予了代码应对变化的弹性。从简单的switch语句重构到工厂方法再到结合依赖注入、注册表等高级技巧是一个代码设计能力不断提升的过程。理解其精髓并在合适的场景运用你的C代码将告别僵化的new拥抱灵活与清晰。记住模式的最终目的不是套用而是写出更易于理解、维护和扩展的代码。
 存储型XSS)
