工厂方法模式的核心思想
工厂方法模式不是直接创建具体对象，而是把对象的创建过程延迟到子类中。它定义一个创建对象的抽象方法（工厂方法），由子类决定实例化哪个类。这样客户端代码只依赖抽象产品和抽象工厂，不耦合具体实现。
基本结构：抽象产品、具体产品、抽象工厂、具体工厂
先定义一个产品接口或基类，比如 IProduct；再写几个实现它的类，如 ConcreteProductA 和 ConcreteProductB。接着声明一个抽象工厂类（含 CreateProduct() 抽象方法），然后为每种产品提供对应的具体工厂，比如 ConcreteFactoryA 返回 A 类型实例，ConcreteFactoryB 返回 B 类型实例。
简单可运行的 C# 示例
以下是最小可行代码，不含依赖注入等高级用法，便于理解本质：
// 1. 抽象产品
public interface IProduct
{
void Operation();
}
<p>// 2. 具体产品A
public class ProductA : IProduct
{
public void Operation() => Console.WriteLine("ProductA is working");
}</p><p>// 3. 具体产品B
public class ProductB : IProduct
{
public void Operation() => Console.WriteLine("ProductB is working");
}</p><p>// 4. 抽象工厂
public abstract class Creator
{
public abstract IProduct CreateProduct();
}</p><p>// 5. 具体工厂A
public class ConcreteCreatorA : Creator
{
public override IProduct CreateProduct() => new ProductA();
}</p><p>// 6. 具体工厂B
public class ConcreteCreatorB : Creator
{
public override IProduct CreateProduct() => new ProductB();
}</p><p>// 使用示例
var factoryA = new ConcreteCreatorA();
var productA = factoryA.CreateProduct();
productA.Operation(); // 输出：ProductA is working</p><p>var factoryB = new ConcreteCreatorB();
var productB = factoryB.CreateProduct();
productB.Operation(); // 输出：ProductB is working</p>什么时候该用工厂方法模式
当系统需要让子类决定创建哪个具体类型时；当类希望把对象创建委托给子类，同时保持自身逻辑稳定时；当一个类不知道它所必须创建的对象的类时；或者你想避免在代码里写一堆 if-else / switch 来 new 不同对象——这时就可以把分支逻辑移到各个工厂子类里。
新增一种产品？只需加一个具体产品类 + 一个对应的具体工厂类，不改已有代码 客户端不再关心“谁来造”，只面向抽象工厂和抽象产品编程 比简单工厂更符合开闭原则（对扩展开放，对修改关闭）基本上就这些。工厂方法模式不复杂但容易忽略它的设计意图——不是为了“多写几个类”，而是为了把变化点（创建逻辑）隔离出来，让核心流程更稳定。
