简单工厂适合产品少、变化慢的场景，如仅2–4个具体类且短期不新增；工厂方法适用于需扩展、不能修改旧代码的情况，核心是将创建决策权从工厂内部移至子类实现。
简单工厂适合“产品少、变得慢”的场景
当你只有 2–4 个具体类，且短期内不会新增（比如 FileLogger、ConsoleLogger），用简单工厂最直接。它就是一个带 static 方法的类，参数一传，对象出来，不用继承、不用虚函数、不引入额外抽象层。
常见错误现象：if-else 堆在客户端里反复出现；或者工厂类里不断加 else if 分支，每次加新类型都要改同一处——这其实是没用好简单工厂，而不是它不行。
- 推荐用
enum class或字符串字面量做参数，避免魔法值（如用LoggerType::File而非"file"） - 返回类型优先用
std::unique_ptr<product></product>，避免裸指针和内存泄漏 - 不要把简单工厂做成单例——它本就不该有状态，静态方法足够
工厂方法必须用在“要扩展、不能动旧代码”的地方
一旦你发现需求开始说“下季度要支持 Kafka 日志”“后面还要接入 Prometheus 上报”，而当前代码里所有创建点都得跟着改，就该切到工厂方法了。它的核心不是多写了几个类，而是把“哪个类该被创建”这个决策权，从工厂内部移到了子类实现里。
使用场景：日志后端切换、数据库驱动适配、跨平台 UI 组件初始化等需要隔离变化的模块。
- 抽象工厂基类必须定义纯虚函数
create()，不能提供默认实现 - 每个具体工厂只负责一个具体产品，禁止在
DatabaseLoggerFactory::create()里返回FileLogger - 客户端只依赖
std::shared_ptr<loggerfactory></loggerfactory>和std::shared_ptr<logger></logger>，完全不知道KafkaLogger这个名字
别用工厂方法去套简单工厂的壳
这是最常踩的坑：写了一堆 FileLoggerFactory、ConsoleLoggerFactory，但它们的 create() 里还是用 if (type == ...) 分支返回不同对象——这等于把简单工厂拆成多个文件，反而更难维护。
工厂方法有效的前提是：每个子类的 create() 实现是确定的、无条件的。比如 FileLoggerFactory::create() 永远只 new 一个 FileLogger，不看任何运行时参数。
- 如果创建逻辑依赖配置项（如文件路径、连接串），把参数塞进工厂构造函数，而不是塞进
create()参数列表 - 如果一个工厂类里出现了多个
new不同类的语句，说明它其实该是简单工厂，或该拆成多个工厂 - 编译期已知的产品集合，用模板 + 简单工厂更轻量（比如
make_logger<filelogger>()</filelogger>）
选择的关键不在“哪个更高级”，而在“谁来承担修改成本”
简单工厂的修改成本在工厂类本身；工厂方法的修改成本在新增类（加一个 KafkaLogger 就要加一个 KafkaLoggerFactory）。前者改一处，后者加两处——但后者不碰原有任何一行代码。
真正容易被忽略的是：很多项目根本没走到“需要扩展”的阶段，就提前上了工厂方法，结果多出七八个空壳类，连单元测试都懒得写。先用简单工厂跑通主干流程，等第一个“不得不加新类型”的 PR 出现时，再重构，往往更实际。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
