上一篇:从Java类库看设计模式(3)

下一篇:从Java类库看设计模式(1)

从Java类库看设计模式(2)

Command模式

在设计一般用途的软件的时候,在C或者C++语言中,用的很多的一个技巧就是回调函数(Callback),所谓的回调函数,意指先在系统的某个地方对函数进行注册,让系统知道这个函数的存在,然后在以后,当某个事件发生时,再调用这个函数对事件进行响应。在C或者C++中,实现的回调函数方法是使用函数指针。但是在Java中,并不支持指针,因而就有了Command模式,这一回调机制的面向对象版本。

Command模式用来封装一个命令/请求,简单的说,一个Command对象中包含了待执行的一个动作(语句)序列,以执行特定的任务。当然,并不是随便怎么样的语句序列都可以构成一个Command对象的,按照Command模式的设计,Command对象和它的调用者Incvoker之间应该具有接口约定的。也就是说,Invoker得到Command对象的引用,并调用其中定义好的方法,而当Command对象改变(或者是对象本身代码改变,或者干脆完全另外的一个Command对象)之后,Invoker中的代码可以不用更改。这样,通过封装请求,可以把任务和任务的实现加以分离。

图二:Command模式的类图

而对于请求的处理又有两种不同的方法,一种是Command只充当代理,将请求转发给某个接受者对象,还有一种是Command对象自己处理完所有的请求操作。当然,这只是两个极端,更多的情况是Command完成一部分的工作,而另外的一部分这则交给接受者对象来处理。

在新的JDK的代理事件模型中,就可以看作是这样的一个Command模式。在那个模型中,一个事件监听者类EventListener监听某个事件,并根据接口定义,实现特定的操作。比如,当用Document对象的addDocumentListener(DocumentListener listener) 方法注册了一个DocumentListener后,以后如果在Document对象中发生文本插入的事件,DocumentListener中实现的insertUpdate(DocumentEvent e)方法就会被调用,如果发生文本删除事件,removeUpdate(DocumentEvent e)方法就会被调用。怎么样,想想看,这是不是一个Command模式的应用呢?

然而,最经典的Command模式的应用,莫过于Swing中的Action接口。Action实际上继承的是ActionListener,也就是说,它也是一个事件监听者(EventListener)。但是Action作为一种ActionListener的扩展机制,提供了更多的功能。它可以在其中包含对这个Action动作的一个或者多个文字的或图标的描叙,它提供了Enable/Disable的功能许可性标志。并且,一个Action对象可以被多个Invoker,比如实现相同功能的按钮,菜单,快捷方式所共享。而这些Invoker都知道如何加入一个Action,并充分利用它所提供的扩展机制。可以说,在这儿Action更像一个对象了,因为它不仅仅提供了对方法的实现,更提供了对方法的描叙和控制。可以方便的描叙任何的事务,这更是面向对象方法的威力所在。

下面我们看一个Command模式的应用的例子。假设要实现这样的一个任务:Task Schedule。也就是说,我想对多个任务进行安排,比如扫描磁盘,我希望它每1个小时进行一次,而备份数据,我希望它半个小时进行一次,等等等等。但是,我并不希望作为TaskSchedule的类知道各个任务的细节内容,TaskSchedule应该只是知道Task本身,而对具体的实现任务的细节并不理会。因而在这儿,我们就需要对TaskSchedule和Task进行解耦,将任务和具体的实现分离出来,这不正是Command模式的用武之地吗?

图三:Command模式的应用例子

程序清单:

程序本身其实没有多大的意义,因而,程序在编码的时候也只是用的最简单的方法来实现的,如果要做一个真正的TaskSchedule的话,这个程序除了结构上的,其它没有什么好值得参考的了。

AbstractFactory 和 FactoryMethod

基本上来说,AbstractFacotry模式和FactoryMethod模式所作的事情是一样的,都是用来创建与具体程序代码无关的对象,只是面对的对象层次不一样,AbstractFactory创建一系列的对象组,这些对象彼此相关。而FactoryMethod往往只是创建单个的对象。

再开始这两个模式之前,有必要先陈叙一个在设计模式,或者说在整个面向对象设计领域所遵循的一个设计原则:针对接口编程,而不是针对具体的实现。这个思想可以说是设计模式的基石之一。现在的很多对象模型,比如EJB,COM+等等,无不是遵照这个基本原则来设计的。针对接口编程的好处有很多,通过接口来定义对象的抽象功能,方便实现多态和继承;通过接口来指定对象调用之间的契约,有助于协调对象之间的关系;通过接口来划分对象的职责,有助于寻找对象,等等。

AbstractFactory和FactoryMethod,还有其他的一些创建型的设计模式,都是为了实现这个目的而设计出来的。它们创建一个个符合接口规范的对象/对象组,使得用同一个Factory创建出来的对象/对象组可以相互替换。这种可替换性就称为多态,是面向对象的核心思想之一。而多态,是通过动态绑定来实现的。

图四:AbstractFactory模式的类图

客户程序使用具体的AbstractFacotry对象(ConcreteFactoryX)调用CreateProductX()方法,生成具体的ConcreteProductX。每个AbstractFactory所能生成的对象,组成一个系列的对象组,他们可能是相互相关的,紧耦合的。应为各个AbstractFactory对象所能够生成的对象组都遵循一组相同的接口(AbstractProductX),因而当程序是针对接口进行编程的时候,这些实现方法各不相同的对象组却可以相互的替换。

实际上,客户程序本身并不关心,也不知道具体使用的是那些产品对象。它甚至能够不理会到底是哪个AbstractFactory对象被创建。在这种情况下,你可能会问,那么一个AbstractFactory又该如何生成呢? 这时候,就该用该FactoryMethod模式了。

前面有说过,AbstractFactory着重于创建一系列相关的对象,而这些对象与具体的AbstractFactory相关。而FactoryMethod则着重于创建单个的对象,这个对象决定于一个参数或者一个外部的环境变量的值;或者,在一个抽象类中定义一个抽象的工厂方法(也成为虚拟构造器),然后再实现的子类中返回具体的产品对象。

FactoryMethod可以借助一个参数或者一个外部的标志来判断该具体生成的哪一个子类的实例。比如对于不同的具体情况,需要有不同的AbstractFactory来生成相应的对象组。这时候,FactoryMethod通常作为一个AbstractFactory对象的静态方法出现,使得其能够在具体的对象被创建之前就能够被调用。

在JAVA中,应用这两个模式的地方实在太多,下面我们来看一个在JAXP中这两个模式的应用。JAXP是用来处理XML文档的一个API。我们都知道XML文件的一个特点就是其平台无关,流通性能好。因而往往也需要处理他们的程序具有更好的平台无关性。Java语言是一个比较好的平台无关语言,可以作为一个选择,但是对XML进行解析的解析器确有很多。有时候需要在不同的解析器之间进行切换,这时候,JAXP的良好设计就能够体现出来了。它能够允许在不同解析器之间竟进行切换的时候,不用更改程序的代码。

我们就拿JAXP中的DOM解析器来作为例子,来例示AbstractFactory和FactoryMethod的用法。

图五:DOM中工厂模式的应用

上图中为了方便起见,只画出了抽象类和接口,DocumentBuilderFactory和DocumentBuilder都是抽象类。

DocumentBuilderFactory的静态方法newInstance()方法根据一个外部的环境变量javax.xml.parsers.DocumentBuilderFactory的值来确定具体生成DocumentBuilderFactory的哪一个子类。这儿的newInstance()是一个工厂方法。当DocumentBuilderFactory被创建后,可以调用其newDocumentBuilder()来创建具体一个DocumentBuilder的子类。然后再由DocumentBuilder来生成Document等DOM对象。

下面是创建一个DOM对象的代码片段:

在这儿,DocumentBuilder,Document,Node等等对象所组成的一个产品组,是和具体的DocumentBuilderFactory相关的。这也就是AbstractFactory模式的含义所在。

当然,FactoryMethod模式应用的很广。这是一个具体的例子,但他不应该限制我们的思路,FactoryMethod和AbstractFactory是解决面向对象设计中一个基本原则--面向接口编程的主要方法。

Singleton模式

Singleton模式要解决的是对象的唯一性问题。由Singleton模式创建的对象在整个的应用程序的范围内,只允许有一个对象的实例存在。这样的情况在Java程序设计的过程中其实并不少见,比如处理JDBC请求的连接池(Connection Pool),再比如一个全局的注册表(Register),等等,这都需要使用到Singleton,单件模式。

在Java中,最简单的实现Singleton模式的方法是使用static修饰符,static可以用在内部类上,也可以用在方法和属性上,当一个类需要被创建成Singleton时,可以把它所有的成员都定义成static,然后再用final和private来修饰其构造函数,使其不能够被创建和重载。这在程序语法上保证了只会有一个对象实例被创建。比如java.util.Math就是这样的一个类。

而Singleton模式所作的显然要比上面介绍的解决方法要复杂一些,也更为安全一些。它基本的思路也还是使用static变量,但是它用一个类来封装这个static变量,并拦截对象创建方法,保证只有一个对象实例被创建,这儿的关键在于使用一个private或者protected的构造函数,而且你必须提供这样的一个构造函数,否则编译器会自动的为你创建一个public的构造函数,这就达不到我们想要的目的了。

对象创建的方法,除了使用构造函数之外,还可以使用Object对象的clone()方法,因而在Singleton中也要注意这一点。如果Singleton类直接继承于Object,因为继承于Object的clone()方法仍保留有其protected修饰,因而不能够被其他外部类所调用,所以可以不用管它,但是如果Singleton继承于一个其他的类,而这个类又有重载clone()方法,这时就需要在Singleton中再重载clone()方法,并在其中抛出CloneNotSupportedException,这样就可以避免多个Singleton的实例被创建了。

在JDK1.2以前的版本中使用Singleton模式的时候有一些需要额外注意的地方,因为Singleton类并没有被任何其他的对象所引用,所以这个类在创建后一段时间会被unload,Singleton类的静态方法就会出现问题,这是由于Java中垃圾收集机制造成的。解决的方法也很容易,只需要为其创建一个引用就行了。而在JDK1.2以后的版本中,Sun重新定义了Java规范,改正了其垃圾收集机制中的一些问题,这个问题也就不复存在了,这儿指出只是为了提起大家的主意。

小结:

Command模式用来封装请求,也描叙了一致性的发送请求的接口,允许你配置客户端以处理不同的请求,为程序增添了更大的灵活性。Singleton模式为提供对象的单一入口提供了帮助。AbstractFactory和FactoryMethod模式在功能上比较类似,都是用来处理对象的创建的,但应用在不同的层面上。在创建型模式中,还有Builder模式和Prototype模式,这儿不打算详细的讨论了,简单的说,Builder模式用来处理对象创建的细节。在两个工厂模式中都没有涉及到对象创建的具体细节,都是通过接口来返回一个给定类型的对象。而Builder模式则需要对创建一个给定类型对象的过程进行建模。这对创建复杂对象时很有用,使得创建对象的算法独立于对象各个组成部分的创建。而Prototype模式使用原型机制,通过创建简单原型的拷贝来创建对象。

上一篇:从Java类库看设计模式(3)

下一篇:从Java类库看设计模式(1)