Design Pattern Introduction – catch the core

类别:Java 点击:0 评论:0 推荐:
Design Pattern Introduction – catch the core

(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程序。

 

本文地址:http://com.8s8s.com/it/it17959.htm