板桥里人 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源代码，你肯定无法看懂。

:)