上一次主要介绍了几个创建型的设计模式AbstractFactroy，FacToryMethod和Singliton 。它们的共同的特点，都是用来创建对象的。这次接下来的内容，涉及到的是几个结构型的 模式。所谓结构型模式，就是用来解决在创建系统结构的过程中，通过对类或者对象进行合 理有效的组合，以获得更大的结构的方法。这儿主要讲到了Bridge模式和DecoraTor模式。对 于Bridge模式可能需要更多的理解，因为它在很大程度上说，例示了设计模式的基本的设计 思路和原则。
Bridge模式
当初Java刚刚推出来的时候，AWT可是一个比较热的话题，虽然现在有被Swing取代的趋势 。但是我一直都觉得AWT也有其优势，至少它使用的本地代码就要比Swing快上许多，而且， 可以为用户提供熟悉的本地操作系统界面。如果在Windows XP中运行基于AWT的程序的话，XP 中绚烂多变的界面Theme可以轻易应用到AWT程序中，而Swing就不行了，因为AWT所调用的是 本带代码，使用的是本地的窗体控件。当然，Swing也有其好处，不可一概而论。
简单来讲，AWT提供对程序员的是对窗体界面系统的抽象，而在内部实现中，针对每一种 操作系统，分别有不同实现，这就是同位体（Peer）的概念。当程序员调用AWT对象时，调用 被转发到对象所对应的一个Peer上，在由Peer调用本地对象方法，完成对象的显示。例如， 如果你使用AWT创建了一个Menu类的实例，那么在程序运行时会创建一个菜单同位体的实例， 而由创建的同位体的来实际执行菜单的现实和管理。不同的系统，有不同的同位体实现， Solaris JDK将产生一个Motif菜单的同位体，Windows下的JDK将产生一个Windows的菜单的同 位体，等等。同位体的使用，使得交叉平台窗口工具的开发变得极为迅速，因为同位体的使 用可以避免重新实现本地窗口控件中已经包含的方法。
图九：AWT中的组件和其对等体
实际上，从设计的角度来看，这是一个抽象和实现分离的过程–AWT是抽象，同位体是实 现，抽象和实现各自成为一个对象体系，它们由一个桥连接起来，可以各自发展各自的对象 层次，而不必顾虑另一方面。这就是Bridge模式所提供的思想。Bridge模式更可以提供在各 个不同的实现中动态的进行切换，而不必从新编译程序。
通常，Bridge模式和AbstractFacTory模式一起工作，由AbstractFacTory来创建一个具体 实现的对象体系。特殊的，当只有一个实现的时候，可以将ImplemenTor抽象类去掉。这样， 在抽象和实现之间建立起了一一对应的关系，但这并不损害Bridge模式的内涵。这被称为退 化了的Bridge模式。
很多时候，Abstraction层次和ImplemenTor层次之间的方法都不是一一对应的，也就是说 ，在Abstraction和ImplemenTor之不是简单的的消息转发。通常，我们会将Abstraction作为 一个抽象类（而不是接口）来实现。在ImplemenTor层次中定义底层的，或者称之为原子方法 ，而在Abstraction层次中定义一些中高层的基于原子方法的抽象方法。这样，就能更为清晰 的划分Abstraction和ImplemenTor，类的结构也更为清晰。
图十：Bridge模式对系统的划分
下面，我们来看一个Bridge模式的具体应用。考虑这样的一个问题，需要生成一份报告， 但是报告的格式并没有确定，可能是HTML文件，也可能是纯ASCII文本。报告本身也可能分为 很多种，财务报表，货物报表，等等问题很简单，用继承也较容易实现，因为相互之间的组 合关系并不是很多。但是，我们现在需要用Bridge的观点来看问题。
在Bridge模式中，使用一个Report类来描叙一个报告的抽象，用一个Reporter类来描叙 Report的实现，它的子类有HTMLReporter和ASCIIReporter，用来分别实现HTML格式和ASCII 格式的报告。在Report层次下面，有具体的一个StockListReport子类，用来表示货物清单报 告。
public abstract class Report{ Reporter reporter; public Report(Reporter reporter) { this.reporter = reporter;}//抽象类使用桥接对象的方法来实现一个任务 public void addReportItem(Object item){ reporter.addLine(item.toString()); } public void addReportItems(List items){ IteraTor iteraTor = items.iteraTor(); while ( iteraTor.hasNext() ) { reporter.addLine(iteraTor.next().toString()); } } public String report(){ return reporter.getReport(); }}public class StockListReport extends Report{ ArrayList stock=new ArrayList(); public StockListReport(Reporter reporter){ super(reporter); } public void addStockItem(StockItem stockItem){ stock.add(stockItem); addReportItem(stockItem); }}//实现层次的抽象父类定义原子方法，供抽象层次的类调用public abstract class Reporter{ String header = ""; String trailer = ""; String report = ""; public abstract void addLine(String line); public void setHeader(String header){ this.header = header; } public void setTrailer(String trailer){ this.trailer = trailer; } public String getReport(){ return header+report+trailer; }}public class HTMLReporter extends Reporter{ public HTMLReporter(){ setHeader("<HTML>/n<HEAD></HEAD>/n<BODY>/n"); setTrailer("</BODY>/n</HTML>"); } public void addLine(String line){ report += line + "<BR>/n"; }}public class ASCIIReporter extends Reporter{ public void addLine(String line) { report += line + "/n"; }}
实际上，Bridge模式是一个很强大的模式，可以应用在很多方面。其基本思想：分离抽象 和实现，是设计模式的基础之一。正如GOF所提到的：”找到变化的部分，并将其封装起来”； “更多的考虑用对象组合机制，而不是用对象继承机制”。Bridge模式很好的体现了这几点。
DecoraTor模式
在使用Java中的IO类库的时候，是不是快要被它那些功能相似，却又绝对可称得上庞杂的 类搞得要发疯了？或许你很不明白为什么要做这么多功能相似的几十个类出来，这就是 DecoraTor模式将要告诉你的了。
在IO处理中，Java将数据抽象为流（Stream）。在IO库中，最基本的是InputStream和 OutputStream两个分别处理输出和输入的对象（为了叙述简便起见，这儿只涉及字节流，字 符流和其完全相似），但是在InputStream和OutputStream中之提供了最简单的流处理方法， 只能读入/写出字符，没有缓冲处理，无法处理文件，等等。它们只是提供了最纯粹的抽象， 最简单的功能。
如何来添加功能，以处理更为复杂的事情呢？你可能会想到用继承。不错，继承确实可以 解决问题，但是继承也带来更大的问题，它对每一个功能，都需要一个子类来实现。比如， 我先实现了三个子类，分别用来处理文件，缓冲，和读入/写出数据，但是，如果我需要一个 既能处理文件，又具有缓冲功能的类呢？这时候又必须在进行一次继承，重写代码。实际上 ，仅仅这三种功能的组合，就已经是一个很大的数字，如果再加上其它的功能，组合起来的 IO类库，如果只用继承来实现的话，恐怕你真的是要被它折磨疯了。
图六：JDK中IO流的类层次
DecoraTor模式可以解决这个问题。DecoraTor字面的意思是装饰的意思，在原有的基础上 ，每添加一个装饰，就可以增加一种功能。这就是DecoraTor的本意。比如，对于上面的那个 问题，只需要三个DecoraTor类，分别代表文件处理，缓冲和数据读写三个功能，在此基础上 所衍生的功能，都可以通过添加装饰来完成，而不必需要繁杂的子类继承了。更为重要的是 ，比较继机制承而言，DecoraTor是动态的，可以在运行时添加或者去除附加的功能，因而也 就具有比继承机制更大的灵活性。
上面就是DecoraTor的基本思想，下面的是DecoraTor模式的静态结构图：
图七：DecoraTor模式的类图
可以看到，一个DecoraTor与装饰的Subject对象有相同的接口，并且除了接口中给出的方 法外，每个DecoraTor均有自己添加的方法，来添加对象功能。每个DecoraTor均有一个指向 Subject对象的引用，附加的功能被添加在这个Subject对象上。而DecoraTor对象本身也是一 个Subject对象，因而它也能够被其他的DecoraTor所修饰，提供组合的功能。
在Java IO操作中，经常可以看到诸如如下的语句：
myStringBuffer=new StringBuffer("This is a sample string to be read");FilterInputStream myStream=new LineNumberInputStream( new BufferInputStream( new StringBufferInputStream( myStringBuffer)));myStream.read();myStream.line();
多个的DecoraTor被层叠在一起，最后得到一个功能强大的流。既能够被缓冲，又能够得 到行数，这就是DecoraTor的威力！
不仅仅如此，Java中的IO还允许你引入自定义的DecoraTor，来实现自己想要的功能。在 良好的设计背景下，这做起并不复杂，只需要4步：
创建两个分别继承了FilterInputStream和 FilterOutputStream的子类
重载read()和write()方法来实现自己想要的功能。
可以定义或者重载其它方法来提供附加功能。
确定这两个类会被一起使用，因为它们在功能上是对称的。
就这样，你就可以无限的扩展IO的功能了。
在了解了IO中的DecoraTor后，我们再来看一个DecoraTor模式应用的具体的例子。这个例 子原本是出现在GOF书中的，这儿稍作改动，引来示例。
在一个图形用户界面（GUI）中，一个组件有时候需要用到边框或者滚动条，而有时候又 不需要，有时候可能两者都要用到。当需要动态的去处或者添加职能的时候，就可以考虑使 用DecoraTor模式了。这儿对于一个VisualComponent组件对象，我们引入了两个DecoraTor类 ：BoderDecoraTor和ScrollDecoraTor，分别用来为组件添加边框和处理滚动。程序类图如下 ：
图八：DecoraTor模式的应用例子
程序写得很简单，没有包括具体的代码，只是有一个可以运行的框架以供参考。代码如下 ：
//Client类用来创建窗体和组件对象，这儿可以看到DecoraTor是如何组合和应用 的class Client{ public static void main (String[] args ){ Window window = new Window (); TextView textView = new TextView (); window.setContents ( new BorderDecoraTor ( new ScrollDecoraTor (textView, 500), 1)); }}//Windows类用来容纳组件对象class Window{ VisualComponent contents; public Window () {} public void setContents (VisualComponent vc){ contents = vc; }}//VisualComponent类定义了组件的接口class VisualComponent{ public VisualComponent (){} public void draw (){} public void resize (){}}//TextView类是一个显示文本的具体的组件class TextView extends VisualComponent{ public TextView (){} public void draw (){ … } public void resize (){ … }}//DecoraTor类继承于VisualComponent，定义所有DecoraTor的缺省方法实现class DecoraTor extends VisualComponent{ private VisualComponent component; public DecoraTor (VisualComponent vc) { this.component=vc; } public void draw () { component.draw (); } public void resize () { component.resize (); }}//BorderDecoraTor类为组件提供边框class BorderDecoraTor extends DecoraTor{ private int width; public BorderDecoraTor (VisualComponent vc, int borderWidth){ super (vc); width = borderWidth; } public void draw (){ super.draw (); drawBorder (width); } private void drawBorder (int width){ … }}//ScrollDecoraTor类为组件提供滚动条class ScrollDecoraTor extends DecoraTor{ private int scrollSize; public ScrollDecoraTor (VisualComponent vc, int scrSize){ super (vc); scrollSize = scrSize; } public void draw (){ scroll(); super.draw (); } private void scroll (){ … }}
DecoraTor确实能够很好的缓解当功能组合过多时子类继承所能够带来的问题。但是在得 到很大的灵活性的同时，DecoraTor在使用时也表现得较为复杂。看看仅仅为了得到一个IO流 ，除了要创建核心的流外，还要为其加上各种各样的装饰类，这使得代码变得复杂而难懂。 有几个人一开始时没有被Java的IO库吓一跳呢？
小结：
Bridge模式用来分离抽象和实现，使得这两个部分能够分别的演化而不必修改另外一部分 的内容。通常的，可以在实现部分定义一些基本的原子方法，而在抽象部分则通过组合定义 在实现层次中的原子方法来实现系统的功能。DecoraTor模式通过聚合机制来为对象动态的添 加职责，解决了在子类继承中容易引起的子类爆炸的问题。
含泪播种的人一定能含笑收获。
