Decorator确实能够很好的缓解当功能组合过多时子类继承所能够带来的问题。但是在得到很大的灵活性的同时，Decorator在使用时也表现得较为复杂。看看仅仅为了得到一个IO流，除了要创建核心的流外，还要为其加上各种各样的装饰类，这使得代码变得复杂而难懂。有几个人一开始时没有被Java的IO库吓一跳呢?

Bridge模式用来分离抽象和实现，使得这两个部分能够分别的演化而不必修改另外一部分的内容。通常的，可以在实现部分定义一些基本的原子方法，而在抽象部分则通过组合定义在实现层次中的原子方法来实现系统的功能。Decorator模式通过聚合机制来为对象动态的添加职责，解决了在子类继承中容易引起的子类爆炸的问题。

Composite模式是为了简化编程而提出的，一般的在编程的时候，如果严格的区分Component和Container的话，有时候会带来许多不便，而且这些往往是没有必要的。比如，我要在一个Container中放置一个Component，我并不需要知道这个Component到底是一个Container，或者就是一个一般的Component，在父级容器中所要做的，只是记录一个Component的引用，在需要的时候调用Component的绘制方法来显示这个Component。当这个Component确实是一个Container的时候，它可以通过Container重载后的绘制方法，完成对这个容器的显示，并把绘制消息传递给到它的子对象去。也就是说，对一个父级容器而言，它并不不关心，其子对象到底是一个Component，还是一个Container。它需要将Component和Container统一对待。

Composite模式比较简单，实现起来也不复杂，但是有一定的局限性。比如，在处理树的时候，我们往往需要处理三类对象：子树，页节点和非页节点。而在Composite模式中对于子树和非叶节点的区分并不明显，而是把他们合成为一个Composite对象了。而且在GOF给出的Composite的模式中，对于添加，删除子节点等属于Composite对象的的方法，是放在了Component对象中的，这虽然在实现的时候可以区分开来，但容易造成一些概念上的误解。

由上所叙，我们可以提出一个改进了的Composite模式，引入子树对象，从而将子树和非叶节点分开，如下图所示：

图十二：Composite模式的一种变体

虽然将Composite从Component类层次中分离出来，但并没有损害Composite模式的内涵。这样做不一定就会比上面的那个要好，各有不同的应用，不过有时候用这样的方法来处理子树要容易些，概念上也更为清晰。

下面的代码，给出了一个Composite模式简单的Java实现：

Strategy模式主要用来将算法实现从类中分离出来，并封装在一个单独的类中。更简单的说，对象与其行为(behaviour)这本来紧密联系的两部分被解耦，分别放在了两个不同的类中。这使得对同一个行为，可以方便的在任何时候切换不同的实现算法。而通过对策略的封装，为其提供统一的接口，也可以很容易的引入新的策略。

AWT的LayoutManager，是Strategy模式的一个例子。对于GUI而言，每个组件(Component)在容器中(Container)的排放是需要遵循一定的算法的。通常的方法是使用绝对坐标，就像VB，Delphi之类的工具所作的那样，记录每个组件在容器中的位置。这当然会带来一些问题，比如在窗体缩放的时候，就需要手工编码改变组件的大小和位置，以使得原来的比例得以保存。而在AWT中，引入了布局管理器(LayoutManager)的概念，使得布局的方法大大丰富，编码过程也变得简单。

一个容器，比如Applet，Panel等，仅仅记录其包含的组件，而布局管理器中封装了对容器中组件进行布局的算法，具体地说，就是指明容器中组件的位置和尺寸的大小。通过布局管理器，你只需要确定想放置的组件间的相对位置即可，这一方面简化编码，另一方面也有助于实现的平台无关性。

图十三：AWT中的容器和布局管理器的关系

每一个容器均有一个布局管理器，当容器需要布置它的组件时，它调用布局管理器的方法布置容器内的组件。LayoutManager2继承于LayoutManager，提供更为细致的布局功能，它可以让布局管理器为组件加上约束条件已确定组件如何被布置。例如，为了确定组件被摆放在边框内的位置，BorderLayout在它的组件上加上方向指示。

特别的，通过实现LayoutManager或者LayoutManager2接口，可以很容易实现自定义的布局策略。

回到模式的话题上来，如果有几个很相似的类，其区别仅仅是在个别行为上的动作不同，这时候就可以考虑使用Strategy模式。这样，通过策略组合，将原来的多个类精简为一个带有多个策略的类。这很符合OO设计的原则：找到变化的部分，并将其封装起来!Strategy模式同样的为子类继承提供了一个好的替代方案，当使用继承机制的时候，行为的改变是静态的，你指能够改变一次--而策略是动态的，可以在任何时候，切换任何次数。更为重要的是，策略对象可以在不同的环境中被不同的对象所共享。以布局管理器为例，虽然每一个容器只有一个布局管理器，但是一个布局管理器可以为多个容器工作。

图十四：Strategy模式的类图

Strategy模式也有一些缺点，比如，应用程序必须知道所有的策略对象，并从中选者其一。而且在策略对象被使用的时候，它和Context对象之间通常是紧耦合的，Context对象必须为策略对象提供与具体算法相关的数据或者其它的东西，而这些数据的传递可能并不能够风装载抽象地策略类中，因为并不是所有的算法都会需要这些数据的。另外，因为策略对象通常由应用程序所创建，Context对象并不能够控制Strategy的生命期，而在概念上，这个策略应该从属于Context对象，其生命期不应该超出Context的范围对象。

通常的，Strategy很容易和Bridge模式相混淆。确实，他们有着很相近的结构，但是，他们却是为解决不同的问题而设计的。Strategy模式注重于算法的封装，而Bridge模式注重于分离抽象和实现，为一个抽象体系提供不同的实现。

Iterator模式用来规格化对某一数据结构的遍历接口。

hasNext()：用来判断在遍历器中是否还有下一个元素。

next()：返回遍历器中的下一个元素。

remove()：在被遍历的Collection类中删除最后被返回的那个对象。

Collection接口作为这个Framework的基础，被所有其它的集合类所继承或者实现。对Collection接口，有一个基本的实现是抽象类AbstractCollection，它实现了大部分与具体数据结构无关的操作。比如判断一个对象是否存在于这个集合类中的contains()方法：

而这其中调用的iterator()方法是一个抽象方法，有赖于具体的数据结构的实现。但是对于这个containers()方法而言，并不需要知道具体的Iterator实现，而只需要知道它所提供的接口，能够完成某类任务既可，这就是抽象类中抽象方法的作用。其它的在AbstractCollection中实现的非抽象方法，大部分都是依赖于抽象方法iterator()方法所提供的Iterator接口来实现的。这种设计方法是引入抽象类的一个关键所在，值得仔细领悟。

这儿的设计技巧和上面一样，都是使用抽象方法来实现一个具体的操作。抽象方法作为最后被实现的内容，依赖于具体的子类。抽象类看起来很像是一个介于接口和子类之间的一个东西。

从设计上来讲，有人建议所有的类都应该定义成接口的形式，这当然有其道理，但多少有些极端。当你需要最大的灵活性的时候，应该使用接口，而抽象类却能够提供一些缺省的操作，最大限度的统一子类。抽象类在许多应用框架(Application Framework)中有着很重要的作用。例如，在一个框架中，可以用抽象类来实现一些缺省的服务比如消息处理等等。这些抽象类能够让你很容易并且自然的把自己的应用嵌入到框架中去。而对于依赖于每个应用具体实现的方法，可以通过定义抽象方法来引入到框架中。

其实在老版本的JDK中也有类似的概念，被称为Enumeration。Iterator其实与Enmeration功能上很相似，只是多了删除的功能。用Iterator不过是在名字上变得更为贴切一些。模式的另外一个很重要的功用，就是能够形成一种交流的语言(或者说文化)。有时候，你说Enumeration大家都不明白，说Iterator就都明白了。

Composite，Strategy和Iterator。Composite是一个结构性的模式，用来协调整体和局部的关系，使之能够被统一的安排在一个树形的结构中，并简化了编程。Strategy模式与Bridge模式在结构上很相似，但是与Bridge不同在于，它是一个行为模式，更侧重于结构的语义以及算法的实现。它使得程序能够在不同的算法之间自由方便的作出选择，并能够在运行时切换到其他的算法，很大程度上增加了程序的灵活性。Iterator模式提供统一的接口操作来实现对一个数据结构的遍历，使得当数据结构的内部算法发生改变时，客户代码不需要任何的变化，只需要改变相应的Iterator实现，就可以无缝的集成在原来的程序中。

有了前面诸多设计模式的基础，这儿可以提出一个比较特殊的模式MVC。MVC并不属于GOF的23个设计模式之列，但是它在GOF的书中作为一个重要的例子被提出来，并给予了很高的评价。一般的来讲，我们认为GOF的23个模式是一些中级的模式，在它下面还可以抽象出一些更为一般的低层的模式，在其上也可以通过组合来得到一些高级的模式。MVC就可以看作是一些模式进行组合之后的结果(实际上，MVC的出现要早于设计模式的提出，这而只是对它在设计模式的基础上进行在分析)。如果没有前面的基础，理解MVC或许会有一些困难。

MVC模式比较的特别，它含义比较的广，涉及的层面也不仅仅是设计这一块，不好简单的把它归为设计模式。当然，它主要还是作为一个设计的概念被提到的，而且在Java体系中，MVC有着至关重要的作用。这儿提的是Java中的设计模式，当然不好拉了它不讲了。

关于MVC的来龙去脉，这儿就不再讲了。这里主s要讲两个方面的：作为设计模式的MVC和作为体系结构模式的MVC。

所谓MVC，指的是一种划分系统功能的方法，它将一个系统划分为三个部分：

模型(Model)：封装的是数据源和所有基于对这些数据的操作。在一个组件中，Model往往表示组件的状态和操作状态的方法。

视图(View)：封装的是对数据源Model的一种显示。一个模型可以由多个视图，而一个视图理论上也可以同不同的模型关联起来。

控制器(Control)：封装的是外界作用于模型的操作。通常，这些操作会转发到模型上，并调用模型中相应的一个或者多个方法。一般Controller在Model和View之间起到了沟通的作用，处理用户在View上的输入，并转发给Model。这样Model和View两者之间可以做到松散耦合，甚至可以彼此不知道对方，而由Controller连接起这两个部分。

有了前面介绍的诸多模式之后，就可以很容易的通过模式来解释MVC的内在行为了。前面说过，在设计模式中，MVC实际上是一个比较高层的模式，它由多个更基本的设计模式组合而成，Model-View的关系实际上是Observer模式，模型的状态和试图的显示相互响应，而View-Controller则是由Strategy模式所描叙的，View用一个特定的Controller的实例来实现一个特定的响应策略，更换不同的Controller，可以改变View对用户输入的响应。而其它的一些设计模式也很容易组合到这个体系中。比如，通过Composite模式，可以将多个View嵌套组合起来;通过FactoryMethod模式来指定View的Controller，等等。

使用MVC的好处，一方面，分离数据和其表示，使得添加或者删除一个用户视图变得很容易，甚至可以在程序执行时动态的进行。Model和View能够单独的开发，增加了程序了可维护性，可扩展性，并使测试变得更为容易。另一方面，将控制逻辑和表现界面分离，允许程序能够在运行时根据工作流，用户习惯或者模型状态来动态选择不同的用户界面。

Swing号称是完全按照MVC的思路来进行设计的。在设计开始前，Swing的希望能够达到的目标就包括：

提供一套单一的API，但是能够支持多种视感(look-and-feel)，为用户提供不同的界面。

很自然的可以发现，使用MVC模式能够有助于实现上面的这两个目标。

严格的说，Swing中的MVC实际上是MVC的一个变体：M-VC。 Swing中只显示的定义了Model接口，而在一个UI对象中集成了视图和控制器的部分机制。View和Control比较松散的交叉组合在一起，而更多的控制逻辑是在事件监听者部分引入的。

但是，这并没有妨碍在Swing中体现MVC的精髓。事实上，在Swing的开发初期，Swing确实是按照标准的MVC模式来设计的，但是很快的问题就出现了：View和Controller实际上是紧密耦合的，很难作出一个能够适应不同View的一般化的Controller来，而且，一般也没有很大的必要。

在Swing中基本上每一个组件都会有对应的Model对象。但其并不是一一对应的，一个Model接口可以为多个Swing对向服务，例如：JProgressBar，JScrollBar，JSlider这三个组件使用的都是BoundedRangeModel接口。这种模型的共享更能够从分的体现MVC的内涵。除了Model接口外，为了实现多个视感间的自由切换，每个Swing组件还包含一个UI接口--也就是View-Controller，负责对组件的绘制和接受用户输入。

Model-View是Subject和Obverser的关系，因而，模型的改变必须要在UI对象中体现出来。Swing使用了JavaBeans的事件模型来实现这种通知机制。具体而言，有两种实现办法，一是仅仅通知事件监听者状态改变了，然后由事件监听者向模型提取必要的状态信息。这种机制对于事件频繁的组件很有效。另外的一种办法是模型向监听者发送包含了已改变的状态信息的通知给UI。这两种方法根据其优劣被分别是现在不同的组件中。比如在JScollBar中使用的是第一种方法，在JTable中使用的是第二种方法。而对Model而言，为了能够支持多个View，它并不知道具体的每一个View。它维护一个对其数据感兴趣的Obverser的列表，使得当数据改变的时候，能够通知到每一个Swing组件对象。

上面讲到的是作为设计模式的MVC。而在J2EE中，Sun更是将MVC提升到了一个体系结构模式的高度，这儿的MVC的含义就更为广泛了。与Swing中不同的是，在这儿MVC的各个部件不再是单纯的类或者接口，而是应用程序的一个组成部分!

在J2EE Blueprint中，Sun推荐了一种基于MVC的J2EE程序的模式。对于企业级的分布式应用程序而言，它更需要支持多种形式的用户接口。比如，网上商店需要一个HTML的界面来同网上的客户打交道，WML的界面可以提供给无线用户，管理者可能需要传统的基于Swing的应用程序来进行管理，而对对商业伙伴，基于XML的Web服务可能对他们更为方便。

MVC无疑是这样一个问题的有效的解决方法，通过在控制和显示逻辑分离出核心的数据存取功能，形成一个Model模块，能够让多种视图来共享这个Model。

在J2EE中有几个核心的技术，JSP，JavaBean，Servlet，EJB，SessionBean，EntityBean构成了J2EE构架的基石。JSP能够生成HTML，WML甚至XML，它对应于Web应用程序中的View部分。EJB作为数据库与应用程序的中介，提供了对数据的封装。一般EntityBean封装的是数据，SessionBean是封装的是对数据的操作。这两个部分合起来，对应于Web应用程序的Model部分。在技术上，JSP能够直接对EJB进行存取，但这并不是好办法，那样会混淆程序中的显示逻辑和控制逻辑，使得JSP的重用性能降低。这时候有两种解决方法，通过JavaBean或者Servlet作为中介的控制逻辑，对EJB所封装的数据进行存取。这时，JavaBean或者Servlet对应于Web引用程序中的Controller部分。两种类型的Controller各有其优缺点：JSP同Servlet的交互不容易规范化，使得交互的过程变得复杂，但是Servlet可以单独同用户交互，实际上JSP的运行时状态就是Servlet;而由于JavaBean的规范性，JSP同JavaBean的交互很容易，利用JavaBean的get/set方法，JSP不需要过多的语句就可以完成数据的存取，这能够让JSP最大限度的集中在其视图功能上，而且，在桌面应用程序中使用JavaBean也很容易，而用Servlet就相对麻烦许多。根据不同的问题背景，可以选取不同的Controller，有时候也可以两者混合使用，或者直接在Servlet中调用JavaBean。

在J2EE中，MVC是一个大的框架，这时我们往往把它不再看作为设计模式，而是作为体系结构模式的一个应用了。

在这篇文章中，从设计的角度，对Java的类库进行了一些分析，并着重于设计模式在其中的使用问题。相信大家看了之后，不论对Java类库本身，还是设计模式，都应该有了一个更深层次的了解。当然，Java类库是一个非常庞大的东西，还有着许多设计精良的结构。因而，对Java源代码的研究，不论对于编码还是设计，都是很有裨益的。本人接触设计模式的时间并不很长，对其的理解可能会有一些偏差，如有谬误的地方，还请能够提出，大家能够共同的探讨。

需要说明的是，对模式的描叙实际上是有一套完整的规格(或者语言)来进行的，涉及到模式的意图(Intent)，问题描叙(Problem)，背景(Context)，约束(Force)，解决方案(Solution)，结果(Resulting Context)等等。但这儿为了叙述的方便，并没有将它们一一列举。如果需要对模式有详细系统的研究，就应该对这些规格叙述有更深入的了解。