优先用simplefactory解耦简单创建逻辑；产品增多时改用factorymethod；需成套切换强关联对象（如winbutton+wintextbox）才用abstractfactory。
直接上结论：C#里想快速解耦对象创建逻辑，优先用 SimpleFactory；如果产品种类开始变多、后续要频繁加新类型，就得换成 FactoryMethod；只有当你需要成套切换一组强关联对象（比如 WinButton + WinTextBox 一起换），才考虑 AbstractFactory。
什么时候该用 SimpleFactory？
它不是 GoF 标准模式，但绝大多数初学者和中小型项目的真实起点就是它。核心是“一个类、一个静态方法、靠字符串或枚举分支决定返回谁”。
- 适用场景：产品类型 ≤ 5 种，创建逻辑简单（比如只 new 一下，不涉及依赖注入、配置加载、异步初始化）
- 典型错误：在
CreateProduct()里硬编码日志、数据库连接或 HTTP 客户端——这会让工厂承担不该有的职责 - 参数差异：
string类型最常见，但建议改用enum（如FruitType.Apple），避免拼写错误和大小写问题 - 性能影响：无额外开销，纯编译期分发；但每次新增产品都要改工厂类，违反开闭原则
示例片段：
public static class FruitFactory
{
public static IFruit CreateFruit(FruitType type) => type switch
{
FruitType.Apple => new Apple(),
FruitType.Banana => new Banana(),
_ => throw new ArgumentException($"未知水果类型: {type}")
};
}
FactoryMethod 为什么比 SimpleFactory 更“正统”？
因为它的结构强制你把“创建逻辑”下放到子类，而不是堆在一个方法里。客户端只依赖抽象基类 Creator，完全不知道 ConcreteCreatorA 这种具体名字。
- 容易踩的坑：抽象基类
Creator写成class却忘了加abstract，导致子类可以不重写CreateProduct() - 使用场景：产品类型增长快，或者不同产品的创建过程差异很大（比如一个从配置读，一个要连 Redis 初始化）
- 兼容性注意：.NET 6+ 可配合
Activator.CreateInstance做泛型工厂，但别滥用——类型擦除和反射调用会丢失编译期检查
关键代码结构：
public abstract class Creator
{
public abstract IProduct CreateProduct(); // 必须 abstract
}
public class ConcreteCreatorA : Creator
{
public override IProduct CreateProduct() => new ProductA(); // 子类自己决定
}
AbstractFactory 到底什么时候才该上？
它不是“多个 FactoryMethod 拼一起”，而是解决“主题一致性”的问题。如果你发现代码里反复出现 new WinButton() 和 new WinTextBox()，而且这两者必须配套使用，那才是它的主场。
- 常见误用：只为一个接口（如
IRepository）就搞出IRepositoryFactory+SqlServerRepositoryFactory——这属于杀鸡用牛刀，直接 DI 注册更轻量 - 性能影响：工厂本身不耗资源，但若每个
CreateXxx()方法都触发一次完整对象图构建（比如带 3 层依赖），要注意初始化延迟 - 可维护性陷阱：一旦新增一个产品（如
IDialog），所有具体工厂类都得补实现，接口也要改——这是设计信号：要么拆分主题，要么换方案
判断依据很实在：你是否在某处写了类似这样的代码？
var button = factory.CreateButton(); var textbox = factory.CreateTextBox(); // 必须和 button 同一主题 // 如果 button 是 WinButton，textbox 就不能是 WebTextBox
真正难的从来不是写出三个 Factory 的类，而是判断哪一层抽象能刚好卡在业务变化的切口上——多一层，冗余；少一层，改起来疼。
