C++工厂方法模式实战：从原理到工程落地

工厂方法模式这名字，看着像教科书里的老古董，但实际项目里它的出场率极高。凡是你要写框架、做插件系统、支持多平台渲染、按文件类型分发解析器，基本都绕不开它。这篇文章我不会从头给你念教材定义，而是从“为什么需要它”讲起，直接给你一份能在工程里落地的 C++ 实现方案，顺便把我踩过的那些坑一并交代清楚。

适合谁看？刚把 C++ 语法摸了个大概、开始在项目里琢磨设计模式的读者；以及写过一阵子业务代码、觉得switch分支越堆越臭、想重构又不知道从哪下手的同学。看之前只需要一个前提：你知道类继承、虚函数、智能指针是干什么的就行。

1. 一个伪装成构造函数的问题

1.1 工厂方法模式到底是什么

先花两分钟把概念锚定住。工厂方法模式的官方定义是：定义一个用于创建对象的接口，让子类决定实例化哪一个类。这句话信息密度不低，拆开了就是三层意思：

• 有一个统一的“创建入口”，客户端只跟这个入口打交道；
• 入口本身是个接口，不一定自己干活，而是把“具体创建哪个对象”的决策权下放给子类；
• 创建出来的东西，客户端只关心它的抽象类型（基类接口），不关心具体实现。

打个比方。你开一家餐厅，菜单上写着“今日甜点”。至于今天是提拉米苏还是抹茶蛋糕，由后厨（子类）决定。客人不会走进厨房喊“给我来一份安佳淡奶油做的提拉米苏”，他只需要对着菜单点“甜点”，后厨自己知道今天该做什么。

对应到代码里，"今日甜点"就是工厂方法，后厨就是具体工厂子类，甜点就是产品对象，客人就是客户端代码。

1.2 它解决了什么痛点

你要是不用工厂方法，最常见的写法是直接在客户端里switch或者if-else判断类型，然后挨个调用不同类的构造函数：

std::unique_ptr<Parser> createParser(const std::string& fileType) { if (fileType == "json") { return std::make_unique<JsonParser>(); } else if (fileType == "xml") { return std::make_unique<XmlParser>(); } else if (fileType == "yaml") { return std::make_unique<YamlParser>(); } else { throw std::invalid_argument("unknown type"); } }

这段代码能跑，但问题很明显：

第一，每新增一种文件格式，你就要回来改这个函数，再加一个else if。改着改着，这个函数的职责就膨胀了，今天加格式、明天加配置、后天加权限判断，一个“创建对象”的简单动作最后变成几百行的业务杂烩。

第二，所有调用方都耦合到了这个具体判断逻辑上。一旦某个格式被废弃、某个分支要调整，牵一发动全身。

第三，违反了一个重要原则：对扩展开放，对修改封闭。理想状态应该是，新增一种产品类型时，新建一个产品类、新建一个对应的创建者子类，就够了。已有的稳定代码一行都不用动。

工厂方法模式的思路，就是把上面那段if-else从客户端代码里挪走，放回到“具体的工厂子类”里，让每个子类只负责创建自己那一类产品。客户端对着一堆不同的工厂子类调用同一个创建接口，拿到的却是各自对应的产品。

2. 模式核心：四个角色一张网

2.1 四个参与者的职责划分

工厂方法模式听起来抽象，其实角色非常固定，就四个，理解透了这模式也就拿下了。

Product（产品接口）：定义产品的公共接口。所有具体产品都必须实现这个接口，这样客户端才能用统一的方式操作它们。

ConcreteProduct（具体产品）：实现产品接口的具体类。比如上文里的 JSON 解析器、XML 解析器，各是各的实体。

Creator（创建者基类）：声明工厂方法createProduct()，并定义依赖该工厂方法的其他逻辑。注意，基类里的工厂方法可以是纯虚的，让子类完全自己实现；也可以提供一个默认实现，子类选择覆写。

ConcreteCreator（具体创建者）：覆写工厂方法，返回具体的产品实例。一个具体创建者通常只负责一种具体产品的创建。

这四个角色的关系用一个很朴素的说法概括就是：创建者基类定义“怎么用产品”的模板，具体创建者负责“造什么产品”。至于产品内部的构造细节、初始化流程，创建者不管，那是具体产品自己的事。

2.2 为什么说它是"虚拟构造函数"

业内有个说法，工厂方法模式的本质是“虚拟构造函数”（virtual constructor）。C++ 的语法规定构造函数不能是虚函数，因为构造对象时对象还没产生，虚函数机制压根无从谈起。

但业务上你确实需要“多态的创建”：同一个创建接口，在不同上下文里返回不同类型的对象。工厂方法就是绕开语言限制、手工模拟虚构造函数的手段：基类声明创建接口，子类提供不同的实现，行为上等效于“构造函数被虚化了”。

理解到这一层，很多问题就豁然开朗。比如我之前带过的一位新人，他死活想不通“为什么不能直接在基类构造函数里调用工厂方法”。原因就在于：基类构造函数执行时，子类部分还没构造完成，此时调用任何虚函数，都不会走到子类实现，这属于 C++ 的未定义行为，而且编译器连警告都不一定给你出。工厂方法创造的“延迟绑定”，恰恰规避了这个坑，调用发生时对象已经完全构造好，虚函数自然工作正常。

再说一个工程层面的原因。构造函数后紧跟初始化逻辑的场景非常常见：创建完对象要注册到管理器、要加载配置文件、要建立连接。这些逻辑放在构造函数里很别扭，尤其是要抛异常的时候——构造函数里抛异常，对象是没构造完成的，资源回收就得格外小心。把“创建 + 后续处理”打包放到工厂方法里，你的控制力会强得多，异常安全也好设计。

3. C++落地：从理论基础到可编译代码

3.1 传统基础版的重点

工厂方法模式本身历史悠久，但 C++ 里的实现方式一直在进化。先看一个“教科书经典版”的核心框架：

// 产品接口 class Document { public: virtual ~Document() = default; virtual void open() = 0; virtual void save() = 0; }; // 具体产品 A class TextDocument : public Document { public: void open() override { /* 打开文本文件的逻辑 */ } void save() override { /* 保存文本文件的逻辑 */ } }; // 具体产品 B class ImageDocument : public Document { public: void open() override { /* 打开图片文件的逻辑 */ } void save() override { /* 保存图片文件的逻辑 */ } }; // 创建者基类 class Application { public: virtual ~Application() = default; // 工厂方法：负责创建产品 virtual std::unique_ptr<Document> createDocument() = 0; // 使用产品的模板逻辑 void newDocument() { auto doc = createDocument(); doc->open(); // 其他业务逻辑... m_docs.push_back(std::move(doc)); } private: std::vector<std::unique_ptr<Document>> m_docs; }; // 具体创建者 A class TextApplication : public Application { public: std::unique_ptr<Document> createDocument() override { return std::make_unique<TextDocument>(); } }; // 具体创建者 B class ImageApplication : public Application { public: std::unique_ptr<Document> createDocument() override { return std::make_unique<ImageDocument>(); } };

这个例子是经典文档编辑器案例的精简版。你注意几个关键设计决策：

工厂方法的返回类型：必须是产品基类（或其抽象引用），不能返回具体类型。否则客户端拿到的是具体类型，就无法实现多态使用。这就是为什么返回std::unique_ptr<Document>而不是std::unique_ptr<TextDocument>。

基类要声明虚析构函数：这是 C++ 的硬规矩。只要类里有虚函数，尤其是这个类要通过基类指针管理派生类对象的生命周期，析构函数就必须加virtual。忘了这一条，delete基类指针时就不会调用派生类析构函数，资源泄漏悄悄发生。

返回值用智能指针：我第一次正经写这个模式时用的是裸指针，每次调用工厂都要记得delete。业务一复杂，漏删一处，内存泄漏就埋伏上了。现在统一用std::unique_ptr，工厂方法天然表达“创建出来的对象所有权归调用者”，调用者用完自动释放，连异常安全都顺带解决了——因为unique_ptr的析构是 RAII 的，栈展开时一定会执行。

使用者在面对抽象：Application::newDocument()里，从头到尾没有出现任何具体产品类名。它只知道createDocument()会返回一个Document，于是就能调用Document接口上的方法。这就是“依赖于抽象，不依赖于具体”的直观体现。

3.2 现代 C++ 写法的几个改进

上面这个版本已经能用了，但工程上还有几个可以打磨的点。

用override关键字显式标注覆写：这是 C++11 就有的特性，但我在实际 code review 里还是见过有人不写。override让编译器帮你检查：如果函数签名和基类不一致（比如漏了const），编译直接报错，不会等你运行时才发现“咦，怎么调的是基类的实现”。

工厂方法可以考虑提供默认实现：不一定非得是纯虚的。有些创建者基类有“默认产品”的概念，子类不覆写就用默认的，覆写了就用定制的。这给了使用者更大的灵活性。

参数化工厂方法：前面提到按文件类型创建解析器的场景，工厂方法可以接收一个参数，根据参数返回不同产品。这其实是工厂方法模式里一种常见变体。不过要小心，参数化工厂方法和“简单工厂”的边界容易模糊，后面我会专门讲区别。

配合auto简化客户端代码：既然返回值类型是明确的，客户端可以用auto承接，减少类型书写的噪音：

void Application::openRecent(const std::string& filePath) { auto doc = createDocument(); doc->openFrom(filePath); m_docs.push_back(std::move(doc)); }

3.3 对象切片：最容易忽视的严重问题

我在实际排查过一个非常隐蔽的 bug，症状是：工厂方法返回了一个派生类对象，客户端拿到的却像是个“残废版”的基类对象，调用派生类特有的接口直接崩溃。

问题根源就是对象切片（object slicing）。有人贪图方便，工厂方法返回类型写成了基类的值类型，比如Document而不是std::unique_ptr<Document>：

Document createDocument() { // 错误示范 return TextDocument(); // 切片发生了 }

这里TextDocument会被切割成Document，派生类部分的成员全部丢失。编译器偶尔会给个警告，但很多时候是静默的。而且这个“切片版对象”析构时不会调用派生类析构函数，又是一个隐患。

正确做法永远只有一个：通过指针或引用的方式返回多态对象，现代 C++ 首选std::unique_ptr等智能指针。记住，在 C++ 里，值和多态天生不兼容。

4. 实战案例：一套支持多格式的日志系统

理论讲得再透彻，不如把工程案例完整过一遍。我带过一个小型日志采集模块，需求是这样的：

• 支持控制台输出、文件输出、网络上报三种日志目的地；
• 每种目的地有不同的配置参数（文件路径、上报接口地址等）；
• 日志模块是公共库，使用方可能只想要其中一种，也可能三种全要；
• 未来极大概率会新增目的地（比如消息队列）。

你品一下这个需求，“未来要新增 + 使用方按需选择 + 创建逻辑可能复杂”，这就是工厂方法模式的典型温床。

4.1 产品与创建者的设计

先设计产品接口。所有日志目的地都得支持write(level, message)，以及可选的flush()：

enum class LogLevel { Debug, Info, Warn, Error }; class LogSink { public: virtual ~LogSink() = default; virtual void write(LogLevel level, const std::string& message) = 0; virtual void flush() {} };

三个具体产品：

class ConsoleSink : public LogSink { public: void write(LogLevel level, const std::string& message) override { std::cout << formatMessage(level, message) << std::endl; } void flush() override {} }; class FileSink : public LogSink { public: explicit FileSink(const std::string& filePath) { m_stream.open(filePath, std::ios::app); if (!m_stream.is_open()) { throw std::runtime_error("failed to open log file: " + filePath); } } void write(LogLevel level, const std::string& message) override { m_stream << formatMessage(level, message) << std::endl; } void flush() override { m_stream.flush(); } ~FileSink() override { if (m_stream.is_open()) m_stream.close(); } private: std::ofstream m_stream; }; class NetworkSink : public LogSink { public: explicit NetworkSink(const std::string& endpoint) : m_endpoint(endpoint) { // 实际项目里这里会建立连接、做鉴权等 } void write(LogLevel level, const std::string& message) override { // 发送数据到远端 } void flush() override {} private: std::string m_endpoint; };

注意到FileSink的构造函数里有一处文件打开失败检查，抛异常。这个细节等会还会提到，因为异常会穿过工厂方法，考验你的异常安全设计。

接着是创建者。这里我选择用参数化工厂方法，因为“按目的地类型创建”本身就是模块对外的主要入口：

enum class SinkType { Console, File, Network }; class SinkFactory { public: virtual ~SinkFactory() = default; virtual std::unique_ptr<LogSink> createSink(SinkType type) = 0; }; class DefaultSinkFactory : public SinkFactory { public: std::unique_ptr<LogSink> createSink(SinkType type) override { switch (type) { case SinkType::Console: return std::make_unique<ConsoleSink>(); case SinkType::File: return std::make_unique<FileSink>(m_defaultFilePath); case SinkType::Network: return std::make_unique<NetworkSink>(m_defaultEndpoint); default: throw std::invalid_argument("unsupported sink type"); } } // 允许使用者修改默认参数 void setDefaultFilePath(std::string path) { m_defaultFilePath = std::move(path); } void setDefaultEndpoint(std::string endpoint) { m_defaultEndpoint = std::move(endpoint); } private: std::string m_defaultFilePath = "app.log"; std::string m_defaultEndpoint = "http://127.0.0.1:8080/log"; };

为什么这里仍然抛出异常而不是返回nullptr？这是工程上一个值得斟酌的点。nullptr会把错误悄然传递给调用方，调用方如果忘了判空，后续解引用直接崩溃；而异常则迫使调用方处理或让异常继续上抛，错误在更早的阶段暴露。而且现在调用方拿到的是unique_ptr，如果返回nullptr，调用方直接sink->write(...)，在大多数编译器和运行时环境下就是段错误，问题定位成本很高。抛异常虽然让调用方多写一个try-catch，但从工程可靠性上看是值得的。

4.2 调用方的视角

使用这个日志模块的代码长这样：

class Logger { public: explicit Logger(std::unique_ptr<SinkFactory> factory) : m_factory(std::move(factory)) {} void initialize(SinkType type) { m_sink = m_factory->createSink(type); } void log(LogLevel level, const std::string& message) { if (m_sink) { m_sink->write(level, message); } } private: std::unique_ptr<SinkFactory> m_factory; std::unique_ptr<LogSink> m_sink; };

客户端使用：

int main() { auto factory = std::make_unique<DefaultSinkFactory>(); Logger logger(std::move(factory)); logger.initialize(SinkType::File); logger.log(LogLevel::Info, "application started"); return 0; }

你看，Logger完全不知道世界上存在ConsoleSink还是FileSink，它面对的只有SinkFactory::createSink()和LogSink::write()。将来新增一个KafkaSink，代码改动范围严格限制在：

1. SinkType枚举加一个值；
2. 新增KafkaSink类；
3. DefaultSinkFactory::createSink()加一个case。

其他地方一行都不用动。这就是开闭原则带给你的红利。我在这个项目中测过，从“写一个新的日志接入方”到“编译通过 + 功能验证”，一个熟悉代码库的工程师大概不到半小时就能完成，而且不会碰坏任何旧功能。

4.3 构造失败时怎么办

这节专门展开讲异常，因为这里藏着一个容易被忽视的设计决策。看这个场景：FileSink构造时文件打开失败，抛出了std::runtime_error。这个异常会从工厂方法里穿出来，到达Logger::initialize()，再往上到main()。

问题来了：Logger对象此时处于什么状态？

这取决于你怎么写initialize：

void initialize(SinkType type) { m_sink = m_factory->createSink(type); }

在createSink抛异常时，m_sink的赋值根本不会发生，m_sink保持原状（要么是nullptr，要么是之前那个正常工作的 sink）。这个行为是由 C++ 的异常安全保证决定的：如果赋值操作本身不抛异常，且右侧的求值先于赋值发生，那么异常发生时赋值压根不会执行。

这就给了一个很好的兜底策略：如果当前 logger 已经在用控制台输出，尝试切换到文件输出时文件打开失败，logger 可以优雅地继续用控制台，而不是直接崩溃。用户最多看到一条“文件打开失败”的上层错误提示，程序还能正常运行。

我在另一个项目里见过反面教材：工厂方法内部捕获所有异常，然后返回nullptr。结果调用方拿到nullptr后仍然继续调用write()，段错误发生在生产环境里，排查了半天才发现是“临时目录没权限”这种小事。所以我在代码注释里专门写了一条：工厂方法不要吞异常，把决策权留给调用方。

5. 常见误区和排查实录

5.1 误区一：为造对象而造对象，过度设计

工厂方法模式不是银弹。它的核心价值是解耦和扩展性，但引入的代价是类数量翻倍：每多一个产品，就要多一个创建者子类（或者多一个分支）。

判断“值不值得用”有一个简单标准：如果创建对象的逻辑只有一行return make_unique<Thing>();，而这个 Thing 在未来可预期的两三年内不会有第二种子类，那用工厂方法纯粹是给自己加戏。等产品种类真的多起来了，再从简单创建重构到工厂方法，成本一点也不高。

我个人的经验阈值是：产品种类大约到 3 类以上，或者客户端明确存在“面向接口调用、不关心具体类型”的需求，才上工厂方法。1~2 种类型时，直接在构造函数里做好，或者用命名构造函数都行。

5.2 误区二：构造函数里搞魔法

有人会把工厂逻辑塞进构造函数，期望通过某个成员变量来判断该创建哪种产品。这在 C++ 里几乎必然翻车，原因前面提到过：构造函数执行期间，虚函数不派发到派生类。

还有一个更隐蔽的变种：基类构造函数里调用一个普通的、非虚的init()函数，这个init()里再调用虚的工厂方法。看起来好像绕过了“构造期间调用虚函数”的问题，实际上没有。在基类构造函数执行init()时，对象的动态类型仍然是基类，虚函数照样不会走到派生类版本。这个坑我在一次代码评审里看到过，写代码的人一脸笃定地说“我测过，没问题的”——那是因为他的测试场景恰好没有触发那个分支。

规则很简单也很暴力：不要在构造函数里调用任何虚函数，也不要在构造函数里调用最终会调度到虚函数的间接函数。

5.3 误区三：工厂方法返回类型写错

把返回类型写成具体产品，或者写成基类值类型，都会出问题。前者让多态失效，客户端硬编码依赖具体类型；后者直接对象切片，运行时行为完全不可预期。

排查这个问题的技巧：如果发现“对象的类型对了，但行为不对”，比如调不到派生类扩展的接口，或者虚函数调用表现异常，优先检查工厂方法的返回类型是不是指针/引用形式的基类。别先怀疑业务逻辑，这种低级错误往往逍遥得很久。

5.4 误区四：单例工厂和全局工厂

我曾经一度想把工厂做成单例，觉得“一个工厂全局用，多方便”。后来在并发测试里撞了墙：工厂内部有状态（比如默认文件路径、默认连接端点），多线程同时调用createSink()时，状态被互相覆盖，创建出来的产品配置错乱。

教训就是：工厂最好保持“无状态”或仅持有不可变配置，如果要动态配置，给每个线程（或每个使用者）持有自己的工厂实例，或者引入同步机制。全局唯一工厂 + 可变状态，是并发 bug 的温床。

另外还要警惕“服务定位器”式的全局工厂——把所有类型的创建逻辑都塞进一个巨大的静态工厂类里。那本质上又是一个变种的上帝类，复杂度会随着产品种类线性膨胀，还不如老老实实用几个互相解耦的工厂子类。

5.5 一份问题排查速查表

6. 工厂方法 vs 简单工厂 vs 抽象工厂

这三个概念同居一室，很多人容易搞混。我给出一个非常朴素的区分方式。

简单工厂不是一个 GoF 设计模式，只是一个编码习惯。它通常是一个静态函数（或一个不做多态的类），内部用switch或if-else决定创建什么产品。客户端不直接 new，但静态函数本身没法被继承扩展，新增产品还是要改它。简单工厂适合产品种类较少、变化不频繁的小场景。

工厂方法就是本文的主角。它把创建逻辑做成虚函数，每个子类决定创建什么。扩展方式是继承。

抽象工厂解决的问题是“一族相关产品”的整体创建。比如跨平台 UI 库，一族的控件（按钮、输入框、列表）必须在同一个平台上保持一致风格，你不能一个用 Windows 风格按钮、配一个 Mac 风格输入框。抽象工厂接口里声明一组工厂方法，每个工厂方法创建一个族内产品。

啥时候用哪个？一句话版本：

• 就一个产品维度、少量类型，懒得引入太多类 → 简单工厂；
• 一个产品维度、类型可能扩展、客户端要解耦 → 工厂方法；
• 多个产品维度、且产品之间存在配套约束 → 抽象工厂。

要注意的是，实际项目里这三种写法经常共存。比如抽象工厂的每个创建方法，内部可能又组合了工厂方法或简单工厂逻辑。设计模式不是互斥的教条，它们是可以嵌套搭配的工具。

7. 我在工程中实践后的一些体会

最后分享几个实实在在的体感。

工厂方法模式不是写出了“一个工厂类”就算会用，真正的判断标准是：当需求变化到来时，你的改动是不是被限制在一个很小的范围内。如果你的工厂方法实现得很好，新增一种产品类型，应该像“往书架里插一本新书”一样自然，而不是要把整个书架拆了重建。

C++ 实现这个模式的现代姿势，绕不开三个关键词：unique_ptr、虚析构、override。这三个点做到位，内存和异常安全就有了基本盘。我见过太多人把工厂方法模式学了个形似，返回裸指针、基类析构没加virtual，用起来每天都在雷区边缘试探。

另外，模式学习不要止步于“会写代码”。试着把工厂方法放在更大的上下文里看：配合模板方法模式，创建者基类可以定义一套完整的“使用产品的流程”；配合注册表/原型模式，可以实现基于配置的反射式创建；配合策略模式，工厂创建出来的产品可以携带不同的行为算法。设计模式之间是互相咬合的齿轮，单看一个是片面的，把它们组合起来，才是真正的架构能力。

如果你正打算重构一段满屏if-else的创建逻辑，动手前建议先在纸上画出四个角色，标清楚谁创建谁、谁依赖谁，再落代码。图本身不需要多美观，但画的过程会逼你想清楚职责边界。这一步省了，后面调试多花的时间往往远比画图多。