在学习工厂方法时参考了http://terrylee.cnblogs.com/archive/2006/01/04/310716.html,并引用了其中的例子
概述
在软件系统中,经常面临着“某个对象”的创建工作,由于需求的变化,这个对象的具体实现经常面临着剧烈的变化,但是它却拥有比较稳定的接口。如何应对这种变化?提供一种封装机制来隔离出“这个易变对象”的变化,从而保持系统中“其它依赖该对象的对象”不随着需求的改变而改变?这就是要说的Factory Method模式了。
意图
定义一个用户创建对象的接口,让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。
工厂方法解说
我们考虑一个日志记录的例子(这里我们只是为了说明Factory Method模式,实际项目中的日志记录不会这么去做,也要比这复杂一些)。假定我们要设计日志记录的类,支持记录的方法有FileLog和EventLog两种方式。在这里我们先不谈设计模式,那么这个日志记录的类就很好实现了:
/// 日志记录类
/// </summary>
public class Log
{
public void WriteEvent()
{
Console.WriteLine( " EventLog Success! " );
}
public void WriteFile()
{
Console.WriteLine( " FileLog Success! " );
}
public void Write( string LogType)
{
switch (LogType.ToLower())
{
case " event " :
WriteEvent();
break ;
case " file " :
WriteFile();
break ;
default :
break ;
}
}
}
这样的程序结构显然不能符合我们的要求,如果我们增加一种新的日志记录的方式 DatabaseLog ,那就要修改 Log 类,随着记录方式的变化, switch 语句在不断的变化,这样就引起了整个应用程序的不稳定,进一步分析上面的代码,发现对于 EventLog 和 FileLog 是两种完全不同的记录方式,它们之间不应该存在必然的联系,而应该把它们分别作为单独的对象来对待。 实现代码:
/// EventLog类
/// </summary>
public class EventLog
{
public void Write()
{
Console.WriteLine( " EventLog Write Success! " );
}
}
/// <summary>
/// FileLog类
/// </summary>
public class FileLog
{
public void Write()
{
Console.WriteLine( " FileLog Write Success! " );
}
}
进一步抽象,为它们抽象出一个共同的父类,结构图如下:
实现代码:
{
public abstract void Write();
}
public class EventLog : Log
{
public override void Write()
{
Console.WriteLine( " EventLog Write Success! " );
}
}
public class FileLog : Log
{
public override void Write()
{
Console.WriteLine( " FileLog Write Success! " );
}
}
此时我们再看增加新的记录日志方式DatabaseLog的时候,需要做哪些事情?只需要增加一个继承父类Log的子类来实现,而无需再去修改EventLog和FileLog类,这样的设计满足了类之间的层次关系,又很好的符合了面向对象设计中的单一职责原则,每一个类都只负责一件具体的事情。到这里似乎我们的设计很完美了,事实上我们还没有看客户程序如何去调用。 在应用程序中,我们要使用某一种日志记录方式,也许会用到如下这样的语句:
eventlog.Write();
当日志记录的方式从EventLog变化为FileLog,我们就得修改所有程序代码中出现上面语句的部分,这样的工作量是可想而知的。此时就需要解耦具体的日志记录方式和应用程序。这就要引入Factory Method模式了,每一个日志记录的对象就是工厂所生成的产品,既然有两种记录方式,那就需要两个不同的工厂去生产了,代码如下:
/// EventFactory类
/// </summary>
public class EventFactory
{
public EventLog Create()
{
return new EventLog();
}
}
/// <summary>
/// FileFactory类
/// </summary>
public class FileFactory
{
public FileLog Create()
{
return new FileLog();
}
}
这两个工厂和具体的产品之间是平行的结构,并一一对应,并在它们的基础上抽象出一个公用的接口,结构图如下:
实现代码如下:
/// LogFactory类
/// </summary>
public abstract class LogFactory
{
public abstract Log Create();
}
/// <summary>
/// EventFactory类
/// </summary>
public class EventFactory : LogFactory
{
public override Log Create()
{
return new EventLog();
}
}
/// <summary>
/// FileFactory类
/// </summary>
public class FileFactory : LogFactory
{
public override Log Create()
{
return new FileLog();
}
}
这样通过工厂方法模式我们把上面那对象创建工作封装在了工厂中,此时我们似乎完成了整个Factory Method的过程。这样达到了我们应用程序和具体日志记录对象之间解耦的目的了吗?看一下此时客户端程序代码:
Log log = factory.Create();
log.Write();
在客户程序中,我们有效地避免了具体产品对象和应用程序之间的耦合,可是我们也看到,增加了具体工厂对象和应用程序之间的耦合。那这样究竟带来什么好处呢?我们知道,在应用程序中,Log对象的创建是频繁的,在这里我们可以把
LogFactory factory = new EventFactory();
这句话放在一个类模块中,任何需要用到Log对象的地方仍然不变。要是换一种日志记录方式,只要修改一处为:
LogFactory factory = new FileFactory();
其余的任何地方我们都不需要去修改。有人会说那还是修改代码,其实在开发中我们很难避免修改,但是我们可以尽量做到只修改一处。
其实利用.NET的特性,我们可以避免这种不必要的修改。下面我们利用.NET中的反射机制来进一步修改我们的程序,这时就要用到配置文件了,如果我们想使用哪一种日志记录方式,则在相应的配置文件中设置如下:

2

3

4

此时客户端代码如下:
LogFactory factory;
factory = (LogFactory)Assembly.Load( " FactoryMethod " ).CreateInstance( " FactoryMethod. " + strfactoryName);
Log log = factory.Create();
log.Write();
现在我们看到,在引进新产品(日志记录方式)的情况下,我们并不需要去修改工厂类,而只是增加新的产品类和新的工厂类(注意:这是任何时候都不能避免的),这样很好的符合了开放封闭原则。