工厂方法模式用于解耦对象创建与使用，核心是用虚函数将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）不是替代方案。靠类型转换来“事后补救”创建逻辑，说明工厂设计已经失败
