创建型模式之工厂方法
定义与特点
工厂方法（FactoryMethod）模式的定义：定义一个创建产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。
我们把被创建的对象称为“产品”，把创建产品的对象称为“工厂”。
如果要创建的产品不多，只要一个工厂类就可以完成，这种模式叫“简单工厂模式”，它不属于 GoF 的 23 种经典设计模式，它的缺点是增加新产品时会违背“开闭原则”（可以通过反射克服该缺点）。
“工厂方法模式”是对简单工厂模式的进一步抽象化，其好处是可以使系统在不修改原来代码的情况下引进新的产品，即满足开闭原则。
工厂方法模式的主要优点有：
- 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程（对创建过程复杂的对象很有作用）；
- 在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类，无须对原工厂进行任何修改，满足开闭原则；
其缺点是：每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度。
结构与实现
工厂方法模式由抽象工厂、具体工厂、抽象产品和具体产品等4个要素构成。本节来分析其基本结构和实现方法。
模式的结构
工厂方法模式的主要角色如下：
- 抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法 CreateProduct() 来创建产品。
- 具体工厂（ConcreteFactory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
- 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能。
- 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。
抽象工厂、抽象产品可以是接口，也可以是抽象类。抽象产品的定义方式取决于产品对象的建模事物，抽象工厂的定义方式一般与抽象产品的定义方式保持一致。
一般情况下，产品对象是对现实世界中的事物进行建模，使用抽象类定义抽象产品更合理。特殊情况下，产品对象对功能组件、功能实现建模或产品对象已有父对象（C#中对象只能有一个父类）时则使用接口定义抽象产品。
其结构图如图所示（使用抽象类）：
模式的实现
根据上图写出的该模式的代码如下：
//访问类
class Program
{
static void Main(string[] args)
{
//工厂方法
Product product1 = new ConcreteFactory1().CreateProduct();
product1.ShowInfo();
Product product2 = new ConcreteFactory2().CreateProduct();
product2.ShowInfo();
Console.ReadKey();
}
}
/// <summary>
/// 抽象产品类
/// </summary>
public abstract class Product
{
public abstract void ShowInfo();
}
/// <summary>
/// 具体产品类1
/// </summary>
public class ConcreteProduct1 : Product
{
public override void ShowInfo()
{
Console.WriteLine("产品类型为Product1");
}
}
/// <summary>
/// 具体产品类2
/// </summary>
public class ConcreteProduct2 : Product
{
public override void ShowInfo()
{
Console.WriteLine("产品类型为Product2");
}
}
/// <summary>
/// 抽象工厂类
/// </summary>
public abstract class AbstractFactory
{
public abstract Product CreateProduct();
}
/// <summary>
/// 具体工厂类1
/// </summary>
public class ConcreteFactory1 : AbstractFactory
{
public override Product CreateProduct()
{
return new ConcreteProduct1();
}
}
/// <summary>
/// 具体工厂类2
/// </summary>
public class ConcreteFactory2 : AbstractFactory
{
public override Product CreateProduct()
{
return new ConcreteProduct2();
}
}
运行结果：
产品类型为Product1
产品类型为Product2
上述代码，添加新类型的产品，需要新增新产品类和新产品工厂类，工厂父类AbstractFactory不需要修改，这样对于已有的工厂不会产生任何潜在的改动影响——便于扩展。
这种方式和直接new ConcreteProduct1()、new ConcreteProduct2()有点像，只不过由每一种Product自己的工厂类复杂new操作，主要原因如下：
- new一个Product出来，可能有很多字段都需要赋值，还要运行一些初始化方法。如果这些赋值、方法在客户client类里面写，那么其他所有客户都要写这些代码，代码重复。如果这些赋值、方法写在产品类的构造函数里面，要干的事情特别多，几十行上百行的代码，全放构造函数里面，有点违背设计原则，在构造函数做太复杂的操作，当出错时发现错误有时会很困难。构造函数应该尽量简单，一眼望穿，最好能保证永不出现构造失败的情况。
- 如果ConcreteProduct1多了一个子类ConcreteProduct1Child，现在生产产品时返回这个类的对象，那么所有客户端的new ConcreteProduct1，都要换成new ConcreteProduct1Child，而如果做成工厂模式，直接在返回ConcreteProduct1的代码哪里更改一下返回ConcreteProduct1Child类的对象就可以了，反正返回的都是Product1（抽象父类）——方便维护。
- 如果所有的产品类，在返回对象之前，又要添加新的逻辑了，那么需要一个个类的找，修改，如果全集中在工厂类中，直接在工厂类中修改即可，避免遗漏，还是——方便维护。
如果返回一个实例要做很多事情，不好直接写在构造函数里面，可以写在具体的工厂类里面，而且如果工厂父类要添加新的逻辑，所有工厂同时享有。所以工厂模式主要是有代码重用，分割职责解耦，便于维护的特点。
应用场景
工厂方法模式通常适用于以下场景：
- 客户只知道创建产品的工厂名，而不知道具体的产品名。如 TCL 电视工厂、海信电视工厂等。
- 创建对象的任务由多个具体子工厂中的某一个完成，而抽象工厂只提供创建产品的接口。
- 客户不关心创建产品的细节，只关心产品的品牌。
扩展：简单工厂模式
当需要生成的产品不多且不会增加，一个具体工厂类就可以完成任务时，可删除抽象工厂类。这时工厂方法模式将退化到简单工厂模式，其结构图如图所示：
在上面的实现代码上增加简单工厂方法的实现，代码如下：
//简单工厂方法
public class SimpleFactory
{
public static Product CreateProduct(string name)
{
Product product = null;
if (name == "ConcreteProduct1")
{
product = new ConcreteProduct1();
}
else if (name == "ConcreteProduct2")
{
product = new ConcreteProduct2();
}
return product;
}
}
//简单工厂方法（加反射优化）
public class ReflectionSimpleFactory
{
public static Product CreateProduct(string name)
{
//获取当前程序集
Assembly ass = Assembly.GetCallingAssembly();
//解析程序集名称
AssemblyName assName = new AssemblyName(ass.FullName);
//获取程序集的类型
Type t = ass.GetType(assName.Name+"."+name);
//创建类的实例对象
Product o = (Product)Activator.CreateInstance(t);
return o;
}
}
