简单工厂应使用static成员函数返回智能指针，参数用枚举，基类析构函数需virtual；抽象工厂用于创建一族相关对象，是纯虚类，具体工厂各自实现接口，工厂本身无状态且避免静态初始化依赖。
简单工厂用 static 成员函数最稳妥
简单工厂本质是把对象创建逻辑集中到一个类里，靠参数决定返回哪种子类实例。别写成全局函数或模板——类型擦除和扩展性都差。static 成员函数最直接，调用时不用先构造工厂对象，也避免生命周期干扰。
常见错误是让工厂返回裸指针，导致资源泄漏或悬空。必须返回智能指针：std::unique_ptr（所有权明确）或 std::shared_ptr（需共享时）。否则一不小心就崩在析构上。
- 参数建议用枚举而非字符串——编译期检查、无拼写风险、无运行时哈希开销
- 所有子类必须继承同一基类，且基类析构函数得是
virtual，否则delete智能指针时只调父类析构 - 工厂内部用
switch比if-else更清晰；缺省分支必须抛异常，不能静默返回nullptr
class Product { public: virtual ~Product() = default; };
class ConcreteA : public Product {};
class ConcreteB : public Product {};
class SimpleFactory {
public:
enum class Type { A, B };
static std::unique_ptr<Product> create(Type t) {
switch (t) {
case Type::A: return std::make_unique<ConcreteA>();
case Type::B: return std::make_unique<ConcreteB>();
default: throw std::invalid_argument("Unknown type");
}
}
};
抽象工厂必须成对定义接口与实现
抽象工厂不是“更高级的简单工厂”，它是为「一族相关对象」服务的。比如 GUI 库要同时提供 Button 和 Checkbox，而 Windows 版和 macOS 版实现完全不同——这时才需要抽象工厂。
关键陷阱：有人把抽象工厂写成模板类，试图靠编译期多态替代虚函数。这会破坏运行时切换能力（比如配置决定用哪套 UI），也增加头文件依赖和编译时间。
立即学习“C++免费学习笔记（深入）”；
- 抽象工厂本身是纯虚类，只声明
createButton()、createCheckbox()等接口 - 每个具体工厂（如
WinFactory、MacFactory）各自实现这一组方法，内部 new 各自对应的子类 - 客户端代码只依赖抽象工厂和抽象产品，不 include 任何具体实现头文件
工厂返回值类型选 std::unique_ptr 还是 std::shared_ptr？
取决于所有权是否可能被多个地方持有。90% 的工厂场景用 std::unique_ptr 就够了——创建者立刻移交所有权，后续谁用谁管生命周期。
用 shared_ptr 的典型场景是：工厂返回的对象会被缓存、跨线程传递、或作为观察者长期持有。但要注意循环引用风险：如果产品内部又持有了工厂的 shared_ptr，就 leak 了。
- 不要在工厂里用
new+shared_ptr构造，必须用std::make_shared，否则多一次内存分配 - 如果产品类有自定义删除器（比如用
free()释放 C 风格内存），unique_ptr支持模板参数传入，shared_ptr也支持，但写法稍啰嗦 - 返回值类型一旦定下，就别在不同工厂实现里混用——客户端代码会崩溃在类型不匹配
别在构造函数里调用工厂，小心静态初始化顺序问题
如果某个全局对象的构造函数里调用了工厂，而工厂内部又依赖另一个尚未初始化的全局对象（比如日志器、配置管理器），程序启动就 crash，堆栈还难查。
这种隐式依赖比显式传参危险得多。工厂本身不该有状态，也不该依赖其他单例——它只做一件事：按需 new 对象。
- 把工厂调用推迟到第一次使用时（懒初始化），或由上层业务逻辑明确控制时机
- 如果真需要全局工厂实例，用局部静态变量封装，利用 C++11 的线程安全初始化保证
- 测试时最容易暴露这个问题：单元测试单独跑工厂逻辑没问题，一集成就挂，八成是静态顺序惹的祸
new 很快，但加一层工厂后，接口、头文件、构建依赖全跟着变。没想清楚就加，最后维护成本远高于收益。 
