Design Pattern Introduction – catch the core

Design Pattern Introduction – catch the core<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

(wang hailong)

Data Type and Algorithm 数据类型和算法

Design Pattern(设计模式)的目标是，把共通问题中的不变部分和变化部分分离出来。不变的部分，就构成了Design Pattern(设计模式)。这一点和Framework(框架)有些象。

我们来看下面的问题。

1．有一个int数组，int[] intArray; 找出数组中最大的数。

2．有一个float数组，float[] floatArray，找出数组中最大的数。

对应问题1，有函数，int max(int[] intArray)。

对应问题2，有函数，float max(float[] floatArray)。

这里变化的部分是数据类型(int and float)，不变的部分是算法max。

在C++里，可以用Template机制解决这个问题。

template <typename DataType> DataType max(DataType[] dataArray);

C++的STL就是为了解决这些问题编写的。

1. STL提供了一套容器（集合）类，比如list，vector，set等。容器（集合）类里可以放置任何类型的数据。

2. STL提供了一套Algorithm算法函数，对容器进行操作。上面讲的max函数，自然也包括在里面。

关于设计模式，还有一种说法，Design Pattern is design by contract. 设计模式就是提供一套良好的对象之间的操作接口协议。

STL的Algorithm算法函数如果要对对容器进行操作，那么这些容器必须提供一套通用的接口。容器必须提供基本的遍历操作。这就抽象出来一个Design Pattern —— iterator。

换一种说法，算法和容器之间必须满足这样的协议：容器必须提供iterator接口。相对于max算法，容器里面的数据类型，必须是可以比较大小的，即支持 <, =, > 等操作符。如果我们有一个sum求和算法，那么，相对于sum，容器里面的数据类型，必须是可以相加的，即支持 + 操作符。

关于java的例子，java.util.Collections也提供了类似的的算法。max, sort, binarySearch等。

STL的容器和算法，要比java全面，强大许多。

问题的维度

我们经常把一些公用的处理部分，写成一个公用函数，程序的各个部分都可以调用这个函数。函数的逻辑和算法是不变的，变化的只有参数。这称为重用。

设计模式也是为了达到重用的目的——达到设计结构的重用。但因为设计模式对应的问题比较复杂，问题中变化的部分无法简单的用参数来表示，必须用一些面向对象的特性来描述。

分析某一类相似的问题，从中抽象出设计模式的第一步，就是识别出变化的部分和不变的部分；第二步，就是设计不变部分的结构，定义对象之间的接口协议，使得变化的部分越少越好，越容易改动越好。

决定一个设计模式复杂度的因素，主要是问题的维度。这里，“问题的维度”的意思，主要是指变化部分的维度：这些变化的部分有哪些方面不同？

比如，上面的数据类型和算法的例子，我们可以看到，不同的部分有，数据类型不同，容器类型不同；相同的部分有，算法的逻辑和流程相同。这样，我们就抽象出一个2维（层）的设计模式。第一层，数据类型和容器的分离，数据类型不同，容器提供的数据操作相同——遍历，增加，删除，查找等；第二层，容器和算法的分离，容器的类型不同，但算法的逻辑和流程相同，比如max算法的流程：（1）遍历容器里面的每一个数据，（2）比较这些数据，记录最大的数据，（3）返回最大的数据。

Gang of Four提出的23种基本设计模式，对应的问题空间大多是1维的。一些稍微复杂的设计模式是2维的，比如Double Dispatch(Visitor)和Abstract Factory。

我们来看Abstract Factory。举java里面的awt窗体控件为例。

（这个例子出现在很多介绍设计模式的书籍中，有一些很好，给了我很多启发。）

（我尽量避免写重复的东西。大多数的书籍和资料，都在重复地写大家都知道的东西，都不约而同地略过大家都不知道的东西。书籍和资料也能做到良好的重用就好了。经过沉痛的教训，我终于认识到，出版社之间的差距是如此之大。我强烈建议，只选择第一流的出版社，比如清华出版社，当之无愧，几乎每一本书都是精品。有些出版社，三思，三思。我这里就不提了。一提就后悔。题外话 :-）

因为java是跨平台的，awt窗体控件也要和当前的操作系统对应。这里的问题的维度，分为两层：（1）操作系统不同，比如unix, windows，（2）控件类型不同，比如，Button, Dialog, ScrollBar等。

我们定义一个factory工厂基类（或接口）Toolkit，有createButton，createDialog等方法。参见java.awt.Toolkit类，就是factory工厂基类。

我们再定义一个UnixToolkit，继承（或实现）Toolkit，其中的createButton函数返回unix button, createDialog返回unix dialog。

我们再定义一个WindowsToolkit，继承（或实现）Toolkit，其中的createButton函数返回Windows button, createDialog返回Windows dialog。

以上就是Abstract Factory的例子。注意，上述的UnixToolkit和WindowsToolkit部分存在于操作系统相关的native code里面，在JDK文档和java source code里面是找不到的。

那么，窗体控件创建了之后，又是如何工作的呢？毕竟，这些窗体控件是和操作系统相关的。同样，窗体控件需要调用一些操作系统相关的native code。在java里面，这称为peer。比如，Button类需要调用ButtonPeer类来实现控件的操作，Dialog类需要调用DialogPeer类来实现控件的操作。这种结构称为Bridge模式。

可以看到，Bridge模式对应的问题空间只有1维——对应的操作系统不相同。

（由于java.awt.peer包是操作系统相关的，所以不出现在java doc里面，但在JDK源码里面可以看到这个包，比如java.awt包的Button.java文件里面，就用到了java.awt.peer.ButtonPeer。）

通过上面的分析，我们可以看出，上述的UnixToolkit和WindowsToolkit，创建的窗体控件的操作都是相同的，只是控件对应的peer不同，导致了具体的操作不同。我们可以看到，由于Bridge模式的应用，现在，问题中变化的部分，只有peer部分了。

按照这种思路扩展，我们只要为awt窗体控件提供另外的一组peer，就能够把awt窗体控件“翻译”另外一种操作平台上的空间。比如，我们提供一组对应于awt窗体控件的html peer。把awt窗体控件“翻译”为html 控件。这样，生成一个awt Button，就相当于在网页上生成一个html Button，这个awt Button的事件触发，就相当于html button的事件触发。

参见，http://sourceforge.net的Echo 开发框架（open source），就是一个杰出的实现。使用Echo 开发框架，就能够用编写AWT、Swing的方法，来编写web程序。