【IT168 技术文档】
概述 

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

意图

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

结构图



生活中的例子

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



工厂方法解说

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

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

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