板桥里人 http://www.jdon.com 2002/05/05（转载请保留）

模式实战书籍《Java实用系统开发指南》

Visitor访问者模式定义
作用于某个对象群中各个对象的操作. 它可以使你在不改变这些对象本身的情况下,定义作用于这些对象的新操作.

在Java中,Visitor模式实际上是分离了collection结构中的元素和对这些元素进行操作的行为.

为何使用Visitor?
Java的Collection(包括Vector和Hashtable)是我们最经常使用的技术,可是Collection好象是个黑色大染缸,本来有 各种鲜明类型特征的对象一旦放入后,再取出时,这些类型就消失了.那么我们势必要用If来判断,如:

Iterator iterator = collection.iterator()
while (iterator.hasNext()) {
　　 Object o = iterator.next();
　　 if (o instanceof Collection)
　　 　　 messyPrintCollection((Collection)o);
　　 else if (o instanceof String)
　　 　　 System.out.println("'"+o.toString()+"'");
　　 else if (o instanceof Float)
　　 　　 System.out.println(o.toString()+"f");
　　 else
　　 　　 System.out.println(o.toString());
}
在上例中,我们使用了 instanceof来判断 o的类型.

很显然,这样做的缺点代码If else if 很繁琐.我们就可以使用Visitor模式解决它.

如何使用Visitor?
针对上例,定义接口叫Visitable,用来定义一个Accept操作,也就是说让Collection每个元素具备可访问性.

被访问者是我们Collection的每个元素Element,我们要为这些Element定义一个可以接受访问的接口(访问和被访问是互动的,只有访问者,被访问者如果表示不欢迎,访问者就不能访问),取名为Visitable，也可取名为Element。

被访问的具体元素继承这个新的接口Visitable：

上面是被访问者是字符串类型，下面再建立一个Float类型的：

我 们设计一个接口visitor访问者，在这个接口中,有一些访问操作，这些访问操作是专门访问对象集合Collection中有可能的所有类，目前我们假 定有三个行为：访问对象集合中的字符串类型；访问对象集合中的Float类型；访问对象集合中的对象集合类型。注意最后一个类型是集合嵌套，通过这个嵌套 实现可以看出使用访问模式的一个优点。

接口visitor访问者如下：

访问者的实现:

在上面的visitCollection我们实现了对Collection每个元素访问,只使用了一个判断语句,只要判断其是否可以访问.

StringElement只是一个实现，可以拓展为更多的实现，整个核心奥妙在accept方法中，在遍历Collection时，通过相应的accept方法调用具体类型的被访问者。这一步确定了被访问者类型，

如果是StringElement，而StringElement则回调访问者的visiteString方法，这一步实现了行为操作方法。

客户端代码：

客户端代码中的list对象集合中放置了多种数据类型，对对象集合中的访问不必象一开始那样，使用instance of逐个判断，而是通过访问者模式巧妙实现了。

至此,我们完成了Visitor模式基本结构.

使用Visitor模式的前提
使用访问者模式是对象群结构中(Collection) 中的对象类型很少改变。

在两个接口Visitor和Visitable中,确保Visitable很少变化,也就是说，确保不能老有新的Element元素类型加进来，可以变化的是访问者行为或操作，也就是Visitor的不同子类可以有多种,这样使用访问者模式最方便.

如果对象集合中的对象集合经常有变化, 那么不但Visitor实现要变化，Visistable也要增加相应行为，GOF建议是,不如在这些对象类中直接逐个定义操作，无需使用访问者设计模式。

但是在Java中，Java的Reflect技术解决了这个问题，因此结合reflect反射机制，可以使得访问者模式适用范围更广了。

作者简介

陈刚，广西桂林人，著作有《Eclipse从入门到精通》
您可以通过其博客了解更多信息和文章：http://www.ChenGang.com.cn
版权声明：本博客所有文章仅适用于非商业性转载，并请在转载时注明出处及作者的署名。

分析软件需求，以用户的角度来使用软件，找出发生的scenerio，抽象成为一个一个Use Case，分析出Use Case之间的关系，这一步是非常重要的，这一步做好了，设计就成功了一半。Use Case的抽象有一些可以遵循的原则，这里不详细谈。

然后用语言描述每一个Use Case，描述用户使用一个Use Case发生的主事件流以及异常流。

这样就完成了需求分析阶段。

二。概要设计(找出实体 + 分析实体类之间的关系 + 提取控制类 + 画序列图)

接下来做概要设计，针对每个Use Case，读Use Case的描述，看事件流，找出所有的实体类，这也有一些可以遵循的原则，例如找出所有的名词，画表格排除等等方法。

然后分析实体类之间的关系，是包含，聚合还是依赖，是1：1，还是1：n，还是其他....，根据这些关系，就可以得出实体类和别的实体类想关联的属性，然后再找出每个实体类本身重要的属性。

然后再次分析Use Case的事件流，一方面check实体类的设计是否合理，另一方面你可以找出动词，分析对实体类的控制逻辑，这样就可以可以设计出业务控制类，一般你可 以一个实体类一个控制类，也可以业务逻辑相关的实体类由一个Facade Session Bean(非EJB含义)来统一控制，这里面的控制类的颗粒度就由你自己来掌握了。一般来说先可以设计一些细颗粒度的控制类，然后再按照模块，用粗粒度封 装细颗粒度的控制类，提供给Web层一个Facade。

然后你可以画序列图，就是用序列图来表达事件流，在这个过程中，你需要不断回到类图，给控制类添加方法，而序列图就是控制类的方法调用。

至此，你已经在Rose里面完成了概要设计，当然你不可能一次设计完善，会有很多次迭代，因此你不能一开始把类设计的太详细，只抓住主要的属性和方法，特别需要注意的是，是抽象的设计，不要用具体的编程语言来表达类。

三。实施(结合xdoclet和Schema工具自动生成代码)

然后你就可以抛开Rose了，转到Eclipse+Togehter里面，根据那些类，规划一下package层次，然后在Together里面进行类的详细设计，所有需要的属性一一写上，当然你还是不可能一下把所有的属性方法写全，不过没有关系，把重要的写好就行了。

然后类框架已经生成好了，给所有的实体类加上xdoclet，然后生成hbm，然后用Hibernate的ExportScheme生成DDL，运行一遍自动创建好所有的表。这样所有的实体相关类全部做好了。

你现在就集中精力把控制类那些方法里面的代码填写上就OK了，在这个过程，你会发现有些实体类缺属性，没有关系，加上属性，然后写好xdoclet，运行一遍，自动生成hbm，自动创建好表，然后继续写你的方法，也有可能你发现控制类缺方法，那么就加上。

基本上实体类就是getter/setter，和少量的实体相关方法，所有的控制逻辑都写在控制类里面。

最后你的软件就基本写好了，用Eclipse生成好一堆你的testCase运行测试，反复修改，除bug。

看看使用OOAD的设计思路，是多么的爽的事情阿！你只需要把精力放到Use Case的抽象，实体类的关系总结，控制类的归纳。而当你使用Eclipse＋Together之后，你所需要写的代码只不过是控制类的方法实现代码，其 他的都已经生成好了。另外可能需要写少量工具类。

banq http://www.jdon.com Dec 7, 2003 12:10 AM 回复

板桥里人 http://www.jdon.com 2002/4/6/

模式实战书籍《Java实用系统开发指南》

State模式的定义 : 不同的状态,不同的行为;或者说,每个状态有着相应的行为.

何时使用 ?
State模式在实际使用中比较多,适合"状态的切换".因为我们经常会使用If elseif else 进行状态切换, 如果针对状态的这样判断切换反复出现,我们就要联想到是否可以采取State模式了.

不 只是根据状态,也有根据属性.如果某个对象的属性不同,对象的行为就不一样,这点在数据库系统中出现频率比较高,我们经常会在一个数据表的尾部,加上 property属性含义的字段,用以标识记录中一些特殊性质的记录,这种属性的改变(切换)又是随时可能发生的,就有可能要使用State.

是否使用?
在实际使用,类似开关一样的状态切换是很多的,但有时并不是那么明显,取决于你的经验和对系统的理解深度.

这里要阐述的是"开关切换状态" 和" 一般的状态判断"是有一些区别的, " 一般的状态判断"也是有 if..elseif结构,例如:

　　　　if (which==1) state="hello";
　　　　else if (which==2) state="hi";
　　　　else if (which==3) state="bye";

这是一个 " 一般的状态判断",state值的不同是根据which变量来决定的,which和state没有关系.如果改成:

　　　　if (state.euqals("bye")) state="hello";
　　　　else if (state.euqals("hello")) state="hi";
　　　　else if (state.euqals("hi")) state="bye";

这就是 "开关切换状态",是将state的状态从"hello"切换到"hi",再切换到""bye";在切换到"hello",好象一个旋转开关,这种状态改变就可以使用State模式了.

如 果单纯有上面一种将"hello"-->"hi"-->"bye"-->"hello"这一个方向切换,也不一定需要使用State模 式,因为State模式会建立很多子类,复杂化,但是如果又发生另外一个行为:将上面的切换方向反过来切换,或者需要任意切换,就需要State了.

请看下例:

在上例中,我们有两个动作push推和pull拉,这两个开关动作,改变了Context颜色,至此,我们就需要使用State模式优化它.

另外注意:但就上例,state的变化,只是简单的颜色赋值,这个具体行为是很简单的,State适合巨大的具体行为,因此在,就本例,实际使用中也不一定非要使用State模式,这会增加子类的数目,简单的变复杂.

例如: 银行帐户, 经常会在Open 状态和Close状态间转换.

例如: 经典的TcpConnection, Tcp的状态有创建 侦听 关闭三个,并且反复转换,其创建 侦听 关闭的具体行为不是简单一两句就能完成的,适合使用State

例如:信箱POP帐号, 会有四种状态, start HaveUsername Authorized quit,每个状态对应的行为应该是比较大的.适合使用State

例如:在工具箱挑选不同工具,可以看成在不同工具中切换,适合使用State.如 具体绘图程序,用户可以选择不同工具绘制方框 直线 曲线,这种状态切换可以使用State.

如何使用
State需要两种类型实体参与:

1.state manager 状态管理器 ,就是开关 ,如上面例子的Context实际就是一个state manager, 在state manager中有对状态的切换动作.
2.用抽象类或接口实现的父类,,不同状态就是继承这个父类的不同子类.

以上面的Context为例.我们要修改它,建立两个类型的实体.
第一步: 首先建立一个父类:

父类中的方法要对应state manager中的开关行为,在state manager中 本例就是Context中,有两个开关动作push推和pull拉.那么在状态父类中就要有具体处理这两个动作:handlepush() handlepull(); 同时还需要一个获取push或pull结果的方法getcolor()

下面是具体子类的实现:

同样 其他状态的子类实现如blue一样.

第二步: 要重新改写State manager 也就是本例的Context:

至此,我们也就实现了State的refactorying过程.

以上只是相当简单的一个实例,在实际应用中,handlepush或handelpull的处理是复杂的.

状态模式优点：
（1） 封装转换过程，也就是转换规则
（2） 枚举可能的状态，因此，需要事先确定状态种类。

状态模式可以允许客户端改变状态的转换行为，而状态机则是能够自动改变状态，状态机是一个比较独立的而且复杂的机制，具体可参考一个状态机开源项目：http://sourceforge.net/projects/smframework/

状态模式在工作流或游戏等各种系统中有大量使用，甚至是这些系统的核心功能设计，例如政府OA中，一个批文的状态有多种：未办；正在办理；正在批示；正在审核；已经完成等各种状态，使用状态机可以封装这个状态的变化规则，从而达到扩充状态时，不必涉及到状态的使用者。

在网络游戏中，一个游戏活动存在开始；开玩；正在玩；输赢等各种状态，使用状态模式就可以实现游戏状态的总控，而游戏状态决定了游戏的各个方面，使用状态模式可以对整个游戏架构功能实现起到决定的主导作用。

状态模式实质：
使用状态模式前，客户端外界需要介入改变状态，而状态改变的实现是琐碎或复杂的。

使用状态模式后，客户端外界可以直接使用事件Event实现，根本不必关心该事件导致如何状态变化，这些是由状态机等内部实现。

这是一种Event-condition-State，状态模式封装了condition-State部分。

每个状态形成一个子类，每个状态只关心它的下一个可能状态，从而无形中形成了状态转换的规则。如果新的状态加入，只涉及它的前一个状态修改和定义。

状态转换有几个方法实现：一个在每个状态实现next()，指定下一个状态；还有一种方法，设定一个StateOwner，在StateOwner设定stateEnter状态进入和stateExit状态退出行为。

状态从一个方面说明了流程，流程是随时间而改变，状态是截取流程某个时间片。

相关文章：

从工作流状态机实践中总结状态模式使用心得

参考资源:
the State and Stategy
How to implement state-dependent behavior
The state patterns

转自

.Net中的设计模式——Composite模式

一、模式概述

描述Composite模式的最佳方式莫过于树形图。从抽象类或接口为根节点开始，然后生枝发芽，以形成树枝节点和叶结点。因此， Composite模式通常用来描述部分与整体之间的关系，而通过根节点对该结构的抽象，使得客户端可以将单元素节点与复合元素节点作为相同的对象来看 待。

由于Composite模式模糊了单元素和复合元素的区别，就使得我们为这些元素提供相关的操作时，可以有一个统一的接口。例如，我们要编写一个字 处理软件，该软件能够处理文字，对文章进行排版、预览、打印等功能。那么，这个工具需要处理的对象，就应该包括单个的文字、以及由文字组成的段落，乃至整 篇文档。这些对象从软件处理的角度来看，对外的接口应该是一致的，例如改变文字的字体，改变文字的位置使其居中或者右对齐，也可以显示对象的内容，或者打 印。而从内部实现来看，我们对段落或者文档进行操作，实质上也是对文字进行操作。从结构来看，段落包含了文字，文档又包含了段落，是一个典型的树形结构。 而其根节点正是我们可以抽象出来暴露在外的统一接口，例如接口IElement：

既然文字、段落、文档都具有这些操作，因此它们都可以实现IElement接口：

从上图可以看到，对象Word、Paragraph、Document均实现了IElement接口，但Paragraph和Document与 Word对象不同的是，这两者处除了实现了IElement接口，它们还与IElement接口对象之间具有聚合的关系，且是一对多。也就是说 Paragraph与Document对象内可以包含0个到多个IElement对象，这也是与前面对字处理软件分析获得的结果是一致的。

从整个结构来看，完全符合树形结构的各个要素，接口IElement是根节点，而Paragraph和Document类为枝节点，Word对象为 叶节点。既然作为枝节点，它就具有带叶节点的能力，从上图的聚合关系中我们体现出了这一点。也就是说，Paragraph和Document类除了具有排 版、打印方面的职责外，还能够添加、删除叶节点的操作。那么这些操作应该放在哪里呢？

管理对子节点的管理，Composite模式提供了两种方式：一个是透明方式，也就是说在根节点中声明所有用来管理子元素的方法，包括Add()、 Remove()等方法。这样一来，实现根节点接口的子节点同时也具备了管理子元素的能力。这种实现策略，最大的好处就是完全消除了叶节点和枝节点对象在 抽象层次的区别，它们具备完全一致的接口。而缺点则是不够安全。由于叶节点本身不具备管理子元素的能力，因此提供的Add()、Remove()方法在实 现层次是无意义的。但客户端调用时，却看不到这一点，从而导致在运行期间有出错的可能。

另一种策略则是安全方式。与透明方式刚好相反，它只在枝节点对象里声明管理子元素的方法，由于叶节点不具备这些方法，当客户端在操作叶节点时，就不会出现前一种方式的安全错误。然而，这种实现方式，却导致了叶节点和枝节点接口的不完全一致，这给客户端操作时带来了不便。

这两种方式各有优缺点，我们在实现时，应根据具体的情况，作出更加合理的抉择。在字处理软件一例中，我选择了安全方式来实现，因为对于客户端而言， 在调用IElement接口时，通常是将其视为可被排版、打印等操作的对象。至于为Paragraph和Document对象添加、删除子对象，往往是一 种初始化的行为，完全可以放到一个单独的模块中。根据单一职责原则（SRP），我们没有必要让IElement接口负累太重。所以，我们需要对上图作稍许 的修改，在Paragraph和Document对象中增加Add()和Remove()方法：

以下是IElement对象结构的实现代码：
public interface IElement
{
      void ChangeFont(Font font);
      void Show();
      //其他方法略;
}
public class Word
{
 public void ChangeFont(Font font)
 {
      this.font = font;
 }
 public void Show()
 {
      Console.WriteLine(this.ToString());
 }
 //其他方法略;
}
public class Paragraph
{
 private ArrayList elements = new ArrayList();
 public void Add(IElement element)
 {
      elements.Add(element);
 }
 public void Remove(IElement element)
 {
      elements.Remove(element);
 }
 public void ChangeFont(Font font)
 {
      foreach (IElement element in elements)
      {
          element.ChangeFont(font);
  }
 }
 public void Show()
 {
      foreach (IElement element in elements)
      {
          element.Show(font);
  }
 }
 //其他方法略;
}
//Document类略；

实际上，我们在为叶节点实现Add()，Remove()方法时，还需要考虑一些异常情况。例如在Paragraph类中，添加的子元素就不能是 Document对象和Paragraph对象。所以在添加IElement对象时，还需要做一些条件判断，以确定添加行为是否正确，如果错误，应抛出异 常。

采用Composite模式，我们将Word、Paragraph、Document抽象为IElement接口。虽然各自内部的实现并不相同，枝 节点和叶节点的实质也不一样，但对于调用者而言，是没有区别的。例如在类WordProcessor中，包含一个GetSelectedElement ()静态方法，它能够获得当前选择的对象：
public class WordProcessor
{
 public static IElement GetSelectedElement(){……}
}

对于字处理软件的UI来说，如果要改变选中对象的字体，则可以在命令按钮cmdChangeFont的Click事件中写下如下代码：
public void cmdChangeFont_Click(object sender, EventArgs e)
{
    WordProcessor.GetSelectedElement().ChangeFont(currentFont);
}

不管当前选中的对象是文字、段落还是整篇文档，对于UI而言，操作都是完全一致的，根本不需要去判断对象的类别。因此，如果在Business Layer的类库设计时，采用Composite模式，将极大地简化UI表示层的开发工作。此外，应用该模式也较好的支持项目的可扩展性。例如，我们为 IElement接口增加了Sentence类，对于前面的例子而言，只需要修改GetSelectedElement()方法，而 cmdChangeFont命令按钮的Click事件以及Business Layer类库原有的设计，都不需要做任何改变。这也符合OO的开放-封闭原则（OCP），即对于扩展是开放的(Open for extension)，对于更改则是封闭的（Closed for modification）。

二、.Net Framework中的Composite模式

在.Net中，最能体现Composite模式的莫过于Windows或Web的控件。在这些控件中，有的包含子控件，有的则不包含且不能包含子控 件，这正好符合叶节点和枝节点的含义。所有Web控件的基类为System.Web.UI.Contril类（如果是Windows控件，则基类为 System.Windows.Forms.Control类）。其子类包含有HtmlControl、HtmlContainerControl等。按 照Composite模式的结构，枝节点和叶节点属于根节点的不同分支，同时枝节点与根节点之间应具备一个聚合关系，可以通过Add()、Remove ()方法添加和移除其子节点。设定HtmlControl为叶节点，而HtmlContaiinerControl为枝节点，那么采用透明方式的设计方 法，在.Net中控件类的结构，就应该如下图所示：

虽然根据透明方式的Composite模式，HtmlControl类与其父类Control之间也应具备一个聚合关系，但实质上该类并不具备管理 子控件的职责，因此我在类图中忽略了这个关系。此时，HtmlControl类中的Add()、Remove()方法，应该为空，或者抛出一个客户端能够 捕获的异常。

然而，从具体实现来考虑，由于HtmlControl类和HtmlContainerControl类在实现细节层次，区别仅在于前者不支持子控 件，但从控件本身的功能来看，很多行为是相同或者相近的。例如HtmlControl类的Render()方法，调用了方法RenderBeginTag ()方法：
protected override void Render(HtmlTextWriter writer)
{
      this.RenderBeginTag(writer);
}
protected virtual void RenderBeginTag(HtmlTextWriter writer)
{
      writer.WriteBeginTag(this.TagName);
      this.RenderAttributes(writer);
      writer.Write(’>');
}

而HtmlContainerControl类也具有Render()方法，在这个方法中也调用了RenderBeginTag()方法，且RenderBeginTag方法的实现和前者完全一致：
protected override void Render(HtmlTextWriter writer)
{
      this.RenderBeginTag(writer);
      this.RenderChildren(writer);
      this.RenderEndTag(writer);
}

按照上面的结构，由于HtmlControl和HtmlContainerControl之间并无继承关系，这就要求两个类中，都要重复实现 RenderBeginTag()方法，从而导致产生重复代码。根据OO的特点，解决的办法，就是让HtmlContainerControl继承自 HtmlControl类（因为HtmlContainerControl的接口比HtmlControl宽，所以只能令 HtmlContainerControl作为子类），并让RenderBeginTag()方法成为HtmlControl类的protected方 法，子类HtmlContainerControl可以直接调用这个方法。然而与之矛盾的是，HtmlContainerControl却是一个可以包含 子控件的枝节点，而HtmlControl则是不能包含子控件的叶节点，那么这样的继承关系还成立吗？

HtmlControl类对Add()方法和Remove()方法的重写后，这两个方法内容为空。由于HtmlContainerControl类 继承HtmlControl类，但我们又要求它的Add()和Remove()方法和Control类保持一致，而父类HtmlControl已经重写这 两个方法，此时是无法直接继承来自父类的方法的。以上是采用透明方式的设计。

如果采用安全方式，仍然有问题。虽然在HtmlControl类中不再有Add()和Remove()方法，但由于Control类和 HtmlContainerControl类都允许添加子控件，它们包含的Add()、Remove()方法，只能分别实现。这样的设计必然会导致重复代 码。这也是与我们的期望不符的。

那么在.Net中，Control类究竟是怎样实现的呢？下面，我将根据.Net实现Control控件的源代码，来分析Control控件的真实结构，以及其具体的实现细节。

三、深入分析.Net中的Composite模式

首先，我们来剖析Web控件的基类Control类的内部实现：

public class Control : IComponent, IDisposable, IParserAccessor, IDataBindingsAccessor
{
       // Events;略  
       // Methods
 public Control()
 {
             if (this is INamingContainer)
             {
                    this.flags[0×80] = true;
             }
 }
 public virtual bool HasControls()
 {
              if (this._controls != null)
              {
                    return (this._controls.Count > 0);
              }
              return false;
 }
 public virtual void DataBind()
        {
              this.OnDataBinding(EventArgs.Empty);   
              if (this._controls != null)           
       {                
              string text1 = this._controls.SetCollectionReadOnly(”Parent_collections_readonly”);
                        int num1 = this._controls.Count;
                 for (int num2 = 0; num2 < num1; num2++)                 
   {
                         this._controls[num2].DataBind();
                   }
                   this._controls.SetCollectionReadOnly(text1);
              }
 }
        protected virtual void Render(HtmlTextWriter writer)
 {
              this.RenderChildren(writer);
 }
 protected virtual ControlCollection CreateControlCollection()
 {
              return new ControlCollection(this);
 }
       // Properties
 public virtual ControlCollection Controls
 {
             get
             {
                   if (this._controls == null)
                   {
                         this._controls = this.CreateControlCollection();
                   }
                   return this._controls;
             }
 }
        // Fields
        private ControlCollection _controls;
}

Control基类中的属性和方法很多，为清晰起见，我只保留了几个与模式有关的关键方法与属性。在上述的源代码中，我们需要注意几点：

1、Control类不是抽象类，而是具体类。这是因为在设计时，我们可能会创建Control类型的实例。根据这一点来看，这并不符合OOP的要 求。一般而言，作为抽象出来的基类，必须定义为接口或抽象类。不过在实际的设计中，也不应拘泥于这些条条框框，而应审时度势，根据实际的情况来抉择最佳的 设计方案。
2、公共属性Controls为ControlCollection类型，且该属性为virtual属性。也就是说，这个属性可以被它的子类 override。同时，该属性为只读属性，在其get访问器中，调用了方法CreateControlCollection()；这个方法为 protected虚方法，默认的实现是返回一个ControlCollection实例。
3、方法HasControls()，功能为判断Control对象是否有子控件。它判断的依据是根据私有字段_controls（即公共属性 Controls）的Count值。但是需要注意的是，通过HasControls()方法的返回值，并不能决定对象本身属于叶节点，还是枝节点。因为即 使是枝节点其内部仍然可以不包含任何子对象。
4、 方法DataBind()的实现中，首先调用了自身的OnDataBinding()方法，然后又遍历了Controls中的所有控件，并调用其 DataBind()方法。该方法属于控件的共有行为，从这里可以看出不管是作为叶节点的控件，还是作为枝节点的控件，它们都实现统一的接口。对于客户端 调用而言，枝节点和叶节点是没有区别的。
5、 Control类的完整源代码中，并不存在Add()、Remove()等类似的方法，以提供添加和移除子控件的功能。事实上，继承Control类的所有子类均不存在Add()、Remove()等方法。

显然，在Control类的定义和实现中，值得我们重视的是公共属性Controls的类型ControlCollection。顾名思义，该类必 然是一个集合类型。是否有关子控件的操作，都是在ControlCollection类型中实现呢？我们来分析一下ControlCollection的 代码：
public class ControlCollection : ICollection, IEnumerable
{
       // Methods
 public ControlCollection(Control owner)
 {
               this._readOnlyErrorMsg = null;
               if (owner == null)
               {
                       throw new ArgumentNullException("owner");
               }
               this._owner = owner;
        }
 public virtual void Add(Control child)
        {
               if (child == null)
               {
                throw new ArgumentNullException("child");
               }
               if (this._readOnlyErrorMsg != null)
                   {
                throw new HttpException(HttpRuntime.FormatResourceString(this._readOnlyErrorMsg));
               }
               if (this._controls == null)
               {
                   this._controls = new Control[5];
               }
               else if (this._size >= this._controls.Length)
               {
                   Control[] controlArray1 = new Control[this._controls.Length * 4];
                   Array.Copy(this._controls, controlArray1, this._controls.Length);
                   this._controls = controlArray1;
               }
               int num1 = this._size;
               this._controls[num1] = child;
               this._size++;
               this._version++;
               this._owner.AddedControl(child, num1);
        }
        public virtual void Remove(Control value)
 {
               int num1 = this.IndexOf(value);
               if (num1 >= 0)
               {
                this.RemoveAt(num1);
               }
        }
        // Indexer
 public virtual Control this[int index]
 {
               get
               {
                    if ((index < 0) || (index >= this._size))
                    {
                         throw new ArgumentOutOfRangeException(”index”);
                    }
                    return this._controls[index];
               }
 }
 // Properties    
 public int Count
 {
        get
               {
                    return this._size;
               }
        }
 protected Control Owner
 {
               get
               {
                    return this._owner;
               }
 }
        protected Control Owner { get; }   
        // Fields
        private Control[] _controls;
        private const int _defaultCapacity = 5;
        private const int _growthFactor = 4;
 private Control _owner;    
}

一目了然，正是ControlCollection的Add()、Remove()方法完成了对子控件的添加和删除。例如：
Control parent = new Control();
Control child = new Child();
//添加子控件child;
parent.Controls.Add(child);
//移除子控件child;
parent.Controls.Remove(child);

为什么要专门提供ControlCollection类型来管理控件的子控件呢？首先，作为类库使用者，自然希望各种类型的控件具有统一的接口，尤 其是自定义控件的时候，不希望自己重复定义管理子控件的操作；那么采用透明方式自然是最佳方案。然而，在使用控件的时候，安全也是需要重点考虑的，如果不 考虑子控件管理的合法性，一旦使用错误，会导致整个应用程序出现致命错误。从这样的角度考虑，似乎又应采用安全方式。这里就存在一个抉择。故而，.Net 在实现Control类库时，利用了职责分离的原则，将控件对象管理子控件的属性与行为和控件本身分离，并交由单独的ControlCollection 类负责。同时采用聚合而非继承的方式，以一个公共属性Controls，存在于Control类中。这种方式，集保留了透明方式和安全方式的优势，又摒弃 了这两种方式固有的缺陷，因此我名其为“复合方式”。

“复合方式”的设计，其对安全的保障，不仅仅是去除了Control类关于子控件管理的统一接口，同时还通过异常管理的方式，在ControlCollection类的子类中实现：
public class EmptyControlCollection : ControlCollection
{
        // Methods
 public EmptyControlCollection(Control owner) : base(owner)
 {}
 public override void Add(Control child)
 {
            this.ThrowNotSupportedException();
 }                         
        private void ThrowNotSupportedException()
        {
            throw new HttpException(HttpRuntime.FormatResourceString(”Control_does_not_allow_children”, base.Owner.GetType().ToString()));
        }
}

EmptyControlCollection继承了ControlCollection类，并重写了Add()等添加子控件的方法，使其抛出一个 异常。注意，它并没有重写父类的Remove()方法，这是因为ControlCollection类在实现Remove()方法时，对集合内的数据进行 了非空判断。而在EmptyControlCollection类中，是不可能添加子控件的，直接调用父类的Remove()方法，是不会出现错误的。

既然管理子控件的职责由ControlCollection类型负责，且Control类中的公共属性Controls即为 ControlCollection类型。所以，对于控件而言，如果是树形结构中的叶节点，它不能包含子控件，它的Controls属性就应为 EmptyControlCollection类型，假如用户调用了Controls的Add()方法，就会抛出异常。如果控件是树形结构中的枝节点，它 支持子控件，那么Controls属性就是ControlCollection类型。究竟是枝节点还是叶节点，决定权在于公共属性Controls：
public virtual ControlCollection Controls
{
      get
      {
             if (this._controls == null)
             {
                   this._controls = this.CreateControlCollection();
             }
             return this._controls;
      }
}

在属性的get访问器中，调用了protected方法CreateControlCollection()，它创建并返回了一个ControlCollection实例：
protected virtual ControlCollection CreateControlCollection()
{
     return new ControlCollection(this);
}

很明显，在Control基类实现Controls属性时，采用了Template Method模式,它推迟了ControlCollection的创建，将决定权交给了CreateControlCollection()方法。

如果我们需要定义一个控件，要求它不能管理子控件，就重写CreateControlCollection()方法，返回EmptyControlCollection对象：

protected override ControlCollection CreateControlCollection()
{
     return new EmptyControlCollection(this);
}
 
现在再回过头来看HtmlControl和HtmlContainerControl类。根据前面的分析，我们要求 HtmlContainerControl继承HtmlControl类，同时，HtmlContainerControl应为枝节点，能够管理子控件； HtmlControl则为叶节点，不支持子控件。通过引入ControlCollection类和其子类 EmptyControlCollection，以及Template Method模式后，这些类之间的关系与结构如下所示：

HtmlContainerControl继承了HtmlControl类，这两个类都重写了自己父类的protected方法 CreateControlCollection()。HtmlControl类，该方法返回EmptyControlCollection对象，使其成 为了不包含子控件的叶节点；HtmlContainerControl类中，该方法则返回ControlCollection对象，从而被赋予了管理子控 件的能力，成为了枝节点：
public abstract class HtmlControl : Control, IAttributeAccessor
{
        // Methods
 protected override ControlCollection CreateControlCollection()
 {
            return new EmptyControlCollection(this);
 }
}
public abstract class HtmlContainerControl : HtmlControl
{
       // Methods
 protected override ControlCollection CreateControlCollection()
 {
            return new ControlCollection(this);
 }
}

HtmlControl和HtmlContainerControl类均为抽象类。要定义它们的子类，如果不重写其父类的 CreateControlCollection()方法，那么它们的Controls属性，就与父类完全一致。例如HtmlImage控件继承自 HtmlControl类，该控件不能添加子控件；而HtmlForm控件则继承自HtmlContainerControl类，显然，HtmlForm 控件是支持添加子控件的操作的。

.Net的控件设计采用Composite模式的“复合方式”，较好地将控件的透明性与安全性结合起来，它的特点是：

1、在统一接口中消除了Add()、Remove()等子控件的管理方法，而由ControlCollection类实现，同时通过EmptyControlCollection类保障了控件进一步的安全；
2、控件能否管理子控件，不由继承的层次决定；而是通过重写CreateControlCollection()方法，由Controls属性的真正类型来决定。

如此一来，要定义自己的控件就更加容易。我们可以任意地扩展自己的控件类。不管继承自Control，还是HtmlControl或 HtmlContainerControl，都可以轻松地定义出具有枝节点或叶节点属性的新控件。如果有新的需求要求改变管理子控件的方式，我们还可以定 义继承自ControlCollection的类，并在控件类的方法CreateControlCollection()中创建并返回它的实例。

设计模式之Composite(组合)

板桥里人 http://www.jdon.com 2002/04/27（转载请保留）

Composite模式定义:
将对象以树形结构组织起来,以达成“部分－整体” 的层次结构，使得客户端对单个对象和组合对象的使用具有一致性.

Composite比较容易理解，想到Composite就应该想到树形结构图。组合体内这些对象都有共同接口,当组合体一个对象的方法被调用执行 时，Composite将遍历(Iterator)整个树形结构,寻找同样包含这个方法的对象并实现调用执行。可以用牵一动百来形容。

所以Composite模式使用到Iterator模式，和Chain of Responsibility模式类似。

Composite好处:
1.使客户端调用简单，客户端可以一致的使用组合结构或其中单个对象，用户就不必关系自己处理的是单个对象还是整个组合结构，这就简化了客户端代码。
2.更容易在组合体内加入对象部件. 客户端不必因为加入了新的对象部件而更改代码。

如何使用Composite?
首先定义一个接口或抽象类，这是设计模式通用方式了，其他设计模式对接口内部定义限制不多，Composite却有个规定，那就是要在接口内部定义一个用于访问和管理Composite组合体的对象们（或称部件Component）.

下面的代码是以抽象类定义，一般尽量用接口interface,

抽象类Equipment就是Component定义，代表着组合体类的对象们,Equipment中定义几个共同的方法。

Disk是组合体内的一个对象，或称一个部件，这个部件是个单独元素( Primitive)。
还有一种可能是，一个部件也是一个组合体，就是说这个部件下面还有'儿子'，这是树形结构中通常的情况，应该比较容易理解。现在我们先要定义这个组合体：

上面CompositeEquipment继承了Equipment,同时为自己里面的对象们提供了外部访问的方法,重载了Iterator,Iterator是Java的Collection的一个接口，是Iterator模式的实现.

我们再看看CompositeEquipment的两个具体类:盘盒Chassis和箱子Cabinet，箱子里面可以放很多东西，如底板，电源盒，硬盘盒等；盘盒里面可以放一些小设备，如硬盘 软驱等。无疑这两个都是属于组合体性质的。

至此我们完成了整个Composite模式的架构。

我们可以看看客户端调用Composote代码:

Cabinet cabinet=new Cabinet("Tower");

Chassis chassis=new Chassis("PC Chassis");
//将PC Chassis装到Tower中 (将盘盒装到箱子里)
cabinet.add(chassis);
//将一个10GB的硬盘装到 PC Chassis (将硬盘装到盘盒里)
chassis.add(new Disk("10 GB"));

//调用 netPrice()方法;
System.out.println("netPrice="+cabinet.netPrice());
System.out.println("discountPrice="+cabinet.discountPrice());

上面调用的方法netPrice()或discountPrice()，实际上Composite使用Iterator遍历了整个树形结构,寻找同样包含这个方法的对象并实现调用执行.

Composite是个很巧妙体现智慧的模式，在实际应用中，如果碰到树形结构，我们就可以尝试是否可以使用这个模式。

以论坛为例，一个版(forum)中有很多帖子(message),这些帖子有原始贴，有对原始贴的回应贴，是个典型的树形结构，那么当然可以使用Composite模式，那么我们进入Jive中看看，是如何实现的.

Jive解剖
在Jive中 ForumThread是ForumMessages的容器container(组合体).也就是说，ForumThread类似我们上例中的 CompositeEquipment.它和messages的关系如图：
[thread]
　　 |- [message]
　　 |- [message]
　　 　　 |- [message]
　　 　　 |- [message]
　　 　　 　　 |- [message]

我们在ForumThread看到如下代码：

类似CompositeEquipment, 提供用于访问自己组合体内的部件方法: 增加 删除 遍历.

结合我的其他模式中对Jive的分析，我们已经基本大体理解了Jive论坛体系的框架，如果你之前不理解设计模式，而直接去看Jive源代码，你肯定无法看懂。

:)

　类适配器：

　对象适配器：

使用Java的抽象类时，就经常会使用到Template模式,因此Template模式使用很普遍.而且很容易理解和使用。

在上例中,我们希望重复执行benchmark()操作,但是对benchmark()的具体内容没有说明,而是延迟到其子类中描述:

至此,Template模式已经完成,是不是很简单?

我们称repeat方法为模板方法， 它其中的benchmark()实现被延迟到子类MethodBenchmark中实现了，

看看如何使用:

Benchmark operation = new MethodBenchmark();
long duration = operation.repeat(Integer.parseInt(args[0].trim()));
System.out.println("The operation took " + duration + " milliseconds");

也许你以前还疑惑抽象类有什么用,现在你应该彻底明白了吧? 至于这样做的好处,很显然啊,扩展性强,以后Benchmark内容变化,我只要再做一个继承子类就可以,不必修改其他应用代码.

Command定义
n 将来自客户端的请求传入一个对象，无需了解这个请求激活的 动作或有关接受这个请求的处理细节。

这是一种两台机器之间通讯联系性质的模式，类似传统过程语 言的 CallBack功能。

优点：
解耦了发送者和接受者之间联系。 发送者调用一个操作，接受者接受请求执行相应的动作，因为使用Command模式解耦，发送者无需知道接受者任何接口。

不少Command模式的代码都是针对图形界面的,它实际就是菜单命令,我们在一个下拉菜单选择一个命令时,然后会执行一些动作.

将 这些命令封装成在一个类中,然后用户(调用者)再对这个类进行操作,这就是Command模式,换句话说,本来用户(调用者)是直接调用这些命令的,如菜 单上打开文档(调用者),就直接指向打开文档的代码,使用Command模式,就是在这两者之间增加一个中间者,将这种直接关系拗断,同时两者之间都隔 离,基本没有关系了.

显然这样做的好处是符合封装的特性,降低耦合度,Command是将对行为进行封装的典型模式,Factory是将创建进行封装的模式,
从Command模式,我也发现设计模式一个"通病":好象喜欢将简单的问题复杂化, 喜欢在不同类中增加第三者,当然这样做有利于代码的健壮性 可维护性 还有复用性.

如何使用?
具体的Command模式代码各式各样,因为如何封装命令,不同系统,有不同的做法.下面事例是将命令封装在一个Collection的List中,任何 对象一旦加入List中,实际上装入了一个封闭的黑盒中,对象的特性消失了,只有取出时,才有可能模糊的分辨出:

按照通常做法,我们就可以直接调用这三个Command,但是使用Command模式,我们要将他们封装起来,扔到黑盒子List里去:

这三个命令进入List中后,已经失去了其外表特征,以后再取出,也可能无法分辨出谁是Engineer 谁是Programmer了,看下面客户端如何调用Command模式:

由此可见,调用者基本只和接口打交道,不合具体实现交互,这也体现了一个原则,面向接口编程,这样,以后增加第四个具体命令时,就不必修改调用者TestCommand中的代码了.

理解了上面的代码的核心原理,在使用中,就应该各人有自己方法了,特别是在如何分离调用者和具体命令上,有很多实现方法,上面的代码是使用"从List过一遍"的做法.这种做法只是为了演示.

使用Command模式的一个好理由还因为它能实现Undo功能.每个具体命令都可以记住它刚刚执行的动作,并且在需要时恢复.

Command模式在界面设计中应用广泛.Java的Swing中菜单命令都是使用Command模式,由于Java在界面设计的性能上还有欠缺,因此界面设计具体代码我们就不讨论,网络上有很多这样的示例.

参考:
http://www.patterndepot.com/put/8/command.pdf

http://www.javaworld.com/javaworld/javatips/jw-javatip68.html

在大学的数据结构这门课上，树是最重要的章节之一。还记得树是怎么定义的吗？树 (Tree) 是 n(n≥0) 个结点的有限集 T ， T 为空时称为空树，否则它满足如下两个条件：

(1)    有且仅有一个特定的称为根 (Root) 的结点；

(2)   其余的结点可分为 m(m≥0) 个互不相交的子集 Tl ， T2 ， … ， Tm ，其中每个子集本身又是一棵树，并称其为根的子树 (SubTree) 。

上面给出的递归定义刻画了树的固有特性：一棵非空树是由若干棵子树构成的，而子树又可由若干棵更小的子树构成。而这里的子树可以是叶子也可以是分支。

今天要学习的组合模式就是和树型结构以及递归有关系。

二、 定义与结构

组合 (Composite) 模式的其它翻译名称也很多，比如合成模式、树模式等等。在《设计模式》一书中给出的定义是：将对象以树形结构组织起来，以达成 “ 部分－整体 ” 的层次结构，使得客户端对单个对象和组合对象的使用具有一致性。

从定义中可以得到使用组合模式的环境为： 在设计中想表示对象的 “ 部分 － 整体 ” 层次结构；希望用户忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象。

看下组合模式的组成。

1)         抽象构件角色 Component ：它为组合中的对象声明接口，也可以为共有接口实现缺省行为。

2)       树叶构件角色 Leaf ：在组合中表示叶节点对象 —— 没有子节点，实现抽象构件角色声明的接口。

3)       树枝构件角色 Composite ：在组合中表示分支节点对象 —— 有子节点，实现抽象构件角色声明的接口；存储子部件。

下图为组合模式的类图表示。

如图所示：一个 Composite 实例可以像一个简单的 Leaf 实例一样，可以把它传递给任何使用 Component 的方法或者对象，并且它表现的就像是一个 Leaf 一样。

可以看出来，使用组合模式使得这个设计结构非常灵活，在下面的例子中会得到进一步的印证。

三、 安全性与透明性

组合模式中必须提供对子对象的管理方法，不然无法完成对子对象的添加删除等等操作，也就失去了灵活性和扩展性。但是管理方法是在 Component 中就声明还是在 Composite 中声明呢？

一种方式是在 Component 里面声明所有的用来管理子类对象的方法，以达到 Component 接口的最大化（如下图所示）。目的就是为了使客户看来在接口层次上树叶和分支没有区别 —— 透明性。但树叶是不存在子类的，因此 Component 声明的一些方法对于树叶来说是不适用的。这样也就带来了一些安全性问题。

另一种方式就是只在 Composite 里面声明所有的用来管理子类对象的方法（如下图所示）。这样就避免了上一种方式的安全性问题，但是由于叶子和分支有不同的接口，所以又失去了透明性。

    《设计模式》一书认为：在这一模式中，相对于安全性，我们比较强调透明性。对于第一种方式中叶子节点内不需要的方法可以使用空处理或者异常报告的方式来解决。

四、 举例

这里以 JUnit 中的组合模式的应用为例（JUnit入门）。

JUnit 是一个单元测试框架，按照此框架下的规范来编写测试代码，就可以使单元测试自动化。为了达到“自动化”的目的， JUnit 中定义了两个概念： TestCase 和 TestSuite 。 TestCase 是对一个类或者 jsp 等等编写的测试类；而 TestSuite 是一个不同 TestCase 的集合，当然这个集合里面也可以包含 TestSuite 元素，这样运行一个 TestSuite 会将其包含的 TestCase 全部运行。

然而在真实运行测试程序的时候，是不需要关心这个类是 TestCase 还是 TestSuite ，我们只关心测试运行结果如何。这就是为什么 JUnit 使用组合模式的原因。

JUnit 为了采用组合模式将 TestCase 和 TestSuite 统一起来，创建了一个 Test 接口来扮演抽象构件角色，这样原来的 TestCase 扮演组合模式中树叶构件角色，而 TestSuite 扮演组合模式中的树枝构件角色。下面将这三个类的有关代码分析如下：

//Test 接口 —— 抽象构件角色

public interface Test {

       /**

        * Counts the number of test cases that will be run by this test.

        */

       public abstract int countTestCases();

       /**

        * Runs a test and collects its result in a TestResult instance.

        */

       public abstract void run(TestResult result);

}

//TestSuite 类的部分有关源码 ——Composite 角色，它实现了接口 Test

public class TestSuite implements Test {

// 用了较老的 Vector 来保存添加的 test

       private Vector fTests= new Vector(10);

       private String fName;

       …… 

/**

        * Adds a test to the suite.

        */

       public void addTest(Test test) {          

// 注意这里的参数是 Test 类型的。这就意味着 TestCase 和 TestSuite 以及以后实现 Test 接口的任何类都可以被添加进来

              fTests.addElement(test);

       }

       ……

       /**

        * Counts the number of test cases that will be run by this test.

        */

       public int countTestCases() {

              int count= 0;

              for (Enumeration e= tests(); e.hasMoreElements(); ) {

                     Test test= (Test)e.nextElement();

                     count= count + test.countTestCases();

              }

              return count;

       }

       /**

        * Runs the tests and collects their result in a TestResult.

        */

       public void run(TestResult result) {

              for (Enumeration e= tests(); e.hasMoreElements(); ) {

                    if (result.shouldStop() )

                           break;

                     Test test= (Test)e.nextElement();
                           //关键在这个方法上面

                     runTest(test, result);

              }

       }
            //这个方法里面就是递归的调用了，至于你的Test到底是什么类型的只有在运行的时候得知
            public void runTest(Test test, TestResult result) {
                   test.run(result);
            }

……

}

//TestCase 的部分有关源码 ——Leaf 角色，你编写的测试类就是继承自它

public abstract class TestCase extends Assert implements Test {

       ……

       /**

        * Counts the number of test cases executed by run(TestResult result).

        */

       public int countTestCases() {

              return 1;

       }

/**

        * Runs the test case and collects the results in TestResult.

        */

       public void run(TestResult result) {

              result.run(this);

       }

……

}

       可以看出这是一个偏重安全性的组合模式。因此在使用TestCase和TestSuite时，不能使用Test来代替。

五、 优缺点

从上面的举例中可以看到，组合模式有以下优点：

1)         使客户端调用简单，客户端可以一致的使用组合结构或其中单个对象，用户就不必关心自己处理的是单个对象还是整个组合结构，这就简化了客户端代码。

2)       更容易在组合体内加入对象部件 . 客户端不必因为加入了新的对象部件而更改代码。这一点符合开闭原则的要求，对系统的二次开发和功能扩展很有利！

当然组合模式也少不了缺点：组合模式不容易限制组合中的构件。

六、 总结

组合模式是一个应用非常广泛的设计模式，在前面已经介绍过的解释器模式、享元模式中都是用到了组合模式。它本身比较简单但是很有内涵，掌握了它对你的开发设计有很大的帮助。

这是一个很简单的模式，却被非常广泛的使用。之所以简单是因为在这个模式中仅仅使用到了继承关系。

继承关系由于自身的缺陷，被专家们扣上了 “ 罪恶 ” 的帽子。 “ 使用委派关系代替继承关系 ” ， “ 尽量使用接口实现而不是抽象类继承 ” 等等专家警告，让我们这些菜鸟对继承 “ 另眼相看 ” 。

其实，继承还是有很多自身的优点所在。只是被大家滥用的似乎缺点更加明显了。合理的利用继承关系，还是能对你的系统设计起到很好的作用的。而模板方法模式就是其中的一个使用范例。

二、 定义与结构

GOF 给模板方法（ Template Method ）模式定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。这里的算法的结构，可以理解为你根据需求设计出来的业务流程。特定的步骤就是指那些可能在内容上存在变数的环节。

可以看出来，模板方法模式也是为了巧妙解决变化对系统带来的影响而设计的。使用模板方法使系统扩展性增强，最小化了变化对系统的影响。这一点，在下面的举例中可以很明显的看出来。

来看下这个简单模式的结构吧：

1)         AbstractClass （抽象类）：定义了一到多个的抽象方法，以供具体的子类来实现它们；而且还要实现一个模板方法，来定义一个算法的骨架。该模板方法不仅调用前面的抽象方法，也可以调用其他的操作，只要能完成自身的使命。

2)         ConcreteClass （具体类）：实现父类中的抽象方法以完成算法中与特定子类相关的步骤。

下面是模板方法模式的结构图。直接把《设计模式》上的图拿过来用下：

三、 举例

还是在我刚刚分析完源码的 JUnit 中找个例子吧。 JUnit 中的 TestCase 以及它的子类就是一个模板方法模式的例子。在 TestCase 这个抽象类中将整个测试的流程设置好了，比如先执行 Setup 方法初始化测试前提，在运行测试方法，然后再 TearDown 来取消测试设置。但是你将在 Setup 、 TearDown 里面作些什么呢？鬼才知道呢！！因此，而这些步骤的具体实现都延迟到子类中去，也就是你实现的测试类中。

来看下相关的源代码吧。

这是 TestCase 中，执行测试的模板方法。你可以看到，里面正像前面定义中所说的那样，它制定了“算法”的框架——先执行 setUp 方法来做下初始化，然后执行测试方法，最后执行 tearDown 释放你得到的资源。

public void runBare() throws Throwable {

       setUp();

       try {

              runTest();

       }

       finally {

              tearDown();

       }

}

这 就是上面使用的两个方法。与定义中不同的是，这两个方法并没有被实现为抽象方法，而是两个空的无为方法（被称为钩子方法）。这是因为在测试中，我们并不是 必须要让测试程序使用这两个方法来初始化和释放资源的。如果是抽象方法，则子类们必须给它一个实现，不管用到用不到。这显然是不合理的。使用钩子方法，则 你在需要的时候，可以在子类中重写这些方法。

protected void setUp() throws Exception {

}

protected void tearDown() throws Exception {

}

四、 适用情况

根据上面对定义的分析，以及例子的说明，可以看出模板方法适用于以下情况：

1)         一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。

2)         各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。其实这可以说是一种好的编码习惯了。

3)         控制子类扩展。模板方法只在特定点调用操作，这样就只允许在这些点进行扩展。比如上面 runBare （）方法就只在 runTest 前面适用 setUp 方法。如果你不愿子类来修改你的模板方法定义的框架，你可以采用两种方式来做：一是在 API 中不体现出你的模板方法；二、将你的模板方法置为 final 就可以了。

       可以看出，使用模板方法模式可以将代码的公共行为提取出来，达到复用的目的。而且，在模板方法模式中，是由父类的模板方法来控制子类中的具体实现。这样你在实现子类的时候，根本不需要对业务流程有太多的了解。

五、 总结

一、 引子

门面模式是非常简单的设计模式。

二、 定义与结构

门面模式（ facade ）又称外观模式。 GOF 在《设计模式》一书中给出如下定义：为子系统中的一组接口提供一个一致的界面， Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

定义中提到的子系统是指在设计中为了降低复杂性根据一定的规则（比如业务、功能），对系统进行的划分。子系统中封装有一些类。客户程序在使用子系统的时候，可能会像下图一样零乱。

在上面的实现方法中，客户类紧紧地依赖在子系统的实现上。子系统发生的变化，很可能要影响到客户类的调用。而且子系统在不断优化、可重用化的重构路上，会产生更多更小的类。这对使用子系统的客户类来说要完成一个工作流程，似乎要记住的接口太多了。

门面模式就是为了解决这种问题而产生的。看看使用了门面模式后的图：

这样就减少了客户程序和子系统之间的耦合，增加了可维护性。

很明显，门面模式有三个角色组成：

1)         门面角色（ facade ）：这是门面模式的核心。它被客户角色调用，因此它熟悉子系统的功能。它内部根据客户角色已有的需求预定了几种功能组合。

2)         子系统角色：实现了子系统的功能。对它而言， façade 角色就和客户角色一样是未知的，它没有任何 façade 角色的信息和链接。

3)         客户角色：调用 façade 角色来完成要得到的功能。

三、 举例

Facade 一个典型应用就是进行数据库连接。一般我们在每一次对数据库进行访问，都要进行以下操作：先得到 connect 实例，然后打开 connect 获得连接，得到一个 statement ，执行 sql 语句进行查询，得到查询结果集。

       我们可以将这些步骤提取出来，封装在一个类里面。这样，每次执行数据库访问只需要将必要的参数传递到这个类中就可以了。

       有兴趣可以在你正在进行的系统中实现一下。

四、 使用环境和优点

《设计模式》给出了门面模式的使用环境：

1)         当你要为一个复杂子系统提供一个简单接口时。在上面已经描述了原因。

2)         客户程序与抽象类的实现部分之间存在着很大的依赖性。引入 facade 将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性（上面也提到了）。

3)         当你需要构建一个层次结构的子系统时，使用 facade 模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过 facade 进行通讯，从而简化了它们之间的依赖关系。

以下是它的优点：

1)         它对客户屏蔽子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。

2)         它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。 Facade 模式有助于建立层次结构系统，也有助于对对象之间的依赖关系分层。 Facade 模式可以消除复杂的循环依赖关系。这一点在客户程序与子系统是分别实现的时候尤为重要。在大型软件系统中降低编译依赖性至关重要。在子系统类改变时，希望尽量减少重编译工作以节省时间。用 Facade 可以降低编译依赖性，限制重要系统中较小的变化所需的重编译工作。 Facade 模式同样也有利于简化系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。

3)         如果应用需要，它并不限制它们使用子系统类。因此你可以让客户程序在系统易用性和通用性之间加以选择。

  五、 java 中的门面模式

先来想想门面模式和我们已经讲过的哪个模式相像？答案就是 抽象工厂 模式 。两者虽然在分类上有所区别，但是都是为了方便客户程序的使用而建立。两者的不同应该在于门面模式不仅方便了客户的使用，而且隐藏了不该让客户知道的类（这些类仅仅为子系统的其他类服务）。

但是在 java 语言中提供的包的概念已经能够很好的解决上面门面模式提到的问题。你可以把一个子系统放在一个包里面，里面要提供给外面访问的类定义为 public ，而不该公布的类就可以设计为非 public 。

因此，在一定程度上，门面模式在 java 中基本上可以不使用了。

标准的门面模式虽然可以不再使用，但是这种提供一个中间类或者中间方法来方便客户程序使用的思想应该值得我们来实践的

六、 总结  

门面模式从整体来看，给我的感觉是，它对于使两层之间的调用粗颗粒化很有帮助，避免了大量细颗粒度的访问。这和 SOA 中的一些观点是相同的。

   门面模式大体介绍完了。请指正：）

门面模式从整体来看，给我的感觉是，它对于使两层之间的调用粗颗粒化很有帮助，避免了大量细颗粒度的访问。这和 SOA 中的一些观点是相同的。

   门面模式大体介绍完了。请指正：）

单例模式是设计模式中使用很频繁的一种模式，在各种开源框架、应用系统中多有应用，在我前面的几篇文章中也结合其它模式使用到了单例模式。这里我们就单例模式进行系统的学习。并对有人提出的 “ 单例模式是邪恶的 ” 这个观点进行了一定的分析。

二、 定义与结构

单例模式又叫做单态模式或者单件模式。在 GOF 书中给出的定义为：保证一个类仅有一个实例，并提供一个访问它的全局访问点。单例模式中的 “ 单例 ” 通常用来代表那些本质上具有唯一性的系统组件（或者叫做资源）。比如文件系统、资源管理器等等。

单 例模式的目的就是要控制特定的类只产生一个对象，当然也允许在一定情况下灵活的改变对象的个数。那么怎么来实现单例模式呢？一个类的对象的产生是由类构造 函数来完成的，如果想限制对象的产生，就要将构造函数变为私有的（至少是受保护的），使得外面的类不能通过引用来产生对象；同时为了保证类的可用性，就必 须提供一个自己的对象以及访问这个对象的静态方法。

现在对单例模式有了大概的了解了吧，其实单例模式在实现上是非常简单的 —— 只有一个角色，而客户则通过调用类方法来得到类的对象。

放上一个类图吧，这样更直观一些：

单例模式可分为有状态的和无状态的。有状态的单例对象一般也是可变的单例对象， 多个单态对象在一起就可以作为一个状态仓库一样向外提供服务。没有状态的单例对象也就是不变单例对象，仅用做提供工具函数。

三、 实现

在单例模式的实现上有几种不同的方式，我在这里将一一讲解。先来看一种方式，它在《 java 与模式》中被称为饿汉式。

public class Singleton {

// 在自己内部定义自己一个实例

// 注意这是 private 只供内部调用

private static Singleton instance = new Singleton();

// 如上面所述，将构造函数设置为私有

private Singleton(){

} 　

// 静态工厂方法， 提供了一个供外部访问得到对象 的静态方法　　
　　 public static Singleton getInstance() {
　　　　 return instance; 　　
　　 }
}

       下面这种方式被称为懒汉式： P

public class Singleton {

       // 和上面有什么不同？

private static Singleton instance = null;

// 设置为私有的构造函数

private Singleton(){

} 　

// 静态工厂方法

public static synchronized Singleton getInstance() {

// 这个方法比上面有所改进
　　        if (instance==null)

              instance ＝ new Singleton();
　　        return instance; 　　

}

}

先让我们来比较一下这两种实现方式。

首先他们的构造函数都是私有的，彻底断开了使用构造函数来得到类的实例的通道，但是这样也使得类失去了多态性（大概这就是为什么有人将这种模式称作单态模式）。  

在第二种方式中，对静态工厂方法进行了同步处理，原因很明显——为了防止多线程环境中产生多个实例；而在第一种方式中则不存在这种情况。

       在第二种方式中将类对自己的实例化延迟到第一次被引用的时候。而在第一种方式中则是在类被加载的时候实例化，这样多次加载会照成多次实例化。但是第二种方式由于使用了同步处理，在反应速度上要比第一种慢一些。

       在 《 java 与模式》书中提到，就 java 语言来说，第一种方式更符合 java 语言本身的特点。

       以 上两种实现方式均失去了多态性，不允许被继承。还有另外一种灵活点的实现，将构造函数设置为受保护的，这样允许被继承产生子类。这种方式在具体实现上又有 所不同，可以将父类中获得对象的静态方法放到子类中再实现；也可以在父类的静态方法中进行条件判断来决定获得哪一个对象；在 GOF 中认为最好的一种方式是维护一张存有对象和对应名称的注册表（可以使用 HashMap 来实现）。下面的实现参考《 java 与模式》采用带有注册表的方式。

import java.util.HashMap;

public class Singleton

{

// 用来存放对应关系

       private static HashMap sinRegistry = new HashMap();

       static private Singleton s = new Singleton();

       // 受保护的构造函数

       protected Singleton()

       {}

       public static Singleton getInstance(String name)

       {

              if(name == null)

                     name = "Singleton";

              if(sinRegistry.get(name)==null)

              {

                     try{

                            sinRegistry.put(name , Class.forName(name).newInstance());

                     }catch(Exception e)

                     {

                            e.printStackTrace();

                     }     

              }

              return (Singleton)(sinRegistry.get(name)); 

       }

       public void test()

       {

              System.out.println("getclasssuccess!");      

       }

}

public class SingletonChild1 extends Singleton

{

       public SingletonChild1(){}

       static    public SingletonChild1 getInstance()

       {

              return (SingletonChild1)Singleton.getInstance("SingletonChild1");     

       }

       public void test()

       {

              System.out.println("getclasssuccess111!"); 

       }

}

在 java 中子类的构造函数的范围不能比父类的小，所以可能存在不守规则的客户程序使用其构造函数来产生实例。

四、单例模式邪恶论

看这题目也许有点夸张，不过这对初学者是一个很好的警告。单例模式在 java 中的使用存在很多陷阱和假象，这使得没有意识到单例模式使用局限性的你在系统中布下了隐患……

其实这个问题早在 2001 年的时候就有人在网上系统的提出来过，我在这里只是老生常谈了。但是对于大多的初学者来说，可能这样的观点在还很陌生。下面我就一一列举出单例模式在 java 中存在的陷阱。

多个虚拟机

当系统中的单例类被拷贝运行在多个虚拟机下的时候，在每一个虚拟机下都可以创建一个实例对象。在使用了 EJB 、 JINI 、 RMI 技术的分布式系统中，由于中间件屏蔽掉了分布式系统在物理上的差异，所以对你来说，想知道具体哪个虚拟机下运行着哪个单例对象是很困难的。

因此，在使用以上分布技术的系统中，应该避免使用存在状态的单例模式，因为一个有状态的单例类，在不同虚拟机上，各个单例对象保存的状态很可能是不一样的，问题也就随之产生。而且在 EJB 中不要使用单例模式来控制访问资源，因为这是由 EJB 容器来负责的。在其它的分布式系统中，当每一个虚拟机中的资源是不同的时候，可以考虑使用单例模式来进行管理。

多个类加载器

当存在多个类加载器加载类的时候，即使它们加载的是相同包名，相同类名甚至每个字节都完全相同的类，也会被区别对待的。因为不同的类加载器会使用不同的命名空间（ namespace ）来区分同一个类。因此，单例类在多加载器的环境下会产生多个单例对象。

也许你认为出现多个类加载器的情况并不是很多。其实多个类加载器存在的情况并不少见。在很多 J2EE 服务器上允许存在多个 servlet 引擎，而每个引擎是采用不同的类加载器的；浏览器中 applet 小程序通过网络加载类的时候，由于安全因素，采用的是特殊的类加载器，等等。

       这种情况下，由状态的单例模式也会给系统带来隐患。因此除非系统由协调机制，在一般情况下不要使用存在状态的单例模式。

       错误的同步处理

       在使用上面介绍的懒汉式单例模式时，同步处理的恰当与否也是至关重要的。不然可能会达不到得到单个对象的效果，还可能引发死锁等错误。因此在使用懒汉式单例模式时一定要对同步有所了解。不过使用饿汉式单例模式就可以避免这个问题。

       子类破坏了对象控制

       在上一节介绍最后一种扩展性较好的单例模式实现方式的时候，就提到，由于类构造函数变得不再私有，就有可能失去对对象的控制。这种情况只能通过良好的文档来规范。

       串行化（可序列化）

为了使一个单例类变成可串行化的，仅仅在声明中添加“ implements Serializable ”是不够的。因为一个串行化的对象在每次返串行化的时候，都会创建一个新的对象，而不仅仅是一个对原有对象的引用。为了防止这种情况，可以在单例类中加入 readResolve 方法。 关于这个方法的具体情况请参考《 Effective Java 》一书第 57 条建议。

其实对象的串行化并不仅局限于上述方式，还存在基于 XML 格式的对象串行化方式。这种方式也存在上述的问题，所以在使用的时候要格外小心。

       上面罗列了一些使用单例模式时可能会遇到的问题。而且这些问题都和 java 中的类、线程、虚拟机等基础而又复杂的概念交织在一起，你如果稍不留神……。但是这并不代表着单例模式就一无是处，更不能一棒子将其打死。它还是不可缺少的一种基础设计模式，它对一些问题提供了非常有效的解决方案，在 java 中你完全可以把它看成编码规范来学习，只是使用的时候要考虑周全些就可以了。

五、 题外话

抛开单例模式，使用下面一种简单的方式也能得到单例，而且如果你确信此类永远是单例的，使用下面这种方式也许更好一些。

public static final Singleton INSTANCE = new Singleton();

而使用单例模式提供的方式，这可以在不改变 API 的情况下，改变我们对单例类的具体要求。

六、 总结

装饰模式？肯定让你想起又黑又火的家庭装修来。其实两者在道理上还是有很多相像的地方。家庭装修无非就是要掩盖住原来实而不华的墙面，抹上一层华而不实的涂料，让生活多一点色彩。而墙还是那堵墙，他的本质一点都没有变，只是多了一层外衣而已。

那设计模式中的装饰模式，是什么样子呢？

二、定义与结构

装饰模式（ Decorator ）也叫包装器模式（ Wrapper ）。 GOF 在《设计模式》一书中给出的定义为：动态地给一个对象添加一些额外的职责。就增加功能来说， Decorator 模式相比生成子类更为灵活。

       让我们来理解一下这句话。我们来设计 “ 门 ” 这个类。假设你根据需求为 “ 门 ” 类作了如下定义：

现在，在系统的一个地方需要一个能够报警的 Door ，你来怎么做呢？你或许写一个 Door 的子类 AlarmDoor ，在里面添加一个子类独有的方法 alarm() 。嗯，那在使用警报门的地方你必须让客户知道使用的是警报门，不然无法使用这个独有的方法。而且，这个还违反了 Liskov 替换原则。

也许你要说，那就把这个方法添加到 Door 里面，这样不就统一了？但是这样所有的门都必须有警报，至少是个 “ 哑巴 ” 警报。而当你的系统仅仅在一两个地方使用了警报门，这明显是不合理的 —— 虽然可以使用缺省适配器来弥补一下。

       这时候，你可以考虑采用装饰模式来给门动态的添加些额外的功能。

       下面我们来看看装饰模式的组成，不要急着去解决上面的问题，到了下面自然就明白了！

1)         抽象构件角色（ Component ）：定义一个抽象接口，以规范准备接收附加责任的对象。

2)         具体构件角色 (Concrete Component) ：这是被装饰者，定义一个将要被装饰增加功能的类。

3)         装饰角色 (Decorator) ：持有一个构件对象的实例，并定义了抽象构件定义的接口。

4)         具体装饰角色 (Concrete Decorator) ：负责给构件添加增加的功能。

看下装饰模式的类图：

图中 ConcreteComponent 可能继承自其它的体系，而为了实现装饰模式，他还要实现 Component 接口。整个装饰模式的结构是按照组合模式来实现的，但是注意两者的目的是截然不同的（关于两者的不同请关注我以后的文章）。

三、举例

这个例子还是来自我最近在研究的 JUnit ，如果你对 JUnit 还不太了解，可以参考 《 JUnit入门》 、 《 JUnit源码分析（一）》 、 《 JUnit源码分析（二）》 、 《 JUnit源码分析（三）》 。不愧是由 GoF 之一的 Erich Gamma 亲自开发的，小小的东西使用了 N 种的模式在里面。下面就来看看 JUnit 中的装饰模式。

       在 JUnit 中， TestCase 是一个很重要的类，允许对其进行功能扩展。

       在 junit.extensions 包中， TestDecorator 、 RepeatedTest 便是对 TestCase 的装饰模式扩展。下面我们将它们和上面的角色对号入座。

       呵呵，看看源代码吧，这个来的最直接！

       // 这个就是抽象构件角色

       public interface Test {

       /**

        * Counts the number of test cases that will be run by this test.

        */

       public abstract int countTestCases();

       /**

        * Runs a test and collects its result in a TestResult instance.

        */

       public abstract void run(TestResult result);

}

// 具体构件对象，但是这里是个抽象类

public abstract class TestCase extends Assert implements Test {

       ……

       public int countTestCases() {

              return 1;

       }

       ……

       public TestResult run() {

              TestResult result= createResult();

              run(result);

              return result;

       }

       public void run(TestResult result) {

              result.run(this);

       }

       ……

}

// 装饰角色

public class TestDecorator extends Assert implements Test {

       // 这里按照上面的要求，保留了一个对构件对象的实例

       protected Test fTest;

       public TestDecorator(Test test) {

              fTest= test;

       }

       /**

        * The basic run behaviour.

        */

       public void basicRun(TestResult result) {

              fTest.run(result);

       }

       public int countTestCases() {

              return fTest.countTestCases();

       }

       public void run(TestResult result) {

              basicRun(result);

       }

       public String toString() {

              return fTest.toString();

       }

       public Test getTest() {

              return fTest;

       }

}

       // 具体装饰角色，这个类的增强作用就是可以设置测试类的执行次数

public class RepeatedTest extends  TestDecorator {

    private int fTimesRepeat;

    public RepeatedTest(Test test, int repeat) {

           super(test);

           if (repeat < 0)

                  throw new IllegalArgumentException("Repetition count must be > 0");

           fTimesRepeat= repeat;

    }

    // 看看怎么装饰的吧

    public int countTestCases() {

           return super.countTestCases()*fTimesRepeat;

    }

    public void run(TestResult result) {

           for (int i= 0; i < fTimesRepeat; i++) {

                  if (result.shouldStop())

                         break;

                  super.run(result);

           }

    }

    public String toString() {

           return super.toString()+"(repeated)";

    }

}

       使用的时候，就可以采用下面的方式：

TestDecorator test = new RepeatedTest(new TestXXX() , 3);

让我们在回想下上面提到的 “ 门 ” 的问题，这个警报门采用了装饰模式后，可以采用下面的方式来产生。

DoorDecorator alarmDoor = new AlarmDoor(new Door());

四、应用环境

       GOF 书中给出了以下使用情况：

1)         在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。

2)         处理那些可以撤消的职责。

3)         当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

来分析下 JUnit 的使用是属于哪种情况。首先实现了比静态继承更加灵活的方式，动态的增加功能。试想为 Test 的所有实现类通过继承来增加一个功能，意味着要添加不少的功能类似的子类，这明显是不太合适的。

而且，这就避免了高层的类具有太多的特征，比如上面提到的带有警报的抽象门类。

五、透明和半透明

       对于面向接口编程，应该尽量使客户程序不知道具体的类型，而应该对一个接口操作。这样就要求装饰角色和具体装饰角色要满足 Liskov 替换原则。像下面这样：

Component c = new ConcreteComponent();

Component c1 = new ConcreteDecorator(c);

JUnit 中就属于这种应用，这种方式被称为透明式。而在实际应用中，比如 java.io 中往往因为要对原有接口做太多的扩展而需要公开新的方法（这也是为了重用）。所以往往不能对客户程序隐瞒具体的类型。这种方式称为 “ 半透明式 ” 。

在 java.io 中，并不是纯装饰模式的范例，它是装饰模式、适配器模式的混合使用。

六、其它

采用 Decorator 模式进行系统设计往往会产生许多看上去类似的小对象，这些对象仅仅在他们相互连接的方式上有所不同，而不是它们的类或是它们的属性值有所不同。尽管对于那些了解这些系统的人来说，很容易对它们进行定制，但是很难学习这些系统，排错也很困难。这是 GOF 提到的装饰模式的缺点，你能体会吗？他们所说的小对象我认为是指的具体装饰角色。这是为一个对象动态添加功能所带来的副作用。

七、总结

还记得警匪片上，匪徒们是怎么配合实施犯罪的吗？一个团伙在进行盗窃的时候，总     有一两个人在门口把风——如果有什么风吹草动，则会立即通知里面的同伙紧急撤退。也许放风的人并不一定认识里面的每一个同伙；而在里面也许有新来的小弟不认识这个放风的。但是这没什么，这个影响不了他们之间的通讯，因为他们之间有早已商定好的暗号。

呵呵，上面提到的放风者、偷窃者之间的关系就是观察者模式在现实中的活生生的例子。

二、 定义与结构

观察者（ Observer ）模式又名发布 - 订阅（ Publish/Subscribe ）模式。 GOF 给观察者模式如下定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

在这里先讲一下面向对象设计的一个重要原则——单一职责原则。因此系统的每个对象应该将重点放在问题域中的离散抽象上。因此理想的情况下，一个对象只做一件事情。这样在开发中也就带来了诸多的好处：提供了重用性和维护性，也是进行重构的良好的基础。

因此几乎所有的设计模式都是基于这个基本的设计原则来的。观察者模式的起源我觉得应该是在 GUI 和业务数据的处理上，因为现在绝大多数讲解观察者模式的例子都是这一题材。但是观察者模式的应用决不仅限于此一方面。

下面我们就来看看观察者模式的组成部分。

1)         抽象目标角色（ Subject ）：目标角色知道它的观察者，可以有任意多个观察者观察同一个目标。并且提供注册和删除观察者对象的接口。目标角色往往由抽象类或者接口来实现。

2)         抽象观察者角色（ Observer ）：为那些在目标发生改变时需要获得通知的对象定义一个更新接口。抽象观察者角色主要由抽象类或者接口来实现。

3)         具体目标角色（ Concrete Subject ）：将有关状态存入各个 Concrete Observer 对象。当它的状态发生改变时 , 向它的各个观察者发出通知。

4)         具体观察者角色（ Concrete Observer ）：存储有关状态，这些状态应与目标的状态保持一致。实现 Observer 的更新接口以使自身状态与目标的状态保持一致。在本角色内也可以维护一个指向 Concrete Subject 对象的引用。

放上观察者模式的类图，这样能将关系清晰的表达出来。

       可以看得出来，在 Subject 这个抽象类中，提供了上面提到的功能，而且存在一个通知方法： notify 。还可以看出来 Subject 和 ConcreteSubject 之间可以说是使用了模板模式（这个模式真是简单普遍到一不小心就用到了）。

       这样当具体目标角色的状态发生改变，按照约定则会去调用通知方法，在这个方法中则会根据目标角色中注册的观察者名单来逐个调用相应的 update 方法来调整观察者的状态。这样观察者模式就走完了一个流程。

       在下面的例子中会更深刻的体验到这个流程的。

三、 举例

观察者模式是我在《 JUnit 源代码分析》中遗留的一个模式，因此这里将采用 JUnit 来作为例子。

JUnit 为用户提供了三种不同的测试结果显示界面，以后还可能会有其它方式的现实界面……。怎么才能将测试的业务逻辑和显示结果的界面很好的分离开？不用问，就是观察者模式！

下面我们来看看 JUnit 中观察者模式的使用代码：

// 下面是我们的抽象观察者角色， JUnit 是采用接口来实现的，这也是一般采用的方式。

// 可以看到这里面定义了四个不同的 update 方法，对应四种不同的状态变化

public interface TestListener {

       /**

        * An error occurred.

        */

       public void addError(Test test, Throwable t);

       /**

        * A failure occurred.

        */

       public void addFailure(Test test, AssertionFailedError t); 

       /**

        * A test ended.

        */

       public void endTest(Test test);

       /**

        * A test started.

        */

       public void startTest(Test test);

}

// 具体观察者角色，我们采用最简单的 TextUI 下的情况来说明（ AWT ， Swing 对于整天做 Web 应用的人来说，已经很陌生了）

public class ResultPrinter implements TestListener {

       // 省略好多啊，主要是显示代码

……

       // 下面就是实现接口 TestListener 的四个方法

       // 填充方法的行为很简单的说

       /**

        * @see junit.framework.TestListener#addError(Test, Throwable)

        */

       public void addError(Test test, Throwable t) {

              getWriter().print("E");

       }

       /**

        * @see junit.framework.TestListener#addFailure(Test, AssertionFailedError)

        */

       public void addFailure(Test test, AssertionFailedError t) {

              getWriter().print("F");

       }

       /**

        * @see junit.framework.TestListener#endTest(Test)

        */

       public void endTest(Test test) {

       }

       /**

        * @see junit.framework.TestListener#startTest(Test)

        */

       public void startTest(Test test) {

              getWriter().print(".");

              if (fColumn++ >= 40) {

                     getWriter().println();

                     fColumn= 0;

              }

       }

}

来看下我们的目标角色，随便说下，由于 JUnit 功能的简单，只有一个目标—— TestResult ，因此 JUnit 只有一个具体目标角色。

// 好长的代码，好像没有重点。去掉了大部分与主题无关的信息

// 下面只列出了当 Failures 发生时是怎么来通知观察者的

public class TestResult extends Object {

       // 这个是用来存放测试 Failures 的集合

protected Vector fFailures;

// 这个就是用来存放注册进来的观察者的集合

       protected Vector fListeners;

       public TestResult() {

              fFailures= new Vector();

              fListeners= new Vector();

       }

       /**

        * Adds a failure to the list of failures. The passed in exception

        * caused the failure.

        */

       public synchronized void addFailure(Test test, AssertionFailedError t) {

              fFailures.addElement(new TestFailure(test, t));

              // 下面就是通知各个观察者的 addFailure 方法

              for (Enumeration e= cloneListeners().elements(); e.hasMoreElements(); ) {

                     ((TestListener)e.nextElement()).addFailure(test, t);

              }

       }

       /**

        * 注册一个观察者

        */

       public synchronized void addListener(TestListener listener) {

              fListeners.addElement(listener);

       }

       /**

        * 删除一个观察者

        */

       public synchronized void removeListener(TestListener listener) {

              fListeners.removeElement(listener);

       }

       /**

        * 返回一个观察者集合的拷贝，当然是为了防止对观察者集合的非法方式操作了

     * 可以看到所有使用观察者集合的地方都通过它

        */

       private synchronized Vector cloneListeners() {

              return (Vector)fListeners.clone();

       }

       ……

}

嗯，观察者模式组成所需要的角色在这里已经全了。不过好像还是缺点什么……。呵呵，对！就是它们之间还没有真正的建立联系。在 JUnit 中是通过 TestRunner 来作的，而你在具体的系统中可以灵活掌握。

看一下 TestRunner 中的代码：

public class TestRunner extends BaseTestRunner {

       private ResultPrinter fPrinter;

public TestResult doRun(Test suite, boolean wait) {

// 就是在这里注册的

              result.addListener(fPrinter);

……

四、 使用情况

GOF 给出了以下使用观察者模式的情况：

1)         当一个抽象模型有两个方面 , 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。

2)         当对一个对象的改变需要同时改变其它对象 , 而不知道具体有多少对象有待改变。

3)         当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之 , 你不希望这些对象是紧密耦合的。

其实观察者模式同前面讲过的桥梁、策略有着共同的使用环境：将变化独立封装起来，以达到最大的重用和解耦。观察者与后两者不同的地方在于，观察者模式中的目标和观察者的变化不是独立的，而是有着某些联系。

五、 我推你拉

观 察者模式在关于目标角色、观察者角色通信的具体实现中，有两个版本。一种情况便是目标角色在发生变化后，仅仅告诉观察者角色“我变化了”；观察者角色如果 想要知道具体的变化细节，则就要自己从目标角色的接口中得到。这种模式被很形象的称为：拉模式——就是说变化的信息是观察者角色主动从目标角色中“拉”出 来的。

还有一种方法，那就是我目标角色“服务一条龙”，通知你发生变化的同时，通过一个参数将变化的细节传递到观察者角色中去。这就是“推模式”——管你要不要，先给你啦。

这两种模式的使用，取决于系统设计时的需要。如果目标角色比较复杂，并且观察者角色进行更新时必须得到一些具体变化的信息，则“推模式”比较合适。如果目标角色比较简单，则“拉模式”就很合适啦。

六、 总结

大概的介绍了下观察者模式。希望能对你有所帮助。

记得一年前，我开始陆陆续续在自己的 blog 上连载《深入浅出设计模式》。其内容无出经典巨著《设计模式》之右，仅仅偶有己见，但是它记录了我学习、思考和讲述设计模式的过程。一晃，距离写成最后一片设计模式的文章已有 3 月余，我却迟迟没有对设计模式做一个总结。心想，总不能虎头蛇尾吧，于是便有了这篇文章。

二、 回顾 23 种设计模式

先来回顾下这 23 种经典的设计模式吧，下图给出了 GOF 对它们的分类：

    图中从两个纬度将 23 种设计模式划分为六大类：创建型类模式、创建型对象模式、结构型类模式、结构型对象模式、行为型类模式、行为型对象模式。 GOF 对这 23 种模式的划分是有一定道理的，虽然人为的类型划分，说到底还是有些牵强，但是如 GOF 所说，它至少可以帮助记忆学习。

    被分为六大块的 23 种设计模式并不是割裂开来的，很多模式的使用往往是相生相伴的，像工厂与单例，装饰与组合等等。 GOF 给出了模式间的关系详细描述如下图：

    记得曾经不止一次有人问我：这模式和那模式感觉上一样啊，有什么区别啊。同样，在很多论坛上也充满了这样的疑问。其实这是很正常的，面向对象设计、编程所能使用的方式不外乎这几种：继承、组合、封装行为、利用多态等等，所以 23 种模式中翻来覆去的使用这几种方式，看起来当然是似曾相逢。有人曾留言给我，让我着重表述这些模式之间的区别与类似。我当时也许诺会在最后写一篇总结性的文章专门讨论这个话题，但是现在我不打算这样干了。

三、俯瞰全局、 追踪溯源

    什么是设计模式？ GOF 在书中如是说： 设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述； John Vlissides 曾说过：在设计模式中，仅有的、最重要的就是不断的反省；而我将它比作软件开发中经验积累出来的“公式”。

    通看这 23 种模式，就应了 Dennis DeBruler 曾说过的一句话：计算机科学是一门相信所有问题都可以通过多一个间接层（ indirection ）来解决的科学。在前面关于具体模式的文章中，我曾经不只一次的提到“中间层”。但是直到读到这句话，才使我跳出具体模式的束缚俯瞰全局。

    23 种模式似乎不再神奇，它们在解决问题上的思路是如此的相似——添加间接层。何止模式如此，正如 Dennis DeBruler 所言，我们所接触的很多技术都是采用这种手段，如： J2EE 的分层技术、重构等等。但是在具体操作上， 23 种模式中间接层的应用可大可小，无比灵活。观察者模式在动作触发端与动作执行端之间加入了目标角色层，解除了两端之间的耦合，巧妙地解决了一对多的关系；单例模式将构造方法私有化，并在使用者与构造方法之间添加一个获得唯一实例的静态方法，达到控制实例个数的目的。

    间接层应用如此广泛，得益于它能带来如下好处：共享逻辑（重用）、分离意图和实现（提高灵活性）、 隔 离变化（封装）、解耦等等。既然我们知道了间接层这么一回事，似乎我们可以不用知道设计模式也能做出像设计模式那样好的设计来。但是要记住，间接层应用过 于泛滥，则会过犹不及，它会导致简单问题复杂化、跳跃阅读难以理解等问题。那如何在设计中把握使用间接层的度呢？设计模式也许是很好的范例——你毕竟是站 在了巨人的肩上。

再深入一层细看，在设计模式中，广泛遵循了两条设计原则：面向接口编程，而不是实现；优先使用组合，而不是继承。这两条原则带来的好处，自然不用再说了。说到设计原则， 现在为人熟知的设计原则有很多，如： 单一职责原则（ SRP ）、开闭原则（ OCP ）、 Liskov 替换原则（ LSP ）、依赖倒置原则（ DIP ）和接口隔离原则（ ISP ）等等。这些原则的出现大多都早于设计模式，但同设计模式一样，是 OOD 过程中经验积累的结晶。它们在 23 种设计模式中都有体现，因此了解设计原则可以帮助你更好的分析和理解设计模式。

当然，这并不是说设计模式就是建立在设计原则的基础之上的。两者之间的关系是互相促进的。设计原则的诞生，也许会促成新的设计模式；设计模式的出现，也许会提炼出新的设计原则。

现在不禁要问，为什么使用设计模式。也许你的回答会是：提高设计的重用度、灵活性、可维护性等等。但是我认为更准确的回答应该是：解决系统设计中现有的问题。这便又回到了 GOF 给设计模式下的定义上了，绕了一个圈子，原来答案就这么简单。

这也就是我不想详细讲解各种模式区别的原因了，要解决的问题不一样就是它们之间最大的不同。如果还要详细分析，那它们都已写在 GOF 巨著中了——就是它们的定义、使用范围、优缺点等等。

四、 活学活用

是否我们必须按照这本巨著上描述的形式来使用设计模式呢？肯定不是这样的。数学物理公式在不同的条件下还会有不同的衍生式，何况这些在实践中总结的经验呢。

Martin 建 议根据问题的复杂性逐步的引入设计模式。这是个很好的建议，它避免你套用模式而带来了过度的设计，而这些过度的设计也许直到最后都派不上用场。比如，你的 系统中现在就仅有一个适配器角色，或者各个适配器角色没有什么共性，那么目标角色和适配器角色就可以合为一个，这样使得设计模式更加符合你系统的特性。

不 仅如此，做到设计模式的活学活用，我认为还要做到以解决问题为中心，将设计模式融合使用，避免为了设计而模式。当然这是建立在对各种设计模式了如指掌的情 况下。比如，有一段解析字符串的对象，而在使用它之前，还要做一些参数的判断等其他非解析操作，这时，你很快就会想起使用代理模式；但是这个代理提供的接 口可能有两三个（满足不同情形），而解析对象仅有一个接口，命名还不相同，这时你又想到了适配器模式。这时也许将两者融合成你独有的解决方案比笨拙的套用 两个模式好的多得多。

五、现在看模式

GOF 说过，这 23 种模式仅仅是对一般设计问题的总结。现在许多专有领域也开始出现了大量的设计模式，至少在我最了解的企业应用这个方向是这样的。其中有一部分模式仅仅是对 GOF 设计模式的再次包装。我们不妨叫 GOF 的 23 种设计模式为原始设计模式。

但是遗憾的是，越来越方便的框架支持，领域模型简化造成代码过程化、脚本化，使得在企业应用中很难看到原始设计模式的影子（当然还是可以看到遍地的命令模式）。比如： IoC 容器将单例、工厂、原型模式包装了起来，你现在需要做的仅仅是填写配置文件；框架集成了观察者、模版等等模式，你仅仅按照框架说明实现具体对象就可以了；过程化、脚本化的代码里面更不要提什么设计模式了！更甚者在 EJB 中单例模式差点变成了反模式。

原 始的设计模式没有用，过时了吗？如果你不甘心仅仅做一名代码组装工；想对你们部门的高手设计的框架品头论足的话，答案就是否定的。原始设计模式有很多的确 是难得一见了，但是了解它们绝对不是在浪费你的时间，它可以让你在解决问题的时候思路更开阔一些——它的思想比它的架势更重要。          

写在最后（其实应该在最前面）

工厂模式在《 Java 与模式》中分为三类：
      1 ）简单工厂模式（ Simple Factory ）

2 ）工厂方法模式（ Factory Method ）

3 ）抽象工厂模式（ Abstract Factory ）
       这三种模式从上到下逐步抽象，并且更具一般性。
       GOF 在《设计模式》一书中将工厂模式分为两类：工厂方法模式（ Factory Method ）与抽象工厂模式（ Abstract Factory ）。将简单工厂模式（ Simple Factory ）看为工厂方法模式的一种特例，两者归为一类。

两者皆可，在本文使用《 Java 与模式》的分类方法。下面来看看这些工厂模式是怎么来 “ 治病 ” 的。

三、简单工厂模式

简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。
       先来看看它的组成：

1)         工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在 java 中它往往由一个具体类实现。

2)         抽象产品角色：它一般是具体产品继承的父类或者实现的接口。在 java 中由接口或者抽象类来实现。

3)         具体产品角色：工厂类所创建的对象就是此角色的实例。在 java 中由一个具体类实现。

来用类图来清晰的表示下的它们之间的关系（如果对类图不太了解，请参考我关于类图的文章）：  

那么简单工厂模式怎么来使用呢？我们就以简单工厂模式来改造暴发户坐车的方式 —— 现在暴发户只需要坐在车里对司机说句： “ 开车 ” 就可以了。

// 抽象产品角色

public interface Car{

public void drive();
}

// 具体产品角色
public class Benz implements Car{

public void drive()  {

System.out.println("Driving Benz ");

}

}

public class Bmw implements Car{

public void drive()  {

System.out.println("Driving Bmw ");

}

}
。。。（奥迪我就不写了 :P ）

// 工厂类角色

public class Driver{

// 工厂方法 . 注意 返回类型为抽象产品角色
       public staticCar driverCar(String s)throws Exception    {

              // 判断逻辑，返回具体的产品角色给 Client
              if(s.equalsIgnoreCase("Benz"))  

                     return new Benz();

              else if(s.equalsIgnoreCase("Bmw"))

                     return new Bmw();

                    ......   
             else throw new Exception();

       。。。

// 欢迎暴发户出场 ......

public class Magnate{

       public static void main(String[] args){

              try{
                     // 告诉司机我今天坐奔驰               
                     Car car = Driver.driverCar("benz");
                     // 下命令：开车                    
                     car.drive();

              。。。

    将本程序空缺的其他信息填充完整后即可运行。如果你将所有的类放在一个文件中，请不要忘记只能有一个类被声明为 public 。本程序在 jdk1.4 下运行通过。

      程序中各个类的关系表达如下：

这便是简单工厂模式了。怎么样，使用起来很简单吧？那么它带来了什么好处呢？
       首先，使用了简单工厂模式后，我们的程序不在 “ 有病 ” ，更加符合现实中的情况；而且客户端免除了直接创建产品对象的责任，而仅仅负责 “ 消费 ” 产品（正如暴发户所为）。

       下 面我们从开闭原则（对扩展开放；对修改封闭）上来分析下简单工厂模式。当暴发户增加了一辆车的时候，只要符合抽象产品制定的合同，那么只要通知工厂类知道 就可以被客户使用了。所以对产品部分来说，它是符合开闭原则的；但是工厂部分好像不太理想，因为每增加一辆车，都要在工厂类中增加相应的业务逻辑或者判断 逻辑，这显然是违背开闭原则的。可想而知对于新产品的加入，工厂类是很被动的。对于这样的工厂类（在我们的例子中是为司机师傅），我们称它为全能类或者上 帝类。
       我们举的例子是最简单的情况，而在实际应用中，很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品，所以这可能会把我们的上帝累坏了，也累坏了我们这些程序员 :(
       于是工厂方法模式作为救世主出现了。

四、工厂方法模式

       工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。

你应该大致猜出了工厂方法模式的结构，来看下它的组成：

1)         抽象工厂角色：   这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在 java 中它由抽象类或者接口来实现。

2)         具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。

3)         抽象产品角色：它是具体产品继承的父类或者是实现的接口。在 java 中一般有抽象类或者接口来实现。

4)         具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在 java 中由具体的类来实现。

用类图来清晰的表示下的它们之间的关系：

工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的 “ 上帝类 ” 。正如上面所说，这样便分担了对象承受的压力；而且这样使得结构变得灵活起来 —— 当有新的产品（即暴发户的汽车）产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就可以被客户使用，而不必去修改任何已有的代码。可以看出工厂角色的结构也是符合开闭原则的！

       我 们还是老规矩，使用一个完整的例子来看看工厂模式各个角色之间是如何来协调的。话说暴发户生意越做越大，自己的爱车也越来越多。这可苦了那位司机师傅了， 什么车它都要记得，维护，都要经过他来使用！于是暴发户同情他说：看你跟我这么多年的份上，以后你不用这么辛苦了，我给你分配几个人手，你只管管好他们就 行了！于是，工厂方法模式的管理出现了。代码如下：

// 抽象产品角色，具体产品角色与简单工厂模式类似，只是变得复杂了些，这里略。
// 抽象工厂角色
public interface Driver{
       public Car driverCar();
}
public class BenzDriver implements Driver{
       public Car driverCar(){
              return new Benz();
       }
}
public class BmwDriver implements Driver{
       public Car driverCar()   {

return new Bmw();
       }
}

// 应该和具体产品形成对应关系 ...
// 有请暴发户先生
 public class Magnate

{

              public static void main(String[] args)

              {

                     try{ 
                            Driver driver = new BenzDriver();

                            Car car = driver.driverCar();

                            car.drive();

                     }

       ……

}

可 以看出工厂方法的加入，使得对象的数量成倍增长。当产品种类非常多时，会出现大量的与之对应的工厂对象，这不是我们所希望的。因为如果不能避免这种情况， 可以考虑使用简单工厂模式与工厂方法模式相结合的方式来减少工厂类：即对于产品树上类似的种类（一般是树的叶子中互为兄弟的）使用简单工厂模式来实现。

五、小结

工厂方法模式仿佛已经很完美的对对象的创建进行了包装，使得客户程序中仅仅处理抽象产品角色提供的接口。那我们是否一定要在代码中遍布工厂呢？大可不必。也许在下面情况下你可以考虑使用工厂方法模式：

1)         当客户程序不需要知道要使用对象的创建过程。

2)         客户程序使用的对象存在变动的可能，或者根本就不知道使用哪一个具体的对象。

简 单工厂模式与工厂方法模式真正的避免了代码的改动了？没有。在简单工厂模式中，新产品的加入要修改工厂角色中的判断语句；而在工厂方法模式中，要么将判断 逻辑留在抽象工厂角色中，要么在客户程序中将具体工厂角色写死（就象上面的例子一样）。而且产品对象创建条件的改变必然会引起工厂角色的修改。

       面对这种情况， Java 的反射机制与配置文件的巧妙结合突破了限制 —— 这在 Spring 中完美的体现了出来。

六、抽象工厂模式

       先来认识下什么是产品族： 位于不同产品等级结构中，功能相关联的产品组成的家族。还是让我们用一个例子来形象地说明一下吧。

图中的 BmwCar 和 BenzCar 就是两个产品树（产品层次结构）；而如图所示的 BenzSportsCar 和 BmwSportsCar 就是一个产品族。他们都可以放到跑车家族中，因此功能有所关联。同理 BmwBussinessCar 和 BenzSportsCar 也是一个产品族。
      回到抽象工厂模式的话题上。

可以说，抽象工厂模式和工厂方法模式的区别就在于需要创建对象的复杂程度上。而且抽象工厂模式是三个里面最为抽象、最具一般性的。

抽象工厂模式的用意为：给客户端提供一个接口，可以创建多个产品族中的产品对象

而且使用抽象工厂模式还要满足一下条件：

1)         系统中有多个产品族，而系统一次只可能消费其中一族产品。

2)         同属于同一个产品族的产品以其使用。

来看看抽象工厂模式的各个角色（和工厂方法的如出一辙）：

1)         抽象工厂角色：   这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在 java 中它由抽象类或者接口来实现。

2)         具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。在 java 中它由具体的类来实现。

3)         抽象产品角色：它是具体产品继承的父类或者是实现的接口。在 java 中一般有抽象类或者接口来实现。

4)         具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在 java 中由具体的类来实现。

类图如下：

为何使用?
工厂模式是我们最常用的模式了,著名的Jive论坛 ,就大量使用了工厂模式，工厂模式在Java程序系统可以说是随处可见。

为什么工厂模式是如此常用？因为工厂模式就相当于创建实例对象的new，我们经常要根据类Class生成实例对象，如A a=new A() 工厂模式也是用来创建实例对象的，所以以后new时就要多个心眼，是否可以考虑实用工厂模式，虽然这样做，可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。

我们以类Sample为例， 如果我们要创建Sample的实例对象:

Sample sample=new Sample();

可是，实际情况是，通常我们都要在创建sample实例时做点初始化的工作,比如赋值 查询数据库等。

首先，我们想到的是，可以使用Sample的构造函数，这样生成实例就写成:

Sample sample=new Sample(参数);

但是，如果创建sample实例时所做的初始化工作不是象赋值这样简单的事，可能是很长一段代码，如果也写入构造函数中，那你的代码很难看了（就需要Refactor重整）。

为什么说代码很难看，初学者可能没有这种感觉，我们分析如下，初始化工作如果是很长一段代码，说明要做的工作很多，将很多工作装入一个方法中，相当于将很多鸡蛋放在一个篮子里，是很危险的，这也是有背于Java 面向对象的原则，面向对象的封装(Encapsulation)和分派(Delegation)告诉我们，尽量将长的代码分派“切割”成每段，将每段再 “封装”起来(减少段和段之间偶合联系性)，这样，就会将风险分散，以后如果需要修改，只要更改每段，不会再发生牵一动百的事情。

在本例中，首先，我们需要将创建实例的工作与使用实例的工作分开, 也就是说，让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。

这时我们就需要Factory工厂模式来生成对象了，不能再用上面简单new Sample(参数)。还有,如果Sample有个继承如MySample, 按照面向接口编程,我们需要将Sample抽象成一个接口.现在Sample是接口,有两个子类MySample 和HisSample .我们要实例化他们时,如下:

Sample mysample=new MySample();
Sample hissample=new HisSample();

随着项目的深入,Sample可能还会"生出很多儿子出来", 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的.

但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了.

工厂方法
你会建立一个专门生产Sample实例的工厂:

那么在你的程序中,如果要实例化Sample时.就使用

Sample sampleA=Factory.creator(1);

这样, 在整个就不涉及到Sample的具体子类,达到封装效果,也就减少错误修改的机会,这个原理可以用很通俗的话来比喻:就是具体事情做得越多,越容易范错 误.这每个做过具体工作的人都深有体会,相反,官做得越高,说出的话越抽象越笼统,范错误可能性就越少.好象我们从编程序中也能悟出人生道理?呵呵.

使用工厂方法 要注意几个角色，首先你要定义产品接口，如上面的Sample,产品接口下有Sample接口的实现类,如SampleA,其次要有一个factory类，用来生成产品Sample，如下图，最右边是生产的对象Sample：

进一步稍微复杂一点，就是在工厂类上进行拓展，工厂类也有继承它的实现类concreteFactory了。

抽象工厂
工厂模式中有: 工厂方法(Factory Method) 抽象工厂(Abstract Factory).

这两个模式区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了,如上面工厂方法中是创建一个对象Sample,如果我们还有新的产品接口Sample2.

这里假设：Sample有两个concrete类SampleA和SamleB，而Sample2也有两个concrete类Sample2A和SampleB2

那么，我们就将上例中Factory变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现，下面就是将上例中的Factory拓展成抽象工厂:

从上面看到两个工厂各自生产出一套Sample和Sample2,也许你会疑问，为什么我不可以使用两个工厂方法来分别生产Sample和Sample2?

抽 象工厂还有另外一个关键要点，是因为 SimpleFactory内，生产Sample和生产Sample2的方法之间有一定联系，所以才要将这两个方法捆绑在一个类中，这个工厂类有其本身特 征，也许制造过程是统一的，比如：制造工艺比较简单，所以名称叫SimpleFactory。

在实际应用中，工厂方法用得比较多一些，而且是和动态类装入器组合在一起应用，

举例

我们以Jive的ForumFactory为例，这个例子在前面的Singleton模式中我们讨论过，现在再讨论其工厂模式: