工厂模式核心是用函数集中创建对象以解耦调用方与具体类，常用枚举分发的自由函数或运行时注册的map+function方案，避免模板工厂的编译期硬编码和插件扩展限制。
工厂模式的核心是“用函数创建对象，而不是直接 new”
直接 new 具体类会把调用方和实现类强耦合，一旦要换类型就得改所有 new 地方。工厂模式把创建逻辑集中到一个地方——通常是一个函数或类的静态方法，调用方只依赖抽象接口，不关心谁被实例化。
最常用、最轻量的做法是用一个返回基类指针的普通函数，配合枚举或字符串做分发：
enum class ShapeType { Circle, Rectangle };
<p>class Shape {
public:
virtual ~Shape() = default;
virtual void draw() = 0;
};</p><p>class Circle : public Shape {
public:
void draw() override { /<em> ... </em>/ }
};</p><p>class Rectangle : public Shape {
public:
void draw() override { /<em> ... </em>/ }
};</p><p>std::unique_ptr<Shape> createShape(ShapeType type) {
switch (type) {
case ShapeType::Circle: return std::make_unique<Circle>();
case ShapeType::Rectangle: return std::make_unique<Rectangle>();
default: return nullptr;
}
}注意返回类型用 std::unique_ptr<shape></shape> 而不是裸指针，避免内存泄漏；createShape 是自由函数，没状态、易测试、不需实例化。
用 std::map + std::function 实现运行时注册工厂
硬编码 switch 在类型多、插件化或配置驱动场景下不灵活。这时可把构造逻辑注册进一个全局映射表，按字符串动态创建：
立即学习“C++免费学习笔记（深入）”；
- 定义注册函数：接收类型名和构造器（
std::function<:unique_ptr>()></:unique_ptr>） - 内部用
static std::map<:string std::function>></:string>存储 - 构造器必须捕获完整上下文（比如带参数的构造需用 lambda 包一层）
- 注册时机很重要：必须在
main()之前完成，否则首次调用可能找不到项
示例注册片段：
void registerShape(const std::string& name,
std::function<std::unique_ptr<Shape>()> factory) {
static std::map<std::string, std::function<std::unique_ptr<Shape>()>> registry;
registry[name] = std::move(factory);
}
<p>// 使用处（通常在 .cpp 文件顶部或模块初始化函数里）
registerShape("circle", []{ return std::make_unique<Circle>(); });
registerShape("rectangle", []{ return std::make_unique<Rectangle>(); });</p><p>std::unique_ptr<Shape> createShape(const std::string& name) {
static const std::map<std::string, std::function<std::unique_ptr<Shape>()>> registry;
auto it = registry.find(name);
return it != registry.end() ? it->second() : nullptr;
}为什么不用模板工厂类？它解决的是不同问题
有人写 template<typename t> std::unique_ptr<t> create()</t></typename> 这类泛型工厂，但它本质是编译期选择，调用方仍得写死类型名（如 create<circle>()</circle>），没解除耦合，反而让调用点暴露了具体类——这违背工厂初衷。
模板工厂适合工具函数场景（比如统一管理资源生命周期），但不适合“根据运行时输入决定创建哪个子类”的业务逻辑。
- 真正需要工厂模式时，创建依据必须来自运行时（配置文件、网络消息、用户输入）
- 如果类型在编译期已知且固定，直接用
std::make_unique更清晰 - 模板工厂无法支持插件式扩展（新类型加进来要重编译整个工厂）
容易踩的坑：析构不安全、静态初始化顺序、类型擦除开销
基类析构函数没声明为 virtual 是最常见崩溃原因——派生类对象通过基类指针 delete 时不会调用派生析构，资源泄漏或未定义行为。
注册表用 static 局部变量看似方便，但多个编译单元中初始化顺序不可控，可能某处 createShape 调用早于任何 registerShape，结果返回空指针且无提示。
若工厂返回 std::any 或 std::variant 做类型擦除，虽灵活但失去多态优势，还得手动 std::any_cast，不如坚持用虚函数接口 + 智能指针干净。
真正难的从来不是写几行工厂代码，而是想清楚：这个对象谁负责销毁？类型列表是否稳定？配置来源是否可信？这些比模式本身更影响系统长期可维护性。
