由于需求的变化

工厂方法模式(Factory Method)

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

Terrylee,2004年1月2日

概述

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

意图

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

结构图

图片 1

生活中的例子

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

图片 2

工厂方法解说

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

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

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

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

 1图片 43图片 44/// <summary>
 2图片 45/// EventLog类
 3图片 46/// </summary>
 4图片 47public class EventLog
 5图片 48图片 49{
 6图片 50    public void Write()
 7图片 51图片 52    {
 8图片 53        Console.WriteLine("EventLog Write Success!");
 9图片 54    }
10图片 55}
11图片 56
12图片 57图片 58/// <summary>
13图片 59/// FileLog类
14图片 60/// </summary>
15图片 61public class FileLog
16图片 62图片 63{
17图片 64    public void Write()
18图片 65图片 66    {
19图片 67        Console.WriteLine("FileLog Write Success!");
20图片 68    }
21图片 69}
22图片 70

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

图片 71

实现代码:

1图片 72图片 73/// <summary>
2图片 74/// Log类
3图片 75/// </summary>
4图片 76public abstract class Log
5图片 77图片 78{
6图片 79    public abstract void Write();
7图片 80}
8图片 81

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

 1图片 82图片 83/// <summary>
 2图片 84/// EventLog类
 3图片 85/// </summary>
 4图片 86public class EventLog:Log
 5图片 87图片 88{
 6图片 89    public override void Write()
 7图片 90图片 91    {
 8图片 92        Console.WriteLine("EventLog Write Success!");
 9图片 93    }
10图片 94}
11图片 95图片 96/// <summary>
12图片 97/// FileLog类
13图片 98/// </summary>
14图片 99public class FileLog:Log
15图片 100图片 101{
16图片 102    public override void Write()
17图片 103图片 104    {
18图片 105        Console.WriteLine("FileLog Write Success!");
19图片 106    }
20图片 107}
21图片 108

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

图片 109EventLog eventlog = new EventLog();
图片 110eventlog.Write();
图片 111

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

 1图片 112图片 113/// <summary>
 2图片 114/// EventFactory类
 3图片 115/// </summary>
 4图片 116public class EventFactory
 5图片 117图片 118{
 6图片 119    public EventLog Create()
 7图片 120图片 121    {
 8图片 122        return new EventLog();
 9图片 123    }
10图片 124}
11图片 125图片 126/// <summary>
12图片 127/// FileFactory类
13图片 128/// </summary>
14图片 129public class FileFactory
15图片 130图片 131{
16图片 132    public FileLog Create()
17图片 133图片 134    {
18图片 135        return new FileLog();
19图片 136    }
20图片 137}
21图片 138

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

图片 139

实现代码如下:

1图片 140图片 141/// <summary>
2图片 142/// LogFactory类
3图片 143/// </summary>
4图片 144public abstract class LogFactory
5图片 145图片 146{
6图片 147    public abstract Log Create();
7图片 148}
8图片 149

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

 1图片 150图片 151/// <summary>
 2图片 152/// EventFactory类
 3图片 153/// </summary>
 4图片 154public class EventFactory:LogFactory
 5图片 155图片 156{
 6图片 157    public override EventLog Create()
 7图片 158图片 159    {
 8图片 160        return new EventLog();
 9图片 161    }
10图片 162}
11图片 163图片 164/// <summary>
12图片 165/// FileFactory类
13图片 166/// </summary>
14图片 167public class FileFactory:LogFactory
15图片 168图片 169{
16图片 170    public override FileLog Create()
17图片 171图片 172    {
18图片 173        return new FileLog();
19图片 174    }
20图片 175}
21图片 176

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

 1图片 177图片 178/// <summary>
 2图片 179/// App类
 3图片 180/// </summary>
 4图片 181public class App
 5图片 182图片 183{
 6图片 184    public static void Main(string[] args)
 7图片 185图片 186    {
 8图片 187        LogFactory factory = new EventFactory();
 9图片 188
10图片 189        Log log = factory.Create();
11图片 190
12图片 191        log.Write();
13图片 192    }
14图片 193}
15图片 194

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

LogFactory factory = new EventFactory();

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

LogFactory factory = new FileFactory();

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

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

1图片 195<appSettings>
2图片 196    <add key="factoryName" value="EventFactory"></add>
3图片 197</appSettings>
4图片 198

此时客户端代码如下:

 1图片 199图片 200/// <summary>
 2图片 201/// App类
 3图片 202/// </summary>
 4图片 203public class App
 5图片 204图片 205{
 6图片 206    public static void Main(string[] args)
 7图片 207图片 208    {
 8图片 209        string strfactoryName = ConfigurationSettings.AppSettings["factoryName"];
 9图片 210        
10图片 211        LogFactory factory;
11图片 212        factory = (LogFactory)Assembly.Load("FactoryMethod").CreateInstance("FactoryMethod." + strfactoryName);
12图片 213
13图片 214        Log log = factory.Create();
14图片 215        log.Write();
15图片 216    }
16图片 217}
17图片 218

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

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对象并返回。如下图所示:

图片 219

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

 1图片 220internal static IHttpHandler GetApplicationInstance(HttpContext context)
 2图片 221图片 222{
 3图片 223      if (HttpApplicationFactory._customApplication != null)
 4图片 224图片 225      {
 5图片 226            return HttpApplicationFactory._customApplication;
 6图片 227      }
 7图片 228      if (HttpDebugHandler.IsDebuggingRequest(context))
 8图片 229图片 230      {
 9图片 231            return new HttpDebugHandler();
10图片 232      }
11图片 233      if (!HttpApplicationFactory._theApplicationFactory._inited)
12图片 234图片 235      {
13图片 236            lock (HttpApplicationFactory._theApplicationFactory)
14图片 237图片 238            {
15图片 239                  if (!HttpApplicationFactory._theApplicationFactory._inited)
16图片 240图片 241                  {
17图片 242                        HttpApplicationFactory._theApplicationFactory.Init(context);
18图片 243                        HttpApplicationFactory._theApplicationFactory._inited = true;
19图片 244                  }
20图片 245            }
21图片 246      }
22图片 247      return HttpApplicationFactory._theApplicationFactory.GetNormalApplicationInstance(context);
23图片 248}
24图片 249

System.Web.IHttpHandlerFactory

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

图片 250<httpHandlers>
图片 251
图片 252<add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory" />
图片 253
图片 254<add verb="*" path="*.ashx" type="System.Web.UI.SimpleHandlerFactory" />
图片 255
图片 256图片 257图片 258
图片 259
图片 260</httpHandlers>
图片 261

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

图片 262

IHttpHandlerFactory工厂:

1图片 263public interface IHttpHandlerFactory
2图片 264图片 265{
3图片 266      // Methods
4图片 267      IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated);
5图片 268      void ReleaseHandler(IHttpHandler handler);
6图片 269}
7图片 270

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

抽象工厂角色:IHttpHandlerFactory

具体工厂角色:PageHandlerFactory

抽象产品角色:IHttpHandler

具体产品角色:ASP.SamplePage_aspx

进一步去理解

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

 1图片 271图片 272public class HttpHandlerFactoryImpl:IHttpHandlerFactory {
 2图片 273   
 3图片 274   IHttpHandler IHttpHandlerFactory.GetHandler(
 4图片 275      HttpContext context, String requestType, 
 5图片 276图片 277      String url, String pathTranslated ) {
 6图片 278
 7图片 279         return new HttpHandlerImpl();
 8图片 280         
 9图片 281   }//IHttpHandlerFactory.GetHandler
10图片 282
11图片 283   void IHttpHandlerFactory.ReleaseHandler(
12图片 284图片 285      IHttpHandler handler) { /*no-op*/ }
13图片 286
14图片 287}//HttpHandlerFactoryImpl
15图片 288
16图片 289图片 290public class HttpHandlerImpl:IHttpHandler {
17图片 291
18图片 292图片 293   void IHttpHandler.ProcessRequest(HttpContext context) {
19图片 294      
20图片 295      context.Response.Write("sample handler invoked图片 296");
21图片 297      
22图片 298   }//ProcessRequest
23图片 299
24图片 300图片 301   bool IHttpHandler.IsReusable { get { return false; } }
25图片 302
26图片 303}//HttpHandlerImpl
27图片 304

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

图片 305<httpHandlers>
图片 306
图片 307   <add verb="*" path="*.sample" 
图片 308
图片 309      type="HttpHandlerFactoryImpl,SampleHandler" />
图片 310
图片 311</httpHandlers>
图片 312

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

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

图片 313

在.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
出处:
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。