设计模式（03）：创建型模式(二) 工厂方法模式（Factory Method）

一、动机（Motivation）

在软件系统创建过程中，经常面临着“某个对象”的创建工作：由于需求的变化，这个对象（的具体实现）经常面临着剧烈的变化，但是它却拥有比较稳定的接口。
如何应对这种变化？如何提供一种“封装机制”来隔离出“这个易变对象”的变化，从而保持系统中“其他依赖对象的对象”不随着需求改变而改变？

二、意图（Intent）

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟到子类。——《设计模式》GoF

三、结构（Structure）

四、模式的组成

          可以看出，在工厂方法模式的结构图有以下角色：
（1）、抽象工厂角色（Creator）: 充当抽象工厂角色，定义工厂类所具有的基本的操作，任何具体工厂都必须继承该抽象类。
（2）、具体工厂角色（ConcreteCreator）：充当具体工厂角色，该类必须继承抽象工厂角色，实现抽象工厂定义的方法，用来创建具体产品。
（3）、抽象产品角色（Product）：充当抽象产品角色，定义了产品类型所有具有的基本操作，具体产品必须继承该抽象类。
（4）、具体产品角色（ConcreteProduct）：充当具体产品角色，实现抽象产品类对定义的抽象方法，由具体工厂类创建，它们之间有一一对应的关系。

五、工厂方法模式的代码实现

【简单工厂模式】的问题是：如果有新的需求就需要修改工厂类里面创建产品对象实例的那个方法的实现代码，在面向对象设计一个原则就是哪里有变化，我就封装哪里。

为了应对改变，我们需要把Car先变成抽象类。

public abstract class Car
{
    public abstract void startup();

    public abstract void run();

    public abstract void stop();
}

internal class BenzCar : Car
{
    public override void startup()
    {
        Console.WriteLine("BenzCar Startup!");
    }

    public override void run()
    {
        Console.WriteLine("BenzCar Running!");
    }

    public override void stop()
    {
        Console.WriteLine("BenzCar Stopped!");
    }
}

internal class HondaCar : Car
{
    public override void startup()
    {
        Console.WriteLine("HondaCar Startup!");
    }

    public override void run()
    {
        Console.WriteLine("HondaCar Running!");
    }

    public override void stop()
    {
        Console.WriteLine("HondaCar Stopped!");
    }
}

public abstract class CarFactory
{
    public abstract Car CreatCar();
}

internal class BenzCarFactory : CarFactory
{
    public override Car CreatCar()
    {
        return new BenzCar();
    }
}

internal class HondaCarFactory : CarFactory
{
    public override Car CreatCar()
    {
        return new HondaCar();
    }
}

我们在客户程序使用的时候，把所有的Car都换成抽象的AbstractCar，这样客户程序就不需要了解具体测试的是哪个Car了。客户程序如下：

internal class CarTestFrameWork
{
    public void DoTest(CarFactory carFactory)
    {
        Car car = carFactory.CreatCar();
        car.startup();
        car.run();
        car.stop();
    }
}

在应用程序调用的时候，传入客户程序的工厂应该是具体的HongqiCarFactory工厂。当想换具体Car的时候，只需要创建一个新的Car继承自AbstractCar，并新建一个具体CarFactory工厂继承自抽象CarFactory。然后在具体的应用中把具体的Car工厂参数修改即可。当然，完全可以让具体应用的代码也不用修改，把变化转嫁到配置文件中去。

internal class Test
{
    public static void Main()
    {
        CarTestFrameWork cf = new CarTestFrameWork();
        cf.DoTest(new BenzCarFactory());
        cf.DoTest(new HondaCarFactory());
    }
}

六、Factory Method模式的几个要点

　　Factory Method模式主要用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系会导致软件的脆弱。

　　Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。

•       Factory Method模式解决“单个对象”的需求变化；
•       AbstractFactory模式解决“系列对象”的需求变化；
•       Builder模式解决“对象部分”的需求变化；
  

  1、工厂方法模式的优点：

             （1）、 在工厂方法中，用户只需要知道所要产品的具体工厂，无须关系具体的创建过程，甚至不需要具体产品类的类名。
             （2）、在系统增加新的产品时，我们只需要添加一个具体产品类和对应的实现工厂，无需对原工厂进行任何修改，很好地符合了“开闭原则”。
  

  2、工厂方法模式的缺点：

             （1）、每次增加一个产品时，都需要增加一个具体类和对象实现工厂，是的系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。
  

  3、工厂方法模式使用的场景：

              （1）、一个类不知道它所需要的对象的类。在工厂方法模式中，我们不需要具体产品的类名，我们只需要知道创建它的具体工厂即可。
              （2）、一个类通过其子类来指定创建那个对象。在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。
              （3）、将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定。

七、.NET中实现了工厂方法的类

.NET 类库中也有很多实现了工厂方法的类，例如Asp.net中，处理程序对象是具体用来处理请求，当我们请求一个*.aspx的文件时，此时会映射到System.Web.UI.PageHandlerFactory类上进行处理，而对*.ashx的请求将映射到System.Web.UI.SimpleHandlerFactory类中（这两个类都是继承于IHttpHandlerFactory接口的），关于这点说明我们可以在“C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Web.Config”文件中找到相关定义，具体定义如下：

<add path="*.axd" verb="*" type="System.Web.HttpNotFoundHandler" validate="True"/>
<add path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory" validate="True"/>
<add path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" validate="True"/>

配置文件截图了一部分，有时间大家可以自己去研究一下。
下面我们就具体看下工厂方法模式在Asp.net中是如何实现的，如果对一个Index.aspx页面发出请求时，将会调用PageHandlerFactory中GetHandler方法来创建一个Index.aspx对象，它们之间的类图关系如下：