17370845950

工厂方法模式用于解耦对象创建与使用，核心是用虚函数将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 类型的产品」。

实操要点：

• 定义抽象产品基类 Product（通常含纯虚函数，确保多态行为）
• 定义抽象工厂基类 Creator，声明虚函数 virtual std::unique_ptr create() = 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）不是替代方案。靠类型转换来“事后补救”创建逻辑，说明工厂设计已经失败