工厂方法模式用于解耦对象创建与使用，核心是用虚函数将 new 逻辑上提至抽象工厂，避免 if-else 硬编码子类、编译依赖爆炸及无法统一管理生命周期。
工厂方法模式在 C++ 中不是靠“教程步骤”堆出来的，而是为了解决「类继承体系下，调用方不依赖具体子类就能创建多态对象」这个实际问题。核心判断标准只有一条：如果你 new 的地方要写 if-else 判断类型再决定 new 哪个子类，那就该用工厂方法了。
为什么 不能直接 new 子类？
硬 编码 new ConcreteProductA() 或 new ConcreteProductB() 会把业务逻辑和具体实现强耦合。一旦新增子类，所有调用处都要改；单元测试时也无法注入模拟对象；更无法统一控制对象生命周期（比如加对象池、日志、权限检查）。
常见错误现象：
- 函数里一堆
if (type == "A") {return new ProductA(); } else if (type == "B") {……} - 头文件里必须 #include 所有具体子类，导致编译依赖爆炸
- 想替换某个产品实现，却要改十几处 new 调用点
工厂方法的最小可行结构
它本质是把「创建逻辑」上提到一个虚函数里，由子类决定实例化谁。关键不是写多少类，而是让基类接口能表达「我要一个产品」，而不用说「我要一个 A 类型的产品」。
立即学习“C++ 免费学习笔记（深入）”；
实操要点：
- 定义抽象产品基类
Product（通常含纯虚函数，确保多态行为） - 定义抽象工厂基类
Creator，声明虚函数virtual std::unique_ptrcreate() = 0; - 每个具体工厂（如
ConcreteCreatorA）重写create()，返回对应具体产品（如std::make_unique）() - 业务代码只持有
std::unique_ptr，调用create()得到std::unique_ptr，完全不知道具体类型
class Product {public: virtual ~Product() = default; virtual void operation() const = 0;}; class ConcreteProductA : public Product {public: void operation() const override {/ …… / } };
class Creator {public: virtual ~Creator() = default; virtual std::unique_ptr create() = 0;};
class ConcreteCreatorA : public Creator {public: std::unique_ptr create() override { return std::make_unique();} };
std::unique_ptr 还是 raw pointer？
用 std::unique_ptr 是现代 C++ 工厂方法的事实标准。它明确所有权转移，避免内存泄漏，且与多态完美兼容。别用裸指针或 std::shared_ptr 当默认选择 —— 前者要手动 delete，后者引入不必要的引用计数开销，除非你真需要共享所有权。
性能与兼容性影响：
-
std::unique_ptr可 隐式转换 为std::unique_ptr，适合 move 语义传递&& - 若工厂需支持无状态（如单例工厂），可将
create()设为 static，但此时就退化为简单工厂，失去多态创建能力 - 不要在工厂内部用
new Product—— 抽象类不能实例化，编译直接报错：error: invalid new-expression of abstract class type 'Product'
工厂方法 vs 简单工厂 vs 抽象工厂
别被名字绕晕。工厂方法解决的是「一个产品族中，不同工厂创建不同产品」的问题。它和简单工厂（一个静态函数分发创建）的 区别 在于：前者支持运行时切换工厂（比如根据配置加载不同模块），后者只是语法糖；和抽象工厂（创建多个相关产品）的区别在于：前者只管一个产品等级结构，后者管多个（比如 GUI 库中同时创建 Button + Checkbox）。
容易被忽略的点：
- 工厂类本身也应遵循依赖倒置：业务代码依赖抽象工厂
Creator，而不是任何具体工厂 - 如果产品构造需要参数，
create()函数可以加参数，但所有子类工厂必须保持签名一致 —— 否则多态失效 - RTTI（
dynamic_cast）不是替代方案。靠类型转换来“事后补救”创建逻辑，说明工厂设计已经失败
