从Java类库看设计模式（3）

从Java类库看设计模式（3）2011-04-23 IBM 刘武东上一次主要介绍了几个创建型的设计模式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模式对系统的划分