工厂模式适合解决对象创建逻辑分散、易变且需统一管理的问题；它将new操作集中封装，便于替换实现、mock测试、添加日志，并支持运行时动态选择具体类型。
工厂模式适合解决什么问题
当你有一组具有相同接口但不同实现的类，且创建逻辑可能随需求变化（比如要根据配置、用户权限或运行时参数决定实例化哪个子类），就该用工厂模式。它把 new 拆出来集中管理，避免散布在业务代码里，也方便后续替换、Mock 或加日志。
简单工厂 vs 抽象工厂：别一开始就搞复杂
新手常混淆两者。简单工厂不是 GoF 23 种之一，但它够用、易懂，适合大多数场景；抽象工厂用于“产品族”——比如同时创建 WindowsButton 和 WindowsCheckbox，而不仅是一个对象。
- 先写一个静态方法或单独类，接收类型标识（如
string或枚举），返回基类/接口实例 - 不要急着抽象出
IProductFactory和多个实现类，除非你真有多个平行产品线 - 如果只是换数据库驱动（
SqlServerRepository/PostgreRepository），用简单工厂 + 依赖注入容器（如IServiceProvider）更轻量
用 switch 表达式实现安全、可读的工厂方法
C# 8+ 的 switch 表达式比传统 if-else 更清晰，也避免漏掉 default 分支导致运行时异常：
public static IProcessor CreateProcessor(ProcessorType type) => type switch
{
ProcessorType.Image => new ImageProcessor(),
ProcessorType.Text => new TextProcessor(),
ProcessorType.Video => new VideoProcessor(),
_ => throw new ArgumentException($"Unknown processor type: {type}")
};- 返回类型必须是所有分支共同的基类或接口（如
IProcessor），不能是object - 枚举值要覆盖全，
_分支必须处理，否则编译不报错但运行时可能崩 - 构造函数参数多时，别硬塞进 switch；改用字典映射 + 工厂委托，或直接交给 DI 容器
和依赖注入一起用时，工厂别自己管理生命周期
如果你已在 Program.cs 中用 services.AddSingleton<IProcessor, ImageProcessor>()，就别再写一个工厂去 new 实例——这会绕过 DI 容器，导致单例失效、依赖未注入、Dispose 不被调用。
- 真正需要工厂的地方，是那些无法提前注册的动态类型（比如根据文件扩展名选解析器）
- 此时工厂内部应通过
IServiceProvider获取依赖，而不是自己new - 别在工厂里做耗时操作（如读配置文件、连数据库），这些该放在初始化阶段完成
最易被忽略的一点：工厂本身也是对象，它可能持有状态或缓存。如果它被注册为 Singleton，但内部用了非线程安全的集合，就会在并发下出问题。
