创建型模式之工厂方法
- 定义与特点
- 结构与实现
- 模式的结构
- 模式的实现
- 应用场景
- 扩展:简单工厂模式
- 参考文章
定义与特点
工厂方法(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;
}
}