http://www.cnblogs.com/shenfx318/archive/2007/01/28/632724.html

在设计模式的学习过程中，Builder与Factory是创建模式中两个经典的教程，给与了我们很多值得汲取的宝贵设计思想，然而Builder 与Factory模式也是初学者容易混淆的两个模式，经常看到有人问及两者的区别与适用的场景，我在近一段设计模式的学习过程中同样碰到了这个问题，在两 种模式的区别与联系间我看到的更多是后者，在这里愿意与大家分享一些我对Builder与Factory模式的感悟，有说的不对的地方，还请各位多加提 点、指教。

写在前面

本文旨在两种模式间的对比与探讨，因此还希望各位看官首先对两个模式有一定的了解为 好，因为常常看到有人提问说，Builder模式与抽象工厂（Abstract Factory）之间的区别，其实在我看来这两者间并无太多联系，因此也就谈不上区别，至于原因在此不做细述，有兴趣的朋友可以看看我写的有关抽象工厂的文章。故本文中所提的Factory模式皆指的是工厂方法（Factory Method）。

从Builder到Factory的演化

先来看看Builder模式，Builder模式的一般设计及实现
 

 1     public interface IBuilder
 2     {
 3         void BuildPart1();
 4 
 5         void BuildPart2();
 6 
 7         Product GetResult();
 8     }
 9 //ConcreteBuilderA
10     public class BuilderA : IBuilder
11     {
12         private Product product;
13 
14         public void BuildPart1()
15         {
16             product = new Product();
17             product.Add("Part1 build by builderA");
18         }
19 
20         public void BuildPart2()
21         {
22             product.Add("Part2 build by builderA");
23         }
24 
25         public Product GetResult()
26         {
27             return product;
28         }
29     }
30 }
31 //ConcreteBuilderB
32     public class BuilderA : IBuilder
33     //
34 //Director
35     public class Director
36     {
37         public void Construct(IBuilder builder)
38         {
39             builder.BuildPart1();
40             builder.BuildPart2();
41         }
42     }

客户端调用代码

 1     public class Client
 2     {
 3         public void Run()
 4         {
 5             Director director = new Director();
 6             IBuilder builder = new BuilderB();
 7             director.Construct(builder);
 8 
 9             Product product = builder.GetResult();
10            product.Show();
11         }
12     }

从类关系图上来看，Builder模式与我们熟知的工厂模式还是具有一定的区别，最 显著的莫过于这个指导者(Director)的角色，我们观察这个Director，发现他无非是以参数的形势接收了一个Builder，并按照一定的顺 序调用其相应的方法构造各个部件，使得Builder可以完成最终的产品。这其实是对复杂对象构造顺序的封装，但我们可以看到仅仅为了做这一件事情是否有 必要为它单独设计一个类？每次都要实例化这个类的对象呢？既然建造顺序是相对稳定的，而且对于客户来讲并不关心这个顺序，那么是否可以将它与 Builder类结合？当然可以，实际中也确实常常进行这样的简化，比如StringBuilder类，我们看不到类似Director对象的存在及调 用。好，那么经过我们一次的改造以后，变成了如下形式。

客户端调用代码

 1     public class Client
 2     {
 3         public void Run()
 4         {
 5             IBuilder builder = new BuilderB();
 6             builder.Construct(); //Attention here!
 7 
 8             Product product = builder.GetResult();
 9             product.Show();
10         }
11     }

再看看客户端中的这条Builder.Construct()语句，似乎也有些多余 了，客户一般只有在需要产品的时候才会实例化一个Builder对象，因此对于客户来讲，他创建了Builder意味着他需要Builder能够为他生成 一个产品(GetProduct)，而返回产品必然需要构造Construct，于是我们又可以对代码进一步简化，将Construct方法与 GetProduct方法结合。 

 1     public class BuilderA : IBuilder
 2     {
 3         private Product product;
 4 
 5         private void BuildPart1()
 6         {
 7             product = new Product();
 8             product.Add("Part1 build by builderA");
 9         }
10 
11         private void BuildPart2()
12         {
13             product.Add("Part2 build by builderA");
14         }
15 
16         public Product GetResult()
17         {
18             //Construct here!
19             BuildPart1();
20             BuildPart2();
21 
22             return product;
23         }
24     }

 对 了，客户是不关心这个复杂对象的建造生成过程的，也就是说BuildPartN(),这些方法对于客户是没有意义的，是不可见的，那么我们就将其声明为 private,而GetProduct只是方法的一个名称，叫什么都可以，你可以叫GetResult，ReturnProduct….把它称为 Create亦可。OK，之后再来看看改造后的类图。

OMG! 从图上来看，除了名称叫做Builder外，其他根本和Factory模式没有什么区别，从代码来看，不过是工厂模式在返回具体的产品前对该产品进行了一些初始化的工作。 

1         //Create method in Buider
2         public Product Create()
3         {
4             BuildPart1(); // Initail part1 of product
5             BuildPart2(); // Initail part2 of product
6 
7             return product;
8         }

就是这些代码，我们将其挪个地方改个名称又何尝不可呢? 

 1         //Create method in Buider
 2         public Product Create()
 3         {
 4             return product;
 5         }

 6     //Build job move to the product class
 7     public class Product
 8     {
 9         ArrayList parts = new ArrayList();
10 
11         public Product()
12         {
13             InitalPart1(); // Same as BuildPart1()
14             InitalPart2(); // Same as BuildPart2()
15         }
16     }

 好了，通过对Builder模式向Factory的一步步演化，我们可以看到两者实质上并没有太多的区别，这也就是本文想要阐述的观点，也许很多朋友这时会反驳我了，说两者怎么会没有区别呢？

1. Builder模式用于创建复杂的对象。
2. 对象内部构建间的建造顺序通常是稳定的。
3. 对象内部的构建通常面临着复杂的变化。

对于持以上观点的朋友，我也有如下一些疑问。

1. 什么样的对象属于复杂的对象？关于对象复杂与否是如何划分的？
2. 站在客户的角度来讲，是否关心对象的复杂程度及建造顺序？
3. 既然客户不关心对象是否复杂以及生成的顺序，那么将这个复杂对象分布构建的意义就在于它有益于设计方了，对于设计人员，复杂对象分布构建的分布体现在哪里?是依次写几行代码还是依次调用几个方法？
4. 这种分布给你带来了哪些好处？可以帮助你应付哪些变化？

既然我们不是为了学习设计模式而学习，而是为了学习OOD的精髓，能够编写出更加灵活，适用于需求变化的软件。那么对于需求变化，我们不妨再来看看两个模式是如何应对的。Builder模式适用场景中的第3条提到了"变化"二字：对象内部的构建通常面临着复杂的变化。 就拿PartA为例，现在这个对象发生了剧烈的变化，对于Builder来讲，修改BuildPartA()方法显然是违反OCP的，于是采取第二种方 法，从抽象Builder派生一个新的NewBuilder类，为这个新的Builder添加变化后的BuildPartA()方法，其余 BuildPart方法不变。代码如下。 

 1     public class NewBuilder : IBuilder
 2     {
 3         private Product product;
 4         #region IBuilder Members
 5 
 6         public void BuildPart1()
 7         {
 8             //With new part1.
 9             product = new Product();
10             product.Add("NewPart1 build by builderA");
11         }
12 
13         public void BuildPart2()
14         {
15             //Nothing changed.
16             product.Add("Part2 build by builderA");
17         }
18 
19         

持续改进，抽象工厂也反射

http://www.cnblogs.com/shenfx318/archive/2007/01/16/621237.html

在我的上一篇文章(疑惑？改良？从简单工厂到工厂方法) 中，详细论述了创建模式中简单工厂到工厂方法的演变过程，并试图结合工厂方法的设计以及.net中的反射机制之所长，改良出一种新型的工厂—反射工厂，这 当然不是我的首创，经典的PetShop 中便有此工厂的身影。本文尝试按照前篇文章的思路，借着工厂方法到抽象工厂的演变过程而继续对抽象工厂进行改良，文章中的思想仅代表了作者当时的观点，有 欠妥的地方，还请各位不吝赐教。

工厂模式

前面的文章提 到了简单工厂和工厂方法其实是一码事，他们完成了将客户对产品功能的使用与创建具体产品职责的分割，不同的只不过是他们实现方式上的差异，工厂方法利用更 加优雅的多态性取代了相对ugly的switch case…语句，从而很好的体现了设计原则中的OCP原则，此文章将不再强调这种实现上的差异性，而更多的强调两者之间设计思路上的共性，并将这种共性统 称成为工厂模式,从而进一步与抽象工厂进行对比。

工厂的使用，选择的过程

工厂模式的使用，实际上是客户（产品的消费者）对于产品选择的过程，对于实现了相同功能的产品来讲，客户更加关心的是产品间的差异性，而工厂的作用则是将产品的生产过程封装，根据客户的要求直接返回客户需要的产品。注意，工厂只是隐藏了产品的生产过程，但是并没有剥夺客户选择的权利， 那么客户的这个选择过程又是如何体现的呢？在简单工厂中，客户通过参数的形式告诉工厂需要什么样的产品，而在工厂方法中，客户通过对工厂的选择代替了直接 对产品的选择，注意到工厂方法中一个工厂只有一个Create方法，也就是说一个工厂只负责生产一种产品，那么你选择了相应的工厂也就等同于你选择了对应 的产品。就连改良后的反射工厂也没有消去对产品的选择，只不过是将这种选择外化（外化到配置文件中，从而使得对代码的改动最小）。可以说，正是由于产品间 的差异性带给了客户选择的权利，这种权利是不应当被工厂取代的，那么工厂模式的价值又在哪里呢？答案是抽象与封装，工厂模式将由于客户的不同选择而可能导致的对已知事物的影响降到最低，途径是通过抽象产品取代具体产品，使得客户依赖于抽象（越抽象的东西越稳定），同时将客户的选择封装到一处，隔离与具体产品间的依赖。

工厂模式与抽象工厂

前面说了这么多无关的，为得是做好铺垫，更加有益于对下文的理解，OK，终于该说说从工厂模式到抽象工厂的转变了，先来对比两张类图：
 工厂方法(Factory Method)

抽象工厂(Abstract Factory)

从图中我们能够看到哪些差异？

最明显的一点就是在工厂方法的类关系图中只有一类产品，他们实现了一个统一的接口，而抽象工厂有多个类别的产品，他们分别实现了不同的功能（多个接口）。其次的一点差别就是工厂本身所具有的方法数量不同，这点差异其实也是由第一点所导致的，工厂需要有生产不同类别产品的功能，如果抽象工厂中的产品的功能简化到一个，也便成为了工厂方法。

引出类别的概念，类别是指具有相同功能的一类产品的总称。

再来看选择的过程，在工厂方法中，客户关心的只不过是实现同一样功能的不同产品间的差异，这是一个一维选择的过程。

1             IFactory factory = new FactoryA(); //选择了工厂即选择了产品
2             IProduct productA = factory.Create(); //工厂只有一个Create方法，只能生产一种产品

而在抽象工厂中，客户首先要考虑的是需要哪一样功能，其次要考虑才是产品间的差异。也就是说这是一个二维选择的过程。

1             IFactory factory = new FactoryA(); //选择了某个具体工厂
2             IProduct productA = factory.CreateProductA(); //工厂具有多个Create方法，这里选择了其中的一个

由于产品类别的增加而导致客户在考虑产品间差异的同时还要考虑产品间功能的差异，这种二维选择的过程才是工厂方法与抽象工厂之间的本质区别。

举个肯德基与麦当劳的例子，假设原来只有一家快餐店叫做麦当劳，提供的食物（具体产 品）有汉堡、可乐、薯条，它们都可以满足你吃东西（抽象接口）的需求，那么你想吃快餐的时候，唯一的选择就在于吃什么，是一维选择，现在又开了一家快餐店 叫做肯德基，同样供应汉堡、可乐和薯条，那么现在你若打算吃快餐，除了考虑吃什么外，还要考虑去哪里吃--肯德基还是麦当劳？这便是二维的选择。通过横向与纵向的选择才能最终锁定你要的产品。

引入系列的概念，相互间具有差异的同一类别的产品称为不同的系列，如肯德基和麦当劳就是两个不同的系列。

这种选择的区别带来的另外一个后果就是产品间的差异（系列间的差异）变为客户的次要选择，而客户主要的精力放在了功能的选择上（类别的选择）。

我们结合实例来看看抽象工厂的一般设计及实现

客户调用代码

1             AbstractFactory factory = new McDFactory(); //选择去麦当劳吃
2             IHamburger hamburger = factory.CreateHamburger(); //选择吃汉堡

可以看到系列间的选择由工厂的选择来替代，而类别间的选择实际上就是工厂内不同类别产品创建方法的选择。那么如此这般设计是否有依据呢？我们为什么不将工厂设计成为汉堡工厂，可乐工厂和薯条工厂呢？这其实是刚接触抽象工厂的人经常陷入的误区，这个问题的关键在于需求！需求是来自于客户的，工厂的设计取决于客户怎样使用产品。在 这个例子中，之所以要将汉堡、可乐和薯条设计为类别而不是系列，首先是因为他们对于客户有不同的功能，例如汉堡可以充饥，薯条可以解馋、可乐可以解渴，任 何一个客户希望走进一家店（无论是肯德基还是麦当劳）都能够得到上面的这三种功能，这才是客户真正的需求！如果客户选择走进了麦当劳，那么他就永远不会吃 到肯德基的食品。这里有点绕可能需要多想一下，再举个例子帮助理解，比如星际争霸游戏，里面有三个种族，每个种族的兵营都能生产三种兵，如何选定类别与系 列？抛开游戏的设计来讲，从用户的角度出发，我们还是会把系列对应成种族，那是因为任何一个玩家进入游戏后，都希望能够体验三个不同的兵种所具有的不同能 力，而不是希望拥有一个能够制造出所有三个种族一级兵的兵营。反过来讲，用户每次进入游戏只可能选择一个种族，如果他这次选择了虫族，那么他就永远不可能 生产出机枪兵。

最后再将上面提到的种种概念进行一下总结

类别 = 接口 = 抽象产品 = 具体产品所具有的共同功能，通过采用工厂的某个具体方法来体现选择。

系列 = 抽象工厂 = 同一类别间不同产品的差异，通过对实例化某个具体工厂来体现选择。

反射机制实现选择逻辑，关于工厂的工厂

有人的地方就有恩怨，有恩怨的地方就有江湖，人就是江湖，你怎么退出？

有选择的地方就有工厂，由工厂的地方就有反射，选择就是反射，你怎么设计？

呵呵… 开个玩笑，其实上面所写的几段废话就是为了论证这一个观点，有选择的地方就可以反射。看看我是如何把工厂方法改良成反射工厂的，既然工厂方法是一维的选择可以反射，那么对于抽象工厂这个二维的选择自然更不在话下，仔细观察工厂的选择过程。

1             AbstractFactory factory = new McDFactory(); //选择去麦当劳吃
2             IHamburger hamburger = factory.CreateHamburger(); //选择吃汉堡

发现选择分别是针对工厂的选择以及方法的选择，然而对于工厂内部方法的选择不适用于 反射机制，因为不同的方法实现了不同的功能，相互间没有统一的接口，何谈反射，那么反射自然就只能放在对于工厂的选择上--它们都继承自抽象工厂。于是我 们建立一个反射工厂用来动态生成需要的具体工厂，即工厂的工厂。话说起来别扭，还是看图。

 

这里新添加的FFactory就是反射工厂 ，对于反射工厂来说，Abstract Factory就是抽象产品，FactoryA和FactoryB是相应的具体产品。

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

反射工厂

1         public static IFactory CreateFactory()
2         { 
3             //从配置文件中读取需要实例化的工厂
4             string factoryName = ConfigurationSettings.AppSettings["factoryName"].ToString();
5 
6             AbstractFactory factory;
7             factory = (AbstractFactory)Assembly.Load("Abstract Factory").CreateInstance("Abstract_Factory.ImproveFactory." + factoryName);
8             return factory;
9         }

 客户使用

1         public void Run()
2         {
3             AbstractFactory factory = FFactory.CreateFactory();//生产工厂的工厂，采用反射机制
4             IProduct1 product1 = factory.CreateProduct1(); 
5             IProduct2 product2 = factory.CreateProduct2(); 
6             
7             product1.DoTask1();
8             product2.DoTask2();
9         }

补充

抽象工厂的使用除了对多系列多类别的应用外，还有一点很重要的原则，即它的一系列的产品总是在一起使用的，只有这样才更能体现出抽象工厂的价值，关于这点我会在下一篇中通过与Builder模式作对比来阐述两者间的相同与异同。

从简单工厂到工厂方法

http://www.cnblogs.com/shenfx318/archive/2007/01/09/614844.html

从简单工厂说起

严格来讲简单工厂并不属于GOF的23个设计模式之一，但它之所以存在而被人们广泛认知的原因，我想是由于它在一定程度上简化了工厂方法(Factory Method)与抽象工厂(Abstract Factory)的模式，从而可以带给新手对于工厂模式设计的精髓最直观的认识，是不少人接触工厂模式的奠基石，理解了简单工厂的设计理念及实现方法再去理解相对复杂的工厂方法与抽象工厂有着水到渠成的效果。

先来看看简单工厂的类关系图:

简单工厂一般以如下方式实现:

 1     public class SimpleFactory
 2     {
 3         /// <summary>
 4         /// Get the right product base on the paoductcategory parameter.
 5         /// </summary>
 6         /// <param name="productCategory"></param>
 7         /// <returns></returns>
 8         public static IProduct CreateProduct(string productCategory)
 9         {
10             switch (productCategory)
11             {
12                 case "A":
13                     return new ProductA();
14                 case "B":
15                     return new ProductB();
16                 case "C":
17                     return new ProductC();
18                 default:
19                     throw new Exception("Not a valid product category!");
20                     return null;
21             }
22         }
23     }

客户对于简单工厂的使用

 1     public class Client
 2     {
 3         public void Do()
 4         {
 5             //Create a productA
 6             IProduct product = SimpleFactory.CreateProduct("A");
 7             //Product doing its tasks.
 8             product.ExecuteFunction1();
 9             product.ExecuteFunction2();
10             product.ExecuteFunction3();
11             product.ExecuteFunction4();
12             //More tasks .
13         }
14     }

这时，如果客户打算改为生产产品B， 那么他需要做的仅仅是修改传入工厂的参数，以告诉工厂需要生产什么而对于后面产品所实现的功能不需要做任何的修改。简单工厂模式的最大优点在于工场模式包 含了必要的判断逻辑，可以根据客户的需求动态生成客户所需要的产品，而在客户方面，免除了客户对具体产品创建的依赖，一句话:简单工场实现了对责任的分割。
    说完了优点再来说说缺点，如果现在新增加了一种产品称作ProductC怎么办？OK，我们添加类ProductC、实现IProduct接口（注意，这个是由于新的业务规则所带来的变化，是任何模式都无法避免的），下面就是需要让我们的简单工厂具有生产这种新产品的能力，如何实现？你自然会想到多添一条case语句不就完了？然而事情并没有那么简单，因为你在添加case语句的同时也就意味着你修改了工厂类本身—违反了设计原则中最重要的一条OCP原则。开放封闭原则要求避免直接修改类而是应当通过继承来扩展类的功能。此外过多的case语句也容易混乱逻辑，造成工厂类的稳定性下降。那么对于新产品的增加，怎样才能妥善的处理并且又不违反设计原则呢？于是—工厂方法(Factory Method)登场了。 

也谈工厂方法

         先来看看工厂方法(Factory Method)的类关系图:

        

         工厂方法一般以如下方式实现:

 1     public interface IFactory
 2     {
 3         IProduct CreateProduct();
 4     }
 5 
 6     /// <summary>
 7     /// 专门负责生产ProductA的工厂
 8     /// </summary>
 9     public class ProductAFactory : IFactory
10     {
11         public IProduct CreateProduct()
12         {
13             return new ProductA();
14         }
15     }
16 
17     /// <summary>
18     /// 专门负责生产ProductB的工厂
19     /// </summary>
20     public class ProductBFactory : IFactory
21     {
22         public IProduct CreateProduct()
23         {
24             return new ProductB();
25         }
26     }

          我们再看看对于新产品ProductC，工厂方法模式所采取的应对策略。首先仍然是要添加新的类ProductC,然后添加用于生产新产品的工厂类ProductCFactory并且实现IFactory接口，这样在保证能够实例化新产品的同时又没有修改已有的代码….Perfect? 别急，这时我们再来看看客户的代码:   

 1     public class Client
 2     {
 3         public void Do()
 4         {
 5             //Create a ProductA
 6             IFactory factory = new ProductAFactory();
 7             //IFactory factory = new ProductBFactory();
 8 
 9             IProduct product = factory.CreateProduct();
10             product.DoTask1();
11             product.DoTask2();
12             product.DoTask3();
13             product.DoTask4();
14             product.DoTask5();
15             //Do more tasks 
16         }
17     }

         这时你会发现，客户端需要决定实例化哪一个工厂来生产自己所需要的产品，判断逻辑仍然存在，仅仅是从简单工厂的内部逻辑判断移到了客户端代码进行逻辑判断。也就是说如果你要想最终生产出ProductC仍然需要修改代码，而只是这次修改的位置移到了客户端！

         应对策略，很多人都知道这种问题的一个有效的解决方式是可以利用.Net的反射特性或其他IOC机制，具体做法是将需要实例化的工厂类名写到配置文件中，通过反射来读去，代码如下:

1   <appSettings>
2     <add key="FactoryName" value="ProductBFactory" />
3   </appSettings>

 1     public class Client
 2     {
 3         public void Do()
 4         {
 5             string factoryName = ConfigurationSettings.AppSettings["FactoryName"];
 6             IFactory factory = (IFactory)Assembly.Load("Factory Method").CreateInstance("Factory_Method." + factoryName);
 7 
 8             IProduct product = factory.CreateProduct();
 9             product.DoTask();
10         }
11     }

         到这里几乎可以说是对于对象创建的一个完美应对策略，然而…. 

新的疑问

         有“好事”者提出，既然都用到了.Net的反射机制那么工厂类本身是否还有存在的必要呢？是否可以通过在配制文件中写入需要生产的产品名称直接反射出具体的产品实例，从而略去工厂生产的步骤？具体代码参照如下:

1             IProduct product = (IProduct)Assembly.Load("Factory Method").CreateInstance("Factory_Method." + productName);
2             product.DoTask();

         对于这个问题，虽然看起来他在代码上有了一定的简化但是我认为他忽略了工厂模式的另一个特点，它集中封装了对象的创建,体现了代码的重用性。

         我们再来对比一下两段代码,未使用工厂:

1             IProduct product1 = (IProduct)Assembly.Load("Factory Method").CreateInstance("Factory_Method." + productName);
2             product1.DoTask();
3 
4             IProduct product2 = (IProduct)Assembly.Load("Factory Method").CreateInstance("Factory_Method." + productName);
5             product2.DoTask();
6 
7             IProduct product3 = (IProduct)Assembly.Load("Factory Method").CreateInstance("Factory_Method." + productName);
8             product3.DoTask();

       使用了工厂：

 1             IFactory factory = (IFactory)Assembly.Load("Factory Method").CreateInstance("Factory_Method." + factoryName);
 2 
 3             IProduct product1 = factory.CreateProduct();
 4             product1.DoTask();
 5 
 6             IProduct product2 = factory.CreateProduct();
 7             product2.DoTask();
 8 
 9             IProduct product3 = factory.CreateProduct();
10             product3.DoTask();

         可以看到没有使用工厂方法的代码段到处充斥了类似(IProduct)Assembly.Load("Factory Method").CreateInstance("Factory_Method." + productName)这样的代码，首先它不够优雅，其次没有考虑代码的重用性，如果项目的程序集名称或者命名空间发生了改变呢？虽然这种情况在实际项目中很少发生，但是你可以考虑一下若真的发生这种情况，你又需要修改多少地方~。那么这就是最终的解决方案了么，在我看来工厂方法(Factory Method)仍然有值得商榷的地方。

         首先，逻辑相对复杂，不易使用。是否每个人都可以随意的在项目中熟练的运用工厂方法模式呢？

         其次，可以看到在每增加一种新产品类型的时候，我们都需要多添加一个生产该产品的工厂，这便带来了业务需求之外的工作量。下面…. 

新的解决方案

         借助第三节中所提到的反射机制的运用，我思考着能否将反射机制与简单工厂相结合，仍然借助简单工厂的设计模式，而将其对产品的判断逻辑由原先的代码改为反射配置文件。首先参照以下代码。

         改良后的简单工厂:

1     public class ImprovedFactory
2     {
3         public static IProduct CreateProduct()
4         {
5             string productName = ConfigurationSettings.AppSettings["ProductName"];
6             IProduct product = (IProduct)Assembly.Load("Factory Method").CreateInstance("Factory_Method.improvement." + productName);
7             return product;
8         }
9     }

         Ok，我们再看看客户端代码:

1             IProduct product = ImprovedFactory.CreateProduct();
2             product.DoTask();

         同样是对于新产品ProductC，新的解决方法需要做哪些工作?

a)          添加类ProductC并实现IProduct接口，就像前面我说的，这是使用任何模式都无法避免的改变。

b)         在配置文件中多添加一条关于ProductC的配置信息。

看到了么?没有那么多复杂的抽象、具体工厂；不需要对新的产品添加新的工厂；不需要修改工厂类本身或是客户端代码；没有破坏任何设计原则。仅仅需要上面两步就完成一个新产品的添加及创建工作。

 

  以上是我对一种新的解决方案的尝试，也许这种方案也有缺陷的地方，但是我暂时还没有想到具体缺陷有哪些，刚刚接触设计模式不久，很多想法还不够成熟，还希望各位老师前辈多加指点。