First we try, then we trust

呵，你也睡得挺晚的。
最近那么有精神，是不是放假了？
  回复  引用  查看    

这个星期老婆去桂林了。 : - )
  回复  引用  查看    

非常好的文章！使我对工厂方法有了新的认识，特别是最后的例子。感谢楼主！

BTW：哈哈！我老婆带着我女儿去岳母家小住时，我也睡得很晚，看来大家都是这样吧。:P
  回复  引用    

我觉得最后一个例子应该是Builder 模式
  回复  引用    

去看一下本系列的Builder模式的第4条，简单解释了Builder和Factory的异同。实际上2者是创建过程中着眼点不同，一个是创建这个动作的抽象，另一个是创建后初始化这个过程的抽象。
  回复  引用    

可不可以这样理解:
builder模式下 在 director.Construct之前 product已经生成了
director.Construct只是都product进行初始化

而factory模式下 product 是由factory产生出来的
  回复  引用    

指导一下
http://www.pspsoft.com/idior/archive/2005/04/14/137913.html
  回复  引用  查看    

初学设计模式，还请吕老师解惑！
在您的文章中提到“使用多个工厂方法：抽象工厂角色可以规定出多于一个的工厂方法，从而使具体工厂角色实现这些不同的工厂方法，这些方法可以提供不同的商业逻辑，以满足提供不同的产品对象的任务。”我对“商业逻辑”不知道理解的对不对：抽象工厂角色中的每一个工厂方法都是返回一种产品的抽象对象，正是这种抽象对象代表了一种商业逻辑。
我对商业逻辑的概念理解模糊，觉得您的最后一个例子体现了商业逻辑：class Resume : Document
{
// Factory Method implementation
override public void CreatePages()
{
pages.Add( new SkillsPage() );
pages.Add( new EducationPage() );
pages.Add( new ExperiencePage() );
}
}
我的理解是通过多种的产品组合，体现一些特定业务，不知道这样理解对不对？
这应该是两种不同的体现业务逻辑的方式吧？

  回复  引用    

吕震宇，你好，我刚刚接触Pattern不久，有个问题向您请教：

在简单工厂中，使用参数决定创建哪个具体产品类的实例，返回抽象产品类的接口；当增加一个具体产品类时，不需要更改客户代码。（因为选择语句在工厂类提供的方法中实现）

而在工厂方法中，使用具体工厂类创建具体产品类，这样一来，客户代码需要事先判断使用哪个具体工厂来创建实例，因此当增加具体产品类时，客户代码需要改变！！！（因为选择语句在客户代码中）

那么，工厂方法究竟好在何处呢？

landx_terry@hotmail.com

谢谢！

  回复  引用    

Terry:

你好，你说中了问题的关键。其实上面工厂模式的代码过于简单，以至于产生上面的误解。其实“依赖注入（或控制反转）Ioc”模式以及我在《设计模式随笔－让众口不再难调 http://www.cnblogs.com/zhenyulu/articles/81761.html》中提到的“条件外置”解决的就是你说的问题。

在一个比较大的系统中，往往是多组并行开发。所以软件设计可以分步并行开发。上面代码开发过程中可以如此安排。1）由系统架构师设计好抽象产品和抽象工厂。2.1）多组并行开发具体产品和具体工厂。2.2）与此同时另外一组使用依赖注入技术开发主程序。在1的工作完成后2.1与2.2是可以并行的。按上面方案很可能产生3个Assembly。最后通过配置文件完成组装。

因此在实际应用时，主程序的那段代码是利用配置文件“注入”得到的，或者主程序是单独开发，因此可以确保不知道具体工厂是谁。Wayfarer的一篇文章曾循序渐进的讨论过系统如何演进，如何引入配置文件等，只是记不起名字了，你可以到他的Blog上看看。
  回复  引用  查看    

写的非常好,多谢吕老师．
  回复  引用    

谢谢，写得好。
谢谢老师。
继续关注

  回复  引用    

在Factory Method模式中，工厂类与产品类往往具有平行的等级结构，它们之间一一对应。
................................................................
纠正一下,并非一定要"一一对应"和"平行等级结构",例如在开始的例子中,如果TubeLight 是BulbLight 的子类,也是可以的
  回复  引用    

上面代码开发过程中可以如此安排。1）由系统架构师设计好抽象产品和抽象工厂。2.1）多组并行开发具体产品和具体工厂。2.2）与此同时另外一组使用依赖注入技术开发主程序。在1的工作完成后2.1与2.2是可以并行的。按上面方案很可能产生3个Assembly。最后通过配置文件完成组装。


非常正确。 事实上，这个设计模式用在组件开发中是非常有用的，而且可以通过reflect并把具体的类名已经产生实例的参数传入工厂来产生实例。 java和csharp都是通用的，在这个点上。
  回复  引用    

你好，我想请教一下你的代码是怎么粘上去的，看起来很舒服
  回复  引用    

想问一个问题，如果我把产品的构造函数申明为internal的话。这样客户代码就不能将产品接口和产品实现直接耦合。只能通过工厂来创建，这样是不是符合工厂模式的精神呢？请赐教。
  回复  引用    

看到最后的例子，我想到了盒饭。
盒饭由菜组成，某些菜构成一份

  回复  引用    

不是很清楚这些模式是怎么命名的，个人认为“多态性工厂模式”比“工厂方法模式”更能反映模式的实际情况。“工厂方法模式”这个方法不知在哪里能反映出来：（
  回复  引用    

想想在什么地方用到什么模式,这已经让我头晕了.
  回复  引用  查看    

写的不错，我们公司的架构主要是用到了工厂方法模式
  回复  引用  查看    

谢谢吕老师！！
  回复  引用  查看    

写得不错
  回复  引用  查看    

我想问一下：C#我只能看懂，不会写。其中有一句，在后面的实例中Main方法里： Document[] docs = new Document[ 2 ];而Document是抽象类。在VB里面抽象类是不能被实例化的。翻译成vb应该是dim docs as new Document(2)

  回复  引用    

在C#里可以实例化抽象类么？怎么翻译成VB呢？
  回复  引用    

@雪峰·品雨
抽象类的确不能实例化。
比如：Document tempDocs= new Document ():
编译时就会出现编译错误。
但是抽象类的子类是可以实例化的。
docs[0] = new Resume();


Document[] docs = new Document[ 2 ];
并没有实例化，估计是你看错了。


  回复  引用    

@吕兄，
你好，很喜欢你的文章，有些小问题，请赐教
关于"Factory Method模式演化 - 产品的循环使用"：
1. Product为何要Composite于ConcretProduct?
2. 为什么不设计两个子类继承自Creator，如果按照UML图的设计，岂不是不存在Factory Method了？这样的话，对于Product类型的判别又需要通过switch或if-else对字符串进行判别。
3. 下面是我的程序（本想帖UML，可惜不能高级编辑，等注册成功了...）
using System;
using System.Collections;

namespace FactoryMethod_BetterOneProduct
{
public abstract class LightCreator
{
protected ArrayList lights = new ArrayList();

public ArrayList Lights
{
get { return lights; }
}
// Complicated Factory Method
public abstract Light CreateLight();
}

public class BulbLightCreator : LightCreator
{
// Complicated Factory Method
public override Light CreateLight()
{
foreach (Light l in base.lights)
{
if (l.GetType() == typeof(BulbLight))
{
Console.WriteLine("BulbLight Already Existed");
return l;
}
}
Console.WriteLine("New BulbLight Created");
Light newl = new BulbLight();
base.lights.Add(newl);
return newl;
}
}

public class TubeLightCreator : LightCreator
{
// Complicated Factory Method
public override Light CreateLight()
{
foreach (Light l in base.lights)
{
if (l.GetType() == typeof(TubeLight))
{
Console.WriteLine("TubeLight Already Existed");
return l;
}
}
Console.WriteLine("New TubeLight Created");
Light newl = new TubeLight();
base.lights.Add(newl);
return newl;
}
}

public abstract class Light { }

public class BulbLight : Light { }

public class TubeLight : Light { }

public class Client
{
public static void Main()
{
LightCreator blc = new BulbLightCreator();
LightCreator tlc = new TubeLightCreator();

Light l1 = blc.CreateLight();
Light l2 = tlc.CreateLight();
Light l3 = blc.CreateLight();
Light l4 = tlc.CreateLight();
}
}
}

/* OUTPUT
New BulbLight Created
New TubeLight Created
BulbLight Already Existed
TubeLight Already Existed
*/
  回复  引用    

虽然有的东西看的不是很明白,理解上还是有差距,到实际用还有一段距离.但是还是有一种豁然开朗的感觉.十分感谢吕老师.
  回复  引用    

不解之处：
Document[] docs = new Document[ 2 ];
Document类是抽象类，可以实例化吗？

  回复  引用  查看    

好像　这个不是Factory Method工厂方法模式吧，应该是Abstract Factory抽象工厂模式
工厂方法模式是Template Method模板方法　的一种实现，
  回复  引用    

@kevin.li
不解之处：
Document[] docs = new Document[ 2 ];
Document类是抽象类，可以实例化吗？

-----------------------------------

并没有实例化这个抽象类
如果实例化应该写成 Document doc = new Document();
  回复  引用    

--引用--------------------------------------------------
Rolf: 去看一下本系列的Builder模式的第4条，简单解释了Builder和Factory的异同。实际上2者是创建过程中着眼点不同，一个是创建这个动作的抽象，另一个是创建后初始化这个过程的抽象。
--------------------------------------------------------

Factory是创建动作的抽象.Builder是创建过程的抽象.是这样的吧.?!
  回复  引用  查看