工厂方法模式(Factory Method Pattern)

C#设计模式（5）－Factory Method Pattern

http://www.cnblogs.com/zhenyulu/articles/36590.aspx

一、 工厂方法（Factory Method）模式

工厂方法（FactoryMethod）模式是类的创建模式，其用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。

工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。

在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不接触哪一个产品类被实例化这种细节。这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。

在Factory Method模式中，工厂类与产品类往往具有平行的等级结构，它们之间一一对应。

二、 Factory Method模式角色与结构：

 

抽象工厂（Creator）角色：是工厂方法模式的核心，与应用程序无关。任何在模式中创建的对象的工厂类必须实现这个接口。

具体工厂（Concrete Creator）角色：这是实现抽象工厂接口的具体工厂类，包含与应用程序密切相关的逻辑，并且受到应用程序调用以创建产品对象。在上图中有两个这样的角色：BulbCreator与TubeCreator。

抽象产品（Product）角色：工厂方法模式所创建的对象的超类型，也就是产品对象的共同父类或共同拥有的接口。在上图中，这个角色是Light。

具体产品（Concrete Product）角色：这个角色实现了抽象产品角色所定义的接口。某具体产品有专门的具体工厂创建，它们之间往往一一对应。

三、 程序举例：

using  System;

public   abstract     class  Light
{
   public abstract void TurnOn();
   public abstract void TurnOff();
}

public   class  BulbLight : Light
{
   public override void TurnOn()
   { Console.WriteLine("Bulb Light is Turned on"); }

   public override void TurnOff()
   { Console.WriteLine("Bulb Light is Turned off"); }
}

public   class  TubeLight : Light
{
   public override void TurnOn()
   { Console.WriteLine("Tube Light is Turned on"); }

   public override void TurnOff()
   { Console.WriteLine("Tube Light is Turned off"); }
}

public   abstract     class  Creator
{
   public abstract Light factory();
}

public   class  BulbCreator : Creator
{
   public override Light factory()
   { return new BulbLight(); }
}

public   class  TubeCreator : Creator
{
   public override Light factory()
   { return new TubeLight(); }
}

public   class  Client
{
   public static void Main()
   {
      Creator c1 = new BulbCreator();
      Creator c2 = new TubeCreator();

      Light l1 = c1.factory();
      Light l2 = c2.factory();

      l1.TurnOn();
      l1.TurnOff();

      Console.WriteLine("-----------------");

      l2.TurnOn();
      l2.TurnOff();
   }
}

工厂方法的活动序列图

 

活动过程包括：

客户端创建BulbCreator对象，客户端持有此对象的类型是Creator，而实际类型是BulbCreator。然后客户端调用BulbCreator的factory方法，之后BulbCreator调用BulbLight的构造函数创造出产品BulbLight对象。

四、 工厂方法模式与简单工厂模式

工厂方法模式与简单工厂模式再结构上的不同不是很明显。工厂方法类的核心是一个抽象工厂类，而简单工厂模式把核心放在一个具体类上。

工厂方法模式之所以有一个别名叫多态性工厂模式是因为具体工厂类都有共同的接口，或者有共同的抽象父类。

当系统扩展需要添加新的产品对象时，仅仅需要添加一个具体对象以及一个具体工厂对象，原有工厂对象不需要进行任何修改，也不需要修改客户端，很好的符合了"开放－封闭"原则。而简单工厂模式在添加新产品对象后不得不修改工厂方法，扩展性不好。

工厂方法模式退化后可以演变成简单工厂模式。

五、 Factory Method模式演化

使用接口或抽象类
抽象工厂角色和抽象场频角色都可以选择由接口或抽象类实现。

使用多个工厂方法
抽象工厂角色可以规定出多于一个的工厂方法，从而使具体工厂角色实现这些不同的工厂方法，这些方法可以提供不同的商业逻辑，以满足提供不同的产品对象的任务。

产品的循环使用
工厂方法总是调用产品类的构造函数以创建一个新的产品实例，然后将这个实例提供给客户端。而在实际情形中，工厂方法所做的事情可以相当复杂。

一个常见的复杂逻辑就是循环使用产品对象。工厂对象将已经创建过的产品登记到一个聚集中，然后根据客户所请求的产品状态，向聚集查询。如果有满足要求的产品对象，就直接将产品返回客户端；如果聚集中没有这样的产品对象，那么就创建一个新的满足要求的产品对象，然后将这个对象登记到聚集中，再返还给客户端。"享元模式（Flyweight Pattern）"就是这样一个模式。

 

多态性的丧失和模式的退化
一个工厂方法模式的实现依赖于工厂角色和产品角色的多态性。在有些情况下，这个模式可以出现退化。

工厂方法返回的类型应当是抽象类型，而不是具体类型。调用工厂方法的客户端应当依赖抽象产品编程，而不是具体产品。如果工厂仅仅返回一个具体产品对象，便违背了工厂方法的用意，发生退化，这时就不再是工厂模式了。

工厂的等级结构：工厂对象应当有一个抽象的超类型。如果等级结构中只有一个具体工厂类的话，抽象工厂就可以省略，发生了退化。

六、 Factory Method模式与其它模式的关系

与工厂方法模式有关的模式还包括：
模板方法模式、MVC模式、享元模式、备忘录模式

七、 另外一个例子

//  Factory Method pattern -- Real World example  

using  System;
using  System.Collections;

//  "Product"
abstract   class  Page
{
}

//  "ConcreteProduct"
class  SkillsPage : Page
{
}

//  "ConcreteProduct"
class  EducationPage : Page
{
}

//  "ConcreteProduct"
class  ExperiencePage : Page
{
}

//  "ConcreteProduct"
class  IntroductionPage : Page
{
}

//  "ConcreteProduct"
class  ResultsPage : Page
{
}

//  "ConcreteProduct"
class  ConclusionPage : Page
{
}

//  "ConcreteProduct"
class  SummaryPage : Page
{
}

//  "ConcreteProduct"
class  BibliographyPage : Page
{
}

//  "Creator"
abstract   class  Document
{
  // Fields
   protected ArrayList pages = new ArrayList();

  // Constructor
   public Document()
  {
    this.CreatePages();
  }

  // Properties
   public ArrayList Pages
  {
    get{ return pages; }
  }

  // Factory Method
   abstract public void CreatePages();
}

//  "ConcreteCreator"
class  Resume : Document
{
  // Factory Method implementation
   override public void CreatePages()
  {
    pages.Add( new SkillsPage() );
    pages.Add( new EducationPage() );
    pages.Add( new ExperiencePage() );
  }
}

//  "ConcreteCreator"
class  Report : Document
{
  // Factory Method implementation
   override public void CreatePages()
  {
    pages.Add( new IntroductionPage() );
    pages.Add( new ResultsPage() );
    pages.Add( new ConclusionPage() );
    pages.Add( new SummaryPage() );
    pages.Add( new BibliographyPage() );
  }
}

/// <summary>
///  FactoryMethodApp test
/// </summary>
class  FactoryMethodApp
{
  public static void Main( string[] args )
  {
    Document[] docs = new Document[ 2 ];

    // Note: constructors call Factory Method
    docs[0] = new Resume();
    docs[1] = new Report();

    // Display document pages
     foreach( Document document in docs )
    {
      Console.WriteLine( "" + document + " ------- " );
      foreach( Page page in document.Pages )
        Console.WriteLine( " " + page );
    }
  }
}

---

参考文献：
阎宏，《Java与模式》，电子工业出版社
[美]James W. Cooper，《C#设计模式》，电子工业出版社
[美]Alan Shalloway  James R. Trott，《Design Patterns Explained》，中国电力出版社
[美]Robert C. Martin，《敏捷软件开发－原则、模式与实践》，清华大学出版社
[美]Don Box, Chris Sells，《.NET本质论 第1卷：公共语言运行库》，中国电力出版社

.NET设计模式(2): 工厂方法模式

http://www.cnblogs.com/anlyren/archive/2008/01/26/factory_method.html

工厂方法模式（Factory Method Pattern）

介绍：
在简单工厂模式中，我们提到，工厂方法模式是简单工厂模式的一个延伸，它属于Gof23中设计模式的创建型设计模式。它解决的仍然是软件设计中与创建对象有关的问题。它可以更好的处理客户的需求变化。

引入
我们继续来说"new"的问题，我们在简单工厂模式中，将实例化对象的工作推迟到了专门负责创建对象的工厂类中，这样，在我们事先预知的情况下，可以根据我们的需要动态创建产品类。但是，我们的预知是有限的，客户的变化可能是无限的。所以，就出现了问题，一旦客户的变化超越了我们的预知，我们就必须修改我们的源代码了。这是设计模式所不允许的，怎么办呢？工厂方法模式正是解决此类问题的。
问题：具体工厂类的创建工作不能满足我们的要求了，创建的工作变化了
解决思路：哪里变化，封装哪里。把具体工厂封装起来。

定义
工厂方法模式又称为工厂模式，也叫虚拟构造器（Virtual Constructor）模式或者多态工厂模式（Polymorphic Factory）,在工厂方法模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实例化（创建）哪一个类。

意图
定义一个用户创建对象的接口，让子类决定实例化哪一个类，工厂方法模式使一个类的实例化延迟到其子类。

参与者

• 抽象产品角色（Product）
  定义产品的接口
• 具体产品角色（ConcreteProduct）
  实现接口Product的具体产品类
• 抽象工厂角色（Creator）
  声明工厂方法（FactoryMethod），返回一个产品
• 真实的工厂（ConcreteCreator）
  实现FactoryMethod工厂方法，由客户调用，返回一个产品的实例

工厂方法模式UML图


现实生活中的例子
为了方便大家理解，我仍然举穿衣服方面的一个例子。这个例子与简单工厂模式中的那个例子有些不同。
据说清朝有个皇帝穿衣非常的奢侈，每种衣服（具体产品类）由一宫女（具体工厂类）专门负责，这样一来，每增加一种衣服（具体产品类），就要多出一个宫女（具体工厂类），但是他们各负其责，互不影响。皇帝之所以这样做，是因为针对穿衣服这件事来说，可扩展性是非常强的（）。

分析
实现的功能：可以根据皇帝的要求，动态的创建（由宫女去拿）已存在的具体产品（衣服），如果皇帝的要求太苛刻，这种衣服还没有，只需要增加一个宫女，一个衣服就能够满足他的要求了。每个宫女只负责一种衣服（高内聚），要增加一种衣服，对于以前的所有宫女与衣服来说，都不会受到影响（设计模式中所期望的）。说到这里，是不是明白了工厂方法模式所能解决的问题及其应用了？呵呵。。你一定在想，比简单工厂模式灵活性高吧。。

抽象工厂角色代码

 1 namespace FactoryMethod
 2{
 3    /// <summary>
 4    /// 抽象工厂类,定义产品的接口
 5    /// </summary>
 6    public interface IFactory
 7    {
 8        ICoat CreateCoat();
 9    }
10}

抽象产品角色代码

 1 namespace FactoryMethod
 2{
 3    /// <summary>
 4    /// 抽象产品类
 5    /// </summary>
 6    public interface ICoat
 7    {
 8        void ShowCoat();
 9    }
10}

具体工厂角色代码

 1 namespace FactoryMethod
 2{
 3    /// <summary>
 4    /// 具体工厂类:用于创建商务上衣类
 5    /// </summary>
 6    public class BusinessFactory:IFactory
 7    {        
 8        public ICoat CreateCoat()
 9        {
10            return new BusinessCoat();
11        }
12    }
13
14    /// <summary>
15    /// 具体工厂类,用于创建时尚上衣
16    /// </summary>
17    public class FashionFactory : IFactory
18    {
19        public ICoat CreateCoat()
20        {
21            return new FashionCoat();
22        }
23    }
24}

具体产品角色代码

 1 namespace FactoryMethod
 2{
 3    /// <summary>
 4    /// 具体产品类,商务上衣类
 5    /// </summary>
 6    public class BusinessCoat:ICoat
 7    {
 8        public void ShowCoat()
 9        {
10            Console.WriteLine("这件是商务上衣");
11        }
12    }
13
14    /// <summary>
15    /// 具体产品类,时尚上衣类
16    /// </summary>
17    public class FashionCoat : ICoat
18    {
19        public void ShowCoat()
20        {
21            Console.WriteLine("这件是时尚上衣");
22        }
23    }
24}
25

客户端代码

 1 namespace FactoryMethod
 2{
 3    /// <summary>
 4    /// 客户端代码
 5    /// </summary>
 6    class Client
 7    {
 8        static void Main(string[] args)
 9        {
10            //为了方便以后修改,将工厂类的类名写在应用程序配置文件中
11            string factoryName = ConfigurationManager.AppSettings["FactoryName"];
12          
13            IFactory factory = (IFactory)Assembly.Load("ConcreteFactory").CreateInstance("FactoryMethod." + factoryName);
14            
15            ICoat coat = factory.CreateCoat();
16            //显示你要的上衣
17            coat.ShowCoat();
18        }
19    }
20}

客户端代码需要注意的两个地方：
1，把具体工厂类类名称写在了应用程序配置文件中，方便修改
2，用到了反射，利用.NET提供的反射可以根据类名来创建它的实例，非常方便


由反射想到的：
下面这一段内容不是计划要写的。
如果在具体工厂中，每次new的对象都是一个，而且这些类是继承自抽象产品接口的，那么我们用简单工厂模式也可以实现动态的增加具体产品类。这样来做，在简单工厂模式中最核心的部分----工厂类不要根据传来的条件去动态创建产品类，利用反射机制去创建。把要实例化的类名放在应用程序配置文件中，呵呵。。这样利用.NET特有的反射就可以用简单工厂模式解决更多的问题了，工厂方法模式的一部分问题也是可以通过“这样的简单工厂模式”解决的，在需要增加具体产品类时，不用增加具体工厂，是不是简单一些呀。下去试一下。。。

优点：

• 基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象。而且如何创建一个具体产品的细节完全封装在具体工厂内部，符合高内聚，低耦合。
• 在系统中加入新产品时，无需修改抽象工厂和抽象产品提供的接口，无需修改客户端，也无需修改其他的具体工厂和具体产品，很好的利用了封装和委托。

缺点：

• 在添加新产品时，需要编写新的具体产品类（其实这不算一个缺点，因为这是不可避免的），要增加与之对应的具体工厂类。

应用情景：

• 类不知道自己要创建哪一个对象时
• 类用它的子类来指定创建哪个对象
• 当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候  

工厂方法模式在ASP.NET HTTP通道中的应用，TerryLee在他的那篇文件中写的非常好，推荐去看一下。

参考资料

• 《深入浅出设计模式(C#/Java版) 》 清华大学出版社 
• MSDN Webcast  C#面向对象设计模式纵横谈 李建忠老师

源程序下载：
            http://files.cnblogs.com/anlyren/FactoryMethod.rar

工厂方法模式（Factory Method）

——.NET设计模式系列之五

Terrylee，2004年1月2日

http://terrylee.cnblogs.com/archive/2006/01/04/310716.html

概述

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

意图

定义一个用户创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。

结构图

生活中的例子

工厂方法定义一个用于创建对象的接口，但是让子类决定实例化哪个类。压注成型演示了这种模式。塑料玩具制造商加工塑料粉，将塑料注入到希望形状的模具中。玩具的类别（车，人物等等）是由模具决定的。

工厂方法解说

在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不接触哪一个产品类被实例化这种细节。这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。在Factory Method模式中，工厂类与产品类往往具有平行的等级结构，它们之间一一对应。

现在我们考虑一个日志记录的例子（这里我们只是为了说明Factory Method模式，实际项目中的日志记录不会这么去做，也要比这复杂一些）。假定我们要设计日志记录的类，支持记录的方法有FileLog和EventLog两种方式。在这里我们先不谈设计模式，那么这个日志记录的类就很好实现了：

 1 /// <summary>
 2/// 日志记录类
 3/// </summary>
 4 public   class  Log
 5      {
 6
 7        public void WriteEvent()
 8        {
 9            Console.WriteLine("EventLog Success!");
10        }
11    
12        public void WriteFile()
13        {
14            Console.WriteLine("FileLog Success!");
15        }
16
17        public void Write(string LogType)
18        {
19            switch(LogType.ToLower())
20            {
21                case "event":
22                    WriteEvent();
23                    break;
24
25                case "file":
26                    WriteFile();
27                    break;
28
29                default:
30                    break;
31            }
32        }
33    }
34

这样的程序结构显然不能符合我们的要求，如果我们增加一种新的日志记录的方式DatabaseLog，那就要修改Log类，随着记录方式的变化，switch语句在不断的变化，这样就引起了整个应用程序的不稳定，进一步分析上面的代码，发现对于EventLog和FileLog是两种完全不同的记录方式，它们之间不应该存在必然的联系，而应该把它们分别作为单独的对象来对待。

 1 /// <summary>
 2/// EventLog类
 3/// </summary>
 4 public   class  EventLog
 5 {
 6    public void Write()
 7    {
 8        Console.WriteLine("EventLog Write Success!");
 9    }
10}
11
12 /// <summary>
13/// FileLog类
14/// </summary>
15 public   class  FileLog
16 {
17    public void Write()
18    {
19        Console.WriteLine("FileLog Write Success!");
20    }
21}
22

进一步抽象，为它们抽象出一个共同的父类，结构图如下：

实现代码：

1 /// <summary>
2/// Log类
3/// </summary>
4 public   abstract   class  Log
5 {
6    public abstract void Write();
7}
8

此时EventLog和FileLog类的代码应该如下：

 1 /// <summary>
 2/// EventLog类
 3/// </summary>
 4 public   class  EventLog:Log
 5 {
 6    public override void Write()
 7    {
 8        Console.WriteLine("EventLog Write Success!");
 9    }
10}
11 /// <summary>
12/// FileLog类
13/// </summary>
14 public   class  FileLog:Log
15 {
16    public override void Write()
17    {
18        Console.WriteLine("FileLog Write Success!");
19    }
20}
21

此时我们再看增加新的记录日志方式DatabaseLog的时候，需要做哪些事情？只需要增加一个继承父类Log的子类来实现，而无需再去修改EventLog和FileLog类，这样的设计满足了类之间的层次关系，又很好的符合了面向对象设计中的单一职责原则，每一个类都只负责一件具体的事情。到这里似乎我们的设计很完美了，事实上我们还没有看客户程序如何去调用。 在应用程序中，我们要使用某一种日志记录方式，也许会用到如下这样的语句：

EventLog eventlog  =   new  EventLog();
eventlog.Write();

当日志记录的方式从EventLog变化为FileLog，我们就得修改所有程序代码中出现上面语句的部分，这样的工作量是可想而知的。此时就需要解耦具体的日志记录方式和应用程序。这就要引入Factory Method模式了，每一个日志记录的对象就是工厂所生成的产品，既然有两种记录方式，那就需要两个不同的工厂去生产了，代码如下：

 1 /// <summary>
 2/// EventFactory类
 3/// </summary>
 4 public   class  EventFactory
 5 {
 6    public EventLog Create()
 7    {
 8        return new EventLog();
 9    }
10}
11 /// <summary>
12/// FileFactory类
13/// </summary>
14 public   class  FileFactory
15 {
16    public FileLog Create()
17    {
18        return new FileLog();
19    }
20}
21

这两个工厂和具体的产品之间是平行的结构，并一一对应，并在它们的基础上抽象出一个公用的接口，结构图如下：

实现代码如下：

1 /// <summary>
2/// LogFactory类
3/// </summary>
4 public   abstract   class  LogFactory
5 {
6    public abstract Log Create();
7}
8

此时两个具体工厂的代码应该如下：

 1 /// <summary>
 2/// EventFactory类
 3/// </summary>
 4 public   class  EventFactory:LogFactory
 5 {
 6    public override EventLog Create()
 7    {
 8        return new EventLog();
 9    }
10}
11 /// <summary>
12/// FileFactory类
13/// </summary>
14 public   class  FileFactory:LogFactory
15 {
16    public override FileLog Create()
17    {
18        return new FileLog();
19    }
20}
21

这样通过工厂方法模式我们把上面那对象创建工作封装在了工厂中，此时我们似乎完成了整个Factory Method的过程。这样达到了我们应用程序和具体日志记录对象之间解耦的目的了吗？看一下此时客户端程序代码：

 1 /// <summary>
 2/// App类
 3/// </summary>
 4 public   class  App
 5 {
 6    public static void Main(string[] args)
 7    {
 8        LogFactory factory = new EventFactory();
 9
10        Log log = factory.Create();
11
12        log.Write();
13    }
14}
15

在客户程序中，我们有效地避免了具体产品对象和应用程序之间的耦合，可是我们也看到，增加了具体工厂对象和应用程序之间的耦合。那这样究竟带来什么好处呢？我们知道，在应用程序中，Log对象的创建是频繁的，在这里我们可以把

LogFactory factory = new EventFactory();

这句话放在一个类模块中，任何需要用到Log对象的地方仍然不变。要是换一种日志记录方式，只要修改一处为：

LogFactory factory = new FileFactory();

其余的任何地方我们都不需要去修改。有人会说那还是修改代码，其实在开发中我们很难避免修改，但是我们可以尽量做到只修改一处。

其实利用.NET的特性，我们可以避免这种不必要的修改。下面我们利用.NET中的反射机制来进一步修改我们的程序，这时就要用到配置文件了，如果我们想使用哪一种日志记录方式，则在相应的配置文件中设置如下：

1 < appSettings >
2      < add  key ="factoryName"  value ="EventFactory" ></ add >
3 </ appSettings >
4

此时客户端代码如下：

 1 /// <summary>
 2/// App类
 3/// </summary>
 4 public   class  App
 5 {
 6    public static void Main(string[] args)
 7    {
 8        string strfactoryName = ConfigurationSettings.AppSettings["factoryName"];
 9        
10        LogFactory factory;
11        factory = (LogFactory)Assembly.Load("FactoryMethod").CreateInstance("FactoryMethod." + strfactoryName);
12
13        Log log = factory.Create();
14        log.Write();
15    }
16}
17

现在我们看到，在引进新产品（日志记录方式）的情况下，我们并不需要去修改工厂类，而只是增加新的产品类和新的工厂类（注意：这是任何时候都不能避免的），这样很好的符合了开放封闭原则。

ASP.NET HTTP通道中的应用

Factory Method模式在ASP.NET HTTP通道中我们可以找到很多的例子。ASP.NET HTTP通道是System.Web命名空间下的一个类，WEB Server使用该类处理接收到的HTTP请求，并给客户端发送响应。HTTP通道主要的工作有Session管理，应用程序池管理，缓存管理，安全等。

System.Web.HttpApplicationFactory

HttpRuntime是HTTP通道的入口点，它根据每一个具体的请求创建一个HttpContext实例， HttpRuntime并没有确定它将要处理请求的HttpApplication对象的类型，它调用了一个静态的工厂方法HttpApplicationFactory.GetApplicationInstance，通过它来创建HttpContext实例。GetApplicationInstance使用HttpContext实例来确定针对这个请求该响应哪个虚拟路径，如果这个虚拟路径以前请求过，HttpApplication（或者一个继承于ASP.Global_asax的类的实例）将直接从应用程序池中返回，否则针对该虚拟路径将创建一个新的HttpApplication对象并返回。如下图所示：

HttpApplicationFactory.GetApplicationInstance带有一个类型为HttpContext的参数，创建的所有对象（产品）都是HttpApplication的类型，通过反编译，来看一下GetApplicationInstance的实现：

 1 internal   static  IHttpHandler GetApplicationInstance(HttpContext context)
 2 {
 3      if (HttpApplicationFactory._customApplication != null)
 4      {
 5            return HttpApplicationFactory._customApplication;
 6      }
 7      if (HttpDebugHandler.IsDebuggingRequest(context))
 8      {
 9            return new HttpDebugHandler();
10      }
11      if (!HttpApplicationFactory._theApplicationFactory._inited)
12      {
13            lock (HttpApplicationFactory._theApplicationFactory)
14            {
15                  if (!HttpApplicationFactory._theApplicationFactory._inited)
16                  {
17                        HttpApplicationFactory._theApplicationFactory.Init(context);
18                        HttpApplicationFactory._theApplicationFactory._inited = true;
19                  }
20            }
21      }
22      return HttpApplicationFactory._theApplicationFactory.GetNormalApplicationInstance(context);
23}
24

System.Web.IHttpHandlerFactory

我们来做进一步的探索，HttpApplication实例需要一个Handler对象来处理资源请求， HttpApplication的主要任务就是找到真正处理请求的类。HttpApplication首先确定了一个创建Handler对象的工厂，来看一下在Machine.config文件中的配置区<httphandlers>，在配置文件注册了应用程序的具体处理类。例如在Machine.config中对*.aspx的处理将映射到System.Web.UI.PageHandlerFactory 类，而对*.ashx的处理将映射到System.Web.UI.SimpleHandlerFactory 类，这两个类都是继承于IhttpHandlerFactory接口的具体类：

< httpHandlers >

< add  verb ="*"  path ="*.aspx"  type ="System.Web.UI.PageHandlerFactory"   />

< add  verb ="*"  path ="*.ashx"  type ="System.Web.UI.SimpleHandlerFactory"   />



</ httpHandlers >

这个配置区建立了资源请求的类型和处理请求的类之间的一个映射集。如果一个.aspx页面发出了请求，将会调用System.Web.UI.PageHandlerFactory类，HttpApplication调用接口IHttpHandlerFactory中的工厂方法GetHandler来创建一个Handler对象。当一个名为sample.aspx的页面发出请求时，通过PageHandlerFactory将返回一个ASP.SamplePage_aspx对象（具体产品），如下图：

IHttpHandlerFactory工厂：

1 public   interface  IHttpHandlerFactory
2 {
3      // Methods
4      IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated);
5      void ReleaseHandler(IHttpHandler handler);
6}
7

IHttpHandlerFactory.GetHandler是一个工厂方法模式的典型例子，在这个应用中，各个角色的设置如下：

抽象工厂角色：IHttpHandlerFactory

具体工厂角色：PageHandlerFactory

抽象产品角色：IHttpHandler

具体产品角色：ASP.SamplePage_aspx

进一步去理解

理解上面所说的之后，我们就可以去自定义工厂类来对特定的资源类型进行处理。第一步我们需要创建两个类去分别实现IHttpHandlerFactory 和IHttpHandler这两个接口。

 1 public   class  HttpHandlerFactoryImpl:IHttpHandlerFactory  {
 2   
 3   IHttpHandler IHttpHandlerFactory.GetHandler(
 4      HttpContext context, String requestType, 
 5      String url, String pathTranslated ) {
 6
 7         return new HttpHandlerImpl();
 8         
 9   }//IHttpHandlerFactory.GetHandler
10
11   void IHttpHandlerFactory.ReleaseHandler(
12      IHttpHandler handler) { /*no-op*/ }
13
14} // HttpHandlerFactoryImpl
15
16 public   class  HttpHandlerImpl:IHttpHandler  {
17
18   void IHttpHandler.ProcessRequest(HttpContext context) {
19      
20      context.Response.Write("sample handler invoked");
21      
22   }//ProcessRequest
23
24   bool IHttpHandler.IsReusable { get { return false; } }
25
26} // HttpHandlerImpl
27

第二步需要在配置文件中建立资源请求类型和处理程序之间的映射。我们希望当请求的类型为*.sample时进入我们自定义的处理程序，如下：

< httpHandlers >

    < add  verb ="*"  path ="*.sample"  

      type ="HttpHandlerFactoryImpl,SampleHandler"   />

</ httpHandlers >

最后一步我们需要把文件扩展*.sample映射到ASP.NET ISAPI扩展DLL（aspnet_isapi.dll）上。由于我们已经建立了用于处理新扩展文件的处理程序了，我们还需要把这个扩展名告诉IIS并把它映射到ASP.NET。如果你不执行这个步骤而试图访问*.sample文件，IIS将简单地返回该文件而不是把它传递给ASP.NET运行时。其结果是该HTTP处理程序不会被调用。

运行Internet服务管理器，右键点击默认Web站点，选择属性，移动到主目录选项页，并点击配置按钮。应用程序配置对话框弹出来了。点击添加按钮并在可执行字段输入aspnet_isapi.dll文件路径，在扩展字段输入.sample。其它字段不用处理；该对话框如下所示：

在.NET Framework中，关于工厂模式的使用有很多的例子，例如IEnumerable和IEnumerator就是一个Creator和一个Product；System.Security.Cryptography中关于加密算法的选择，SymmetricAlgorithm, AsymmetricAlgorithm, 和HashAlgorithm分别是三个工厂，他们各有一个静态的工厂方法Create；System.Net.WebRequest是 .NET Framework 的用于访问 Internet 数据的请求/响应模型的抽象基类。使用该请求/响应模型的应用程序可以用协议不可知的方式从 Internet 请求数据。在这种方式下，应用程序处理 WebRequest 类的实例，而协议特定的子类则执行请求的具体细节。请求从应用程序发送到某个特定的 URI，如服务器上的 Web 页。URI 从一个为应用程序注册的 WebRequest 子代列表中确定要创建的适当子类。注册 WebRequest 子代通常是为了处理某个特定的协议（如 HTTP 或 FTP），但是也可以注册它以处理对特定服务器或服务器上的路径的请求。有时间我会就.NET Framework中工厂模式的使用作一个专题总结。

实现要点

1．  Factory Method模式的两种情况：一是Creator类是一个抽象类且它不提供它所声明的工厂方法的实现；二是Creator是一个具体的类且它提供一个工厂方法的缺省实现。

2．  工厂方法是可以带参数的。

3．  工厂的作用并不仅仅只是创建一个对象，它还可以做对象的初始化，参数的设置等。

效果

1．  用工厂方法在一个类的内部创建对象通常比直接创建对象更灵活。

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

适用性

在以下情况下，适用于工厂方法模式：

1.       当一个类不知道它所必须创建的对象的类的时候。

2.       当一个类希望由它的子类来指定它所创建的对象的时候。

3.       当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。

总结

Factory Method模式是设计模式中应用最为广泛的模式，通过本文，相信读者已经对它有了一定的认识。然而我们要明确的是：在面向对象的编程中，对象的创建工作非常简单，对象的创建时机却很重要。Factory Method要解决的就是对象的创建时机问题，它提供了一种扩展的策略，很好地符合了开放封闭原则。__________________________________________________________________________________

参考文献：

《设计模式》（中文版）

MSDN：《Exploring the Factory Design Pattern》

《DesignPatternsExplained》

作者： TerryLee
出处： http://terrylee.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

分类: [05]  架构与设计