这个对象的具体实现经常面临着剧烈的变化

 

工厂方法模式(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    图片 10{
 6图片 11
 7图片 12        public void WriteEvent()
 8图片 13图片 14        图片 15{
 9图片 16            Console.WriteLine("EventLog Success!");
10图片 17        }
11图片 18    
12图片 19        public void WriteFile()
13图片 20图片 21        图片 22{
14图片 23            Console.WriteLine("FileLog Success!");
15图片 24        }
16图片 25
17图片 26        public void Write(string LogType)
18图片 27图片 28        图片 29{
19图片 30            switch(LogType.ToLower())
20图片 31图片 32            图片 33{
21图片 34                case "event":
22图片 35                    WriteEvent();
23图片 36                    break;
24图片 37
25图片 38                case "file":
26图片 39                    WriteFile();
27图片 40                    break;
28图片 41
29图片 42                default:
30图片 43                    break;
31图片 44            }
32图片 45        }
33图片 46    }
34图片 47

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

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

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

图片 80

实现代码:

1图片 81图片 82/**//// <summary>
2图片 83/// Log类
3图片 84/// </summary>
4图片 85public abstract class Log
5图片 86图片 87图片 88{
6图片 89    public abstract void Write();
7图片 90}
8图片 91

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

 1图片 92图片 93/**//// <summary>
 2图片 94/// EventLog类
 3图片 95/// </summary>
 4图片 96public class EventLog:Log
 5图片 97图片 98图片 99{
 6图片 100    public override void Write()
 7图片 101图片 102    图片 103{
 8图片 104        Console.WriteLine("EventLog Write Success!");
 9图片 105    }
10图片 106}
11图片 107图片 108/**//// <summary>
12图片 109/// FileLog类
13图片 110/// </summary>
14图片 111public class FileLog:Log
15图片 112图片 113图片 114{
16图片 115    public override void Write()
17图片 116图片 117    图片 118{
18图片 119        Console.WriteLine("FileLog Write Success!");
19图片 120    }
20图片 121}
21图片 122

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

图片 123EventLog eventlog = new EventLog();
图片 124eventlog.Write();
图片 125

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

 1图片 126图片 127/**//// <summary>
 2图片 128/// EventFactory类
 3图片 129/// </summary>
 4图片 130public class EventFactory
 5图片 131图片 132图片 133{
 6图片 134    public EventLog Create()
 7图片 135图片 136    图片 137{
 8图片 138        return new EventLog();
 9图片 139    }
10图片 140}
11图片 141图片 142/**//// <summary>
12图片 143/// FileFactory类
13图片 144/// </summary>
14图片 145public class FileFactory
15图片 146图片 147图片 148{
16图片 149    public FileLog Create()
17图片 150图片 151    图片 152{
18图片 153        return new FileLog();
19图片 154    }
20图片 155}
21图片 156

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

图片 157

实现代码如下:

1图片 158图片 159/**//// <summary>
2图片 160/// LogFactory类
3图片 161/// </summary>
4图片 162public abstract class LogFactory
5图片 163图片 164图片 165{
6图片 166    public abstract Log Create();
7图片 167}
8图片 168

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

 1图片 169图片 170/**//// <summary>
 2图片 171/// EventFactory类
 3图片 172/// </summary>
 4图片 173public class EventFactory:LogFactory
 5图片 174图片 175图片 176{
 6图片 177    public override EventLog Create()
 7图片 178图片 179    图片 180{
 8图片 181        return new EventLog();
 9图片 182    }
10图片 183}
11图片 184图片 185/**//// <summary>
12图片 186/// FileFactory类
13图片 187/// </summary>
14图片 188public class FileFactory:LogFactory
15图片 189图片 190图片 191{
16图片 192    public override FileLog Create()
17图片 193图片 194    图片 195{
18图片 196        return new FileLog();
19图片 197    }
20图片 198}
21图片 199

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

 1图片 200图片 201/**//// <summary>
 2图片 202/// App类
 3图片 203/// </summary>
 4图片 204public class App
 5图片 205图片 206图片 207{
 6图片 208    public static void Main(string[] args)
 7图片 209图片 210    图片 211{
 8图片 212        LogFactory factory = new EventFactory();
 9图片 213
10图片 214        Log log = factory.Create();
11图片 215
12图片 216        log.Write();
13图片 217    }
14图片 218}
15图片 219

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

LogFactory factory = new EventFactory();

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

LogFactory factory = new FileFactory();

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

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

1图片 220<appSettings>
2图片 221    <add key="factoryName" value="EventFactory"></add>
3图片 222</appSettings>
4图片 223

此时客户端代码如下:

 1图片 224图片 225/**//// <summary>
 2图片 226/// App类
 3图片 227/// </summary>
 4图片 228public class App
 5图片 229图片 230图片 231{
 6图片 232    public static void Main(string[] args)
 7图片 233图片 234    图片 235{
 8图片 236        string strfactoryName = ConfigurationSettings.AppSettings["factoryName"];
 9图片 237        
10图片 238        LogFactory factory;
11图片 239        factory = (LogFactory)Assembly.Load("FactoryMethod").CreateInstance("FactoryMethod." + strfactoryName);
12图片 240
13图片 241        Log log = factory.Create();
14图片 242        log.Write();
15图片 243    }
16图片 244}
17图片 245

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

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

图片 246

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

 1图片 247internal static IHttpHandler GetApplicationInstance(HttpContext context)
 2图片 248图片 249图片 250{
 3图片 251      if (HttpApplicationFactory._customApplication != null)
 4图片 252图片 253      图片 254{
 5图片 255            return HttpApplicationFactory._customApplication;
 6图片 256      }
 7图片 257      if (HttpDebugHandler.IsDebuggingRequest(context))
 8图片 258图片 259      图片 260{
 9图片 261            return new HttpDebugHandler();
10图片 262      }
11图片 263      if (!HttpApplicationFactory._theApplicationFactory._inited)
12图片 264图片 265      图片 266{
13图片 267            lock (HttpApplicationFactory._theApplicationFactory)
14图片 268图片 269            图片 270{
15图片 271                  if (!HttpApplicationFactory._theApplicationFactory._inited)
16图片 272图片 273                  图片 274{
17图片 275                        HttpApplicationFactory._theApplicationFactory.Init(context);
18图片 276                        HttpApplicationFactory._theApplicationFactory._inited = true;
19图片 277                  }
20图片 278            }
21图片 279      }
22图片 280      return HttpApplicationFactory._theApplicationFactory.GetNormalApplicationInstance(context);
23图片 281}
24图片 282

System.Web.IHttpHandlerFactory

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

图片 283<httpHandlers>
图片 284
图片 285<add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory" />
图片 286
图片 287<add verb="*" path="*.ashx" type="System.Web.UI.SimpleHandlerFactory" />
图片 288
图片 289图片 290图片 291
图片 292
图片 293</httpHandlers>
图片 294

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

图片 295

IHttpHandlerFactory工厂:

1图片 296public interface IHttpHandlerFactory
2图片 297图片 298图片 299{
3图片 300      // Methods
4图片 301      IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated);
5图片 302      void ReleaseHandler(IHttpHandler handler);
6图片 303}
7图片 304

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

抽象工厂角色:IHttpHandlerFactory

具体工厂角色:PageHandlerFactory

抽象产品角色:IHttpHandler

具体产品角色:ASP.SamplePage_aspx

进一步去理解

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

 1图片 305图片 306public class HttpHandlerFactoryImpl:IHttpHandlerFactory 图片 307{
 2图片 308   
 3图片 309   IHttpHandler IHttpHandlerFactory.GetHandler(
 4图片 310      HttpContext context, String requestType, 
 5图片 311图片 312      String url, String pathTranslated ) 图片 313{
 6图片 314
 7图片 315         return new HttpHandlerImpl();
 8图片 316         
 9图片 317   }//IHttpHandlerFactory.GetHandler
10图片 318
11图片 319   void IHttpHandlerFactory.ReleaseHandler(
12图片 320图片 321      IHttpHandler handler) 图片 322{ /**//*no-op*/ }
13图片 323
14图片 324}//HttpHandlerFactoryImpl
15图片 325
16图片 326图片 327public class HttpHandlerImpl:IHttpHandler 图片 328{
17图片 329
18图片 330图片 331   void IHttpHandler.ProcessRequest(HttpContext context) 图片 332{
19图片 333      
20图片 334      context.Response.Write("sample handler invoked图片 335");
21图片 336      
22图片 337   }//ProcessRequest
23图片 338
24图片 339图片 340   bool IHttpHandler.IsReusable 图片 341{ get 图片 342{ return false; } }
25图片 343
26图片 344}//HttpHandlerImpl
27图片 345

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

图片 346<httpHandlers>
图片 347
图片 348   <add verb="*" path="*.sample" 
图片 349
图片 350      type="HttpHandlerFactoryImpl,SampleHandler" />
图片 351
图片 352</httpHandlers>
图片 353

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

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

图片 354

在.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》