工厂模式适合解决什么问题
当你有一组具有相同接口但不同实现的类，且创建逻辑可能随需求变化（比如要根据配置、用户权限或运行时参数决定实例化哪个子类），就该用工厂模式。它把
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>()</iprocessor>，就别再写一个工厂去
new实例——这会绕过 DI 容器，导致单例失效、依赖未注入、Dispose 不被调用。 真正需要工厂的地方，是那些无法提前注册的动态类型（比如根据文件扩展名选解析器） 此时工厂内部应通过
IServiceProvider获取依赖，而不是自己
new别在工厂里做耗时操作（如读配置文件、连数据库），这些该放在初始化阶段完成
最易被忽略的一点：工厂本身也是对象，它可能持有状态或缓存。如果它被注册为
Singleton，但内部用了非线程安全的集合，就会在并发下出问题。
