行为类模式对比

Published on 2016 - 09 - 07

行为类模式包括责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式。该组真可谓是人才济济,高手如云。行为类模式的11个模式基本上都是大家耳熟能详的,而且它们之间还有很多的相似点,特别是一些扩展部分就更加相似了,我们挑选几个比较重要的模式进行对比说明。

命令模式VS策略模式

命令模式和策略模式的类图确实很相似,只是命令模式多了一个接收者(Receiver)角色。它们虽然同为行为类模式,但是两者的区别还是很明显的。策略模式的意图是封装算法,它认为“算法”已经是一个完整的、不可拆分的原子业务(注意这里是原子业务,而不是原子对象),即其意图是让这些算法独立,并且可以相互替换,让行为的变化独立于拥有行为的客户;而命令模式则是对动作的解耦,把一个动作的执行分为执行对象(接收者角色)、执行行为(命令角色),让两者相互独立而不相互影响。

我们从一个相同的业务需求出发,按照命令模式和策略模式分别设计出一套实现,来看看它们的侧重点有什么不同。zip和gzip文件格式相信大家都很熟悉,它们是两种不同的压缩格式,我们今天就来对一个目录或文件实现两种不同的压缩方式:zip压缩和gzip压缩(这里的压缩指的是压缩和解压缩两种对应的操作行为,下同)。实现这两种压缩格式有什么意义呢?有意义!一是zip格式(.zip后缀)是Windows操作系统常用的压缩格式,gzip格式(.gz后缀)是*nix系统常用的压缩格式;二是JDK提供了对zip和gzip文件的操作包,非常容易实现文件的压缩和解压缩操作。

下面我们来实现不同格式的压缩和解压缩功能。

策略模式实现压缩算法

使用策略模式实现压缩算法非常简单,也是非常标准的,类图如图1所示。

在类图中,我们的侧重点是zip压缩算法和gzip压缩算法可以互相替换,一个文件或者目录可以使用zip压缩,也可以使用gzip压缩,选择哪种压缩算法是由高层模块(实际操作者)决定的。我们来看一下代码实现。先看抽象的压缩算法,如代码清单1所示。

public interface Algorithm {
     //压缩算法
     public boolean compress(String source,String to);
     //解压缩算法
     public boolean uncompress(String source,String to);
}

每一个算法要实现两个功能:压缩和解压缩,传递进来一个绝对路径source,compress把它压缩到to目录下,uncompress则进行反向操作——解压缩,这两个方法一定要成对地实现,为什么呢?用gzip解压缩算法能解开zip格式的压缩文件吗?我们分别来看两种不同格式的压缩算法,zip、gzip压缩算法分别如代码清单2、代码清单3所示。

public class Zip implements Algorithm {
     //zip格式的压缩算法
     public boolean compress(String source, String to) {
             System.out.println(source + " --> " +to + " ZIP压缩成功!");
             return true;
     }
    //zip格式的解压缩算法
     public boolean uncompress(String source,String to){
             System.out.println(source + " --> " +to + " ZIP解压缩成功!");
             return true;
     }
}
public class Gzip implements Algorithm {
     //gzip的压缩算法
     public boolean compress(String source, String to) {
             System.out.println(source + " --> " +to + " GZIP压缩成功!");
             return true;
     }
     //gzip解压缩算法
     public boolean uncompress(String source,String to){
             System.out.println(source + " --> " +to + " GZIP解压缩成功!");
             return true;
     }
}

这两种压缩算法实现起来都很简单,Java对此都提供了相关的API操作,这里就不再提供详细的编写代码,读者可以参考JDK自己进行实现,或者上网搜索一下,网上有太多类似的源代码。

两个具体的算法实现了同一个接口,完全遵循依赖倒转原则。我们再来看环境角色,如代码清单4所示。

public class Context {
     //指向抽象算法
     private Algorithm al;
     //构造函数传递具体的算法
     public Context(Algorithm _al){
             this.al = _al;
     }
     //执行压缩算法
     public boolean compress(String source,String to){
             return al.compress(source, to);
     }
     //执行解压缩算法
     public boolean uncompress(String source,String to){
             return al.uncompress(source, to);
     }
}

也是非常简单,指定一个算法,执行该算法,一个标准的策略模式就编写完毕了。请读者注意,这里虽然有两个算法Zip和Gzip,但是对调用者来说,这两个算法没有本质上的区别,只是“形式”上不同,什么意思呢?从调用者来看,使用哪一个算法都无所谓,两者完全可以互换,甚至用一个算法替代另外一个算法。我们继续看调用者是如何调用的,如代码清单5所示。

public class Client {
     public static void main(String[] args) {
             //定义环境角色
             Context context;
             //对文件执行zip压缩算法
             System.out.println("========执行算法========");
             context = new Context(new Zip());
             /*
              *算法替换
              * context = new Context(new Gzip());
              * 
              */
             //执行压缩算法
             context.compress("c:\\windows","d:\\windows.zip");
             //执行解压缩算法
             context.uncompress("c:\\windows.zip","d:\\windows");
     }
}

运行结果如下所示:

=======执行算法========
c:\windows --> d:\windows.zip ZIP 压缩成功!
c:\windows.zip --> d:\windows ZIP 解压缩成功!

要使用gzip算法吗?在客户端(Client)上把注释删掉就可以了,其他的模块根本不受任何影响,策略模式关心的是算法是否可以相互替换。策略模式虽然简单,但是在项目组使用得非常多,可以说随手拈来就是一个策略模式。

命令模式实现压缩算法

命令模式的主旨是封装命令,使请求者与实现者解耦。例如,到饭店点菜,客人(请求者)通过服务员(调用者)向厨师(接收者)发送了订单(行为的请求),该例子就是通过封装命令来使请求者和接收者解耦。我们继续来看压缩和解压缩的例子,怎么使用命令模式来完成该需求呢?我们先画出类图,如图2所示。

类图看着复杂,但是还是一个典型的命令模式,通过定义具体命令完成文件的压缩、解压缩任务,注意我们这里对文件的每一个操作都是封装好的命令,对于给定的请求,命令不同,处理的结果当然也不同,这就是命令模式要强调的。我们先来看抽象命令,如代码清单6所示。

public abstract class AbstractCmd {
     //对接收者的引用
     protected IReceiver zip = new ZipReceiver();
     protected IReceiver gzip = new GzipReceiver();
     //抽象方法,命令的具体单元
     public abstract boolean execute(String source,String to);
}

抽象命令定义了两个接收者的引用:zip接收者和gzip接收者,大家可以想象一下这两个“受气包”,它们完全是受众,人家让它干啥它就干啥,具体使用哪个接收者是命令决定的。具体命令有4个:zip压缩、zip解压缩、gzip压缩、gzip解压缩,分别如代码清单7、8、9、10所示。

public class ZipCompressCmd extends AbstractCmd {
     public boolean execute(String source,String to) {
             return super.zip.compress(source, to);
     }
}
public class ZipUncompressCmd extends AbstractCmd {
     public boolean execute(String source,String to) {
             return super.zip.uncompress(source, to);
     }
}
public class GzipCompressCmd extends AbstractCmd {
     public boolean execute(String source,String to) {
             return super.gzip.compress(source, to);
     }
}
public class GzipUncompressCmd extends AbstractCmd {
     public boolean execute(String source,String to) {
             return super.gzip.uncompress(source, to);
     }
}

它们非常简单,都只有一个方法,坚决地执行命令,使用了委托的方式,由接收者来实现。我们再来看抽象接收者,如代码清单11所示。

public interface IReceiver {
     //压缩
     public boolean compress(String source,String to);
     //解压缩
     public boolean uncompress(String source,String to);
}

抽象接收者与策略模式的抽象策略完全相同,具体的实现也完全相同,只是类名做了改动,我们先来看zip压缩的实现,如代码清单12所示。

public class ZipReceiver implements IReceiver {
     //zip格式的压缩算法
     public boolean compress(String source, String to) {
             System.out.println(source + " --> " +to + " ZIP压缩成功!");
             return true;
     }
     //zip格式的解压缩算法
     public boolean uncompress(String source,String to){
             System.out.println(source + " --> " +to + " ZIP解压缩成功!");
             return true;
     }
}

这就是一个具体动作执行者,它在策略模式中是一个具体的算法,关心的是是否可以被替换;而在命令模式中,它则是一个具体、真实的命令执行者。我们再来看gzip接收者,如代码清单13所示。

public class GzipReceiver implements IReceiver {
     //gzip的压缩算法
     public boolean compress(String source, String to) {
             System.out.println(source + " --> " +to + " GZIP压缩成功!");
             return true;          
     }
     //gzip解压缩算法
     public boolean uncompress(String source,String to){
             System.out.println(source + " --> " +to + " GZIP解压缩成功!");
             return true;
     }
}

大家可以这样思考这个问题,接收者就是厨房的厨师,具体要哪个厨师做这道菜则是餐馆的规章制度已经明确的,你让专做粤菜的师傅做一个剁椒鱼头,能做出好菜吗?在命令模式中,就是在抽象命令中定义了接收者的引用,然后在具体的实现类中确定要让哪个接收者进行处理。这就好比是客人点菜:我要一个剁椒鱼头,这就是一个命令,然后服务员(Inovker)接收到这个命令后,就开始执行,把这个命令指定给具体的执行者执行。

当然了,接收者这部分还可以这样设计,即按照职责设计接收者,比如压缩接收者、解压缩接收者,但接口需要稍稍改动,如代码清单14所示。

public interface IReceiver {
     //执行zip命令
     public boolean zipExec(String source,String to);
     //执行gzip命令
     public boolean gzipExec(String source,String to);
}

接收者接口只是定义了每个接收者都必须完成zip和gzip相关的两个逻辑,有多少个职责就有多少个实现类。我们这里只有两个职责:压缩和解压缩,分别如代码清单15、16所示。

public class CompressReceiver implements IReceiver {
     //执行gzip压缩命令
     public boolean gzipExec(String source, String to) {
             System.out.println(source + " --> " +to + " GZIP压缩成功!");
             return true;
     }
     //执行zip压缩命令
     public boolean zipExec(String source, String to) {
             System.out.println(source + " --> " +to + " ZIP压缩成功!");
             return true;
     }
}
public class UncompressReceiver implements IReceiver {
     //执行gzip解压缩命令
     public boolean gzipExec(String source, String to) {
             System.out.println(source + " --> " +to + " GZIP解压缩成功!");
             return true;
     }
     //执行zip解压缩命令
     public boolean zipExec(String source, String to) {
             System.out.println(source + " --> " +to + " ZIP解压缩成功!");
             return true;
     }
}

剩下的工作就是对抽象命令、具体命令稍作修改,这里不再赘述。为什么要在这里增加一个分支描述呢?这是为了与策略模式对比,在命令模式中,我们可以把接收者设计得与策略模式的算法相同,也可以不相同。我们按照职责设计的接口就不适用于策略模式,不可能封装一个叫做压缩的算法类,然后在类中提供两种不同格式的压缩功能,这违背了策略模式的意图——封装算法,为什么呢?如果要增加一个rar压缩算法,该怎么办呢?修改抽象算法?这是绝对不允许的!那为什么命令模式就是允许的呢?因为命令模式着重于请求者和接收者解耦,你管我接收者怎么变化,只要不影响请求者就成,这才是命令模式的意图。

命令、接收者都具备了,我们再来封装一个命令的调用者,如代码清单17所示。

public class Invoker {
     //抽象命令的引用
     private AbstractCmd cmd;
     public Invoker(AbstractCmd _cmd){
             this.cmd = _cmd;
     }
     //执行命令
     public boolean execute(String source,String to){
             return cmd.execute(source, to);
     }
}

调用者非常简单,只负责把命令向后传递,当然这里也可以进行一定的拦截处理,我们暂时用不到就不做处理了。我们来看场景类是如何描述这个场景的,如代码清单18所示。

public class Client {
     public static void main(String[] args) {
             //定义一个命令,压缩一个文件
             AbstractCmd cmd = new ZipCompressCmd();
             /*
              * 想换一个?执行解压命令
              * AbstractCmd cmd = new ZipUncompressCmd();
              */
             //定义调用者
             Invoker invoker = new Invoker(cmd);
             //我命令你对这个文件进行压缩
             System.out.println("========执行压缩命令========");
             invoker.execute("c:\\windows", "d:\\windows.zip");
     }
}

想新增一个命令?当然没有问题,只要重新定义一个命令就成,命令改变了,高层模块只要调用它就成。请注意,这里的程序还有点欠缺,没有与文件的后缀名绑定,不应该出现使用zip压缩命令产生一个.gzip后缀的文件名,读者在实际应用中可以考虑与文件后缀名之间建立关联。

通过以上例子,我们看到命令模式也实现了文件的压缩、解压缩的功能,它的实现是关注了命令的封装,是请求者与执行者彻底分开,看看我们的程序,执行者根本就不用了解命令的具体执行者,它只要封装一个命令——“给我用zip格式压缩这个文件”就可以了,具体由谁来执行,则由调用者负责,如此设计后,就可以保证请求者和执行者之间可以相互独立,各自发展而不相互影响。

同时,由于是一个命令模式,接收者的处理可以进行排队处理,在排队处理的过程中,可以进行撤销处理,比如客人点了一个菜,厨师还没来得及做,那要撤回很简单,撤回也是命令,这是策略模式所不能实现的。

小结

策略模式和命令模式相似,特别是命令模式退化时,比如无接收者(接收者非常简单或者接收者是一个Java的基础操作,无需专门编写一个接收者),在这种情况下,命令模式和策略模式的类图完全一样,代码实现也比较类似,但是两者还是有区别的。

  • 关注点不同

策略模式关注的是算法替换的问题,一个新的算法投产,旧算法退休,或者提供多种算法由调用者自己选择使用,算法的自由更替是它实现的要点。换句话说,策略模式关注的是算法的完整性、封装性,只有具备了这两个条件才能保证其可以自由切换。

命令模式则关注的是解耦问题,如何让请求者和执行者解耦是它需要首先解决的,解耦的要求就是把请求的内容封装为一个一个的命令,由接收者执行。由于封装成了命令,就同时可以对命令进行多种处理,例如撤销、记录等。

  • 角色功能不同

在我们的例子中,策略模式中的抽象算法和具体算法与命令模式的接收者非常相似,但是它们的职责不同。策略模式中的具体算法是负责一个完整算法逻辑,它是不可再拆分的原子业务单元,一旦变更就是对算法整体的变更。

而命令模式则不同,它关注命令的实现,也就是功能的实现。例如我们在分支中也提到接收者的变更问题,它只影响到命令族的变更,对请求者没有任何影响,从这方面来说,接收者对命令负责,而与请求者无关。命令模式中的接收者只要符合六大设计原则,完全不用关心它是否完成了一个具体逻辑,它的影响范围也仅仅是抽象命令和具体命令,对它的修改不会扩散到模式外的模块。

当然,如果在命令模式中需要指定接收者,则需要考虑接收者的变化和封装,例如一个老顾客每次吃饭都点同一个厨师的饭菜,那就必须考虑接收者的抽象化问题。

  • 使用场景不同

策略模式适用于算法要求变换的场景,而命令模式适用于解耦两个有紧耦合关系的对象场合或者多命令多撤销的场景。

策略模式VS状态模式

在行为类设计模式中,状态模式和策略模式是亲兄弟,两者非常相似,我们先看看两者的通用类图,把两者放在一起比较一下,如图3所示。

两个类图非常相似,都是通过Context类封装一个具体的行为,都提供了一个封装的方法,是高扩展性的设计模式。但根据两者的定义,我们发现两者的区别还是很明显的:策略模式封装的是不同的算法,算法之间没有交互,以达到算法可以自由切换的目的;而状态模式封装的是不同的状态,以达到状态切换行为随之发生改变的目的。这两种模式虽然都有变换的行为,但是两者的目标却是不同的。我们举例来说明两者的不同点。

人只要生下来就有工作可做,人在孩童时期的主要工作就是玩耍(学习只是在人类具有了精神意识行为后才产生的);成人时期的主要工作是养活自己,然后为社会做贡献;老年时期的主要工作就是享受天伦之乐。按照策略模式来分析,这三种不同的工作方式就是三个不同的具体算法,随着时光的推移工作内容随之更替,这和对一堆数组的冒泡排序、快速排序、插入排序一样,都是一系列的算法;而按照状态模式进行设计,则认为人的状态(孩童、成人、老人)产生了不同的行为结果,这里的行为都相同,都是工作,但是它们的实现方式确实不同,也就是产生的结果不同,看起来就像是类改变了。

策略模式实现人生

下面按照策略模式进行设计,先来看类图,如图4所示。

这是非常典型的策略模式,没有太多的玄机,它定义了一个工作算法,然后有三个实现类:孩童工作、成年人工作和老年人工作。我们来看代码,首先看抽象工作算法,如代码清单19所示。

public abstract class WorkAlgorithm {
     //每个年龄段都必须完成的工作
     public abstract void work();
}

无论如何,每个算法都必须实现work方法,完成对工作内容的定义,三个具体的工作算法如代码清单20、21、22所示。

public class ChildWork extends WorkAlgorithm {
     //小孩的工作
     @Override
     public void work() {
             System.out.println("儿童的工作是玩耍!");
     }
}
public class AdultWork extends WorkAlgorithm {
     //成年人的工作
     @Override
     public void work() {
             System.out.println("成年人的工作就是先养活自己,然后为社会做贡献!");
     }
}
public class OldWork extends WorkAlgorithm {
     //老年人的工作
     @Override
     public void work() {
             System.out.println("老年人的工作就是享受天伦之乐!");
     }
}

我们再来看环境角色,如代码清单23所示。

public class Context {
     private WorkAlgorithm workMethod;
     public WorkAlgorithm getWork() {
             return workMethod;
     }
     public void setWork(WorkAlgorithm work) {
             this.workMethod = work;
    }
     //每个算法都有必须具有的功能
     public void work(){
             workMethod.work();
     }
}

我们编写一个场景类来模拟该场景,如代码清单24所示。

public class Client {
     public static void main(String[] args) {
             //定义一个环境角色
             Context context=new Context();
             System.out.println("====儿童的主要工作=====");
             context.setWork(new ChildWork());
             context.work();
             System.out.println("\n====成年人的主要工作=====");
             context.setWork(new AdultWork());
             context.work();
             System.out.println("\n====老年人的主要工作=====");
             context.setWork(new OldWork());
             context.work();     
     }
}

在这里我们把每个不同的工作内容作为不同的算法,分别是孩童工作、成年人工作、老年人工作算法,然后在场景类中根据不同的年龄段匹配不同的工作内容,其运行结果如下所示:

====儿童的主要工作=====
儿童的工作是玩耍!
====成年人的主要工作=====
成年人的工作就是先养活自己,然后为社会做贡献!
====老年人的主要工作=====
老年人的工作就是享受天伦之乐!

通过采用策略模式我们实现了“工作”这个策略的三种不同算法,算法可以自由切换,到底用哪个算法由调用者(高层模块)决定。策略模式的使用重点是算法的自由切换——老的算法退休,新的算法上台,对模块的整体功能没有非常大的改变,非常灵活。而如果想要增加一个新的算法,比如未出生婴儿的工作,只要继承WorkAlgorithm就可以了。

状态模式实现人生

我们再来看看使用状态模式是如何实现该需求的。随着时间的变化,人的状态变化了,同时引起了人的工作行为改变,完全符合状态模式。我们来看类图,如图5所示。

这与策略模式非常相似,基本上就是几个类名称的修改而已,但是其中蕴藏的玄机就大了,看看代码你就会明白。我们先来看抽象状态类,如代码清单25所示。

public abstract class HumanState {
     //指向一个具体的人
     protected Human human;
     //设置一个具体的人
     public void setHuman(Human _human){
             this.human = _human;
     }
     //不管人是什么状态都要工作
     public abstract void work();
}

抽象状态定义了一个具体的人(human)必须进行工作(work),但是一个人在哪些状态下完成哪些工作则是由子类来实现的。我们先来看孩童状态,如代码清单26所示。

public class ChildState extends HumanState{
     //儿童的工作就是玩耍
     public void work(){
             System.out.println("儿童的工作是玩耍!");
             super.human.setState(Human.ADULT_STATE);
     }
}

ChildState类代表孩童状态,在该状态下的工作就是玩耍。读者看着可能有点惊奇,在work方法中为什么要设置下一个状态?因为我们的状态变化都是单方向的,从孩童到成年人,然后到老年人,每个状态转换到其他状态只有一个方向,因此会在这里看到work有两个职责:完成工作逻辑和定义下一状态。

我们再来看成年人状态和老年人状态,分别如代码清单27、28所示。

public class AdultState extends HumanState {
     //成年人的工作就是先养活自己,然后为社会做贡献
     @Override
     public void work() {
             System.out.println("成年人的工作就是先养活自己,然后为社会做贡献!");
             super.human.setState(Human.OLD_STATE);
     }
}
public class OldState extends HumanState {
     //老年人的工作就是享受天伦之乐
     @Override
     public void work() {
          System.out.println("老年人的工作就是享受天伦之乐!");
     }
}

每一个HumanState的子类都代表了一种状态,虽然实现的方法名work都相同,但是实现的内容却不同,也就是在不同的状态下行为随之改变。我们来看环境角色是如何处理行为随状态的改变而改变的,如代码清单29所示。

public class Human {
     //定义人类都具备哪些状态
     public static final HumanState CHIILD_STATE = new ChildState();
     public static final HumanState ADULT_STATE = new AdultState();
     public static final HumanState OLD_STATE = new OldState();
     //定义一个人的状态
     private HumanState state;
     //设置一个状态
     public void setState(HumanState _state){
             this.state = _state;
             this.state.setHuman(this);
     }
     //人类的工作
     public void work(){
             this.state.work();
     }
}

定义一个Human类代表人类,也就是状态模式中的环境角色,每个人都会经历从孩童到成年人再到老年人这样一个状态过渡(当然了,老顽童周伯通的情况我们就没有考虑进来),随着状态的改变,行为也改变。我们来看场景类,如代码清单30所示。

public class Client {
     public static void main(String[] args) {
             //定义一个普通的人
             Human human = new Human();
             //设置一个人的初始状态
             human.setState(new ChildState());
             System.out.println("====儿童的主要工作=====");
             human.work();
             System.out.println("\n====成年人的主要工作=====");
             human.work();
             System.out.println("\n====老年人的主要工作=====");
             human.work();
     }
}

运行结果如下所示:

====儿童的主要工作=====
儿童的工作是玩耍!
====成年人的主要工作=====
成年人的工作就是先养活自己,然后为社会做贡献!
====老年人的主要工作=====
老年人的工作就是享受天伦之乐!

运行结果与策略模式相同,但是两者的分析角度是大相径庭的。策略模式的实现是通过分析每个人的工作方式的不同而得出三个不同的算法逻辑,状态模式则是从人的生长规律来分析,每个状态对应了不同的行为,状态改变后行为也随之改变。从以上示例中我们也可以看出,对于相同的业务需求,有很多种实现方法,问题的重点是业务关注的是什么,是人的生长规律还是工作逻辑?找准了业务的焦点,才能选择一个好的设计模式。

小结

从例子中我们可以看出策略模式和状态模式确实非常相似,称之为亲兄弟亦不为过,但是这两者还是存在着非常大的差别,而且也是很容易区分的。

  • 环境角色的职责不同

两者都有一个叫做Context环境角色的类,但是两者的区别很大,策略模式的环境角色只是一个委托作用,负责算法的替换;而状态模式的环境角色不仅仅是委托行为,它还具有登记状态变化的功能,与具体的状态类协作,共同完成状态切换行为随之切换的任务。

  • 解决问题的重点不同

策略模式旨在解决内部算法如何改变的问题,也就是将内部算法的改变对外界的影响降低到最小,它保证的是算法可以自由地切换;而状态模式旨在解决内在状态的改变而引起行为改变的问题,它的出发点是事物的状态,封装状态而暴露行为,一个对象的状态改变,从外界来看就好像是行为改变。

  • 解决问题的方法不同

策略模式只是确保算法可以自由切换,但是什么时候用什么算法它决定不了;而状态模式对外暴露的是行为,状态的变化一般是由环境角色和具体状态共同完成的,也就是说状态模式封装了状态的变化而暴露了不同的行为或行为结果。

  • 应用场景不同

两者都能实现前面例子中的场景,但并不表示两者的应用场景相同,这只是为了更好地展示出两者的不同而设计的一个场景。我们来想一下策略模式和状态模式的使用场景有什么不同,策略模式只是一个算法的封装,可以是一个有意义的对象,也可以是一个无意义的逻辑片段,比如MD5加密算法,它是一个有意义的对象吗?不是,它只是我们数学上的一个公式的相关实现,它是一个算法,同时DES算法、RSA算法等都是具体的算法,也就是说它们都是一个抽象算法的具体实现类,从这点来看策略模式是一系列平行的、可相互替换的算法封装后的结果,这就限定了它的应用场景:算法必须是平行的,否则策略模式就封装了一堆垃圾,产生了“坏味道”。状态模式则要求有一系列状态发生变化的场景,它要求的是有状态且有行为的场景,也就是一个对象必须具有二维(状态和行为)描述才能采用状态模式,如果只有状态而没有行为,则状态的变化就失去了意义。

  • 复杂度不同

通常策略模式比较简单,这里的简单指的是结构简单,扩展比较容易,而且代码也容易阅读。当然,一个具体的算法也可以写得很复杂,只有具备很高深的数学、物理等知识的人才可以看懂,这也是允许的,我们只是说从设计模式的角度来分析,它是很容易被看懂的。而状态模式则通常比较复杂,因为它要从两个角色看到一个对象状态和行为的改变,也就是说它封装的是变化,要知道变化是无穷尽的,因此相对来说状态模式通常都比较复杂,涉及面很多,虽然也很容易扩展,但是一般不会进行大规模的扩张和修正。

观察者模式VS责任链模式

为什么要把观察者模式和责任链模式放在一起对比呢?看起来这两个模式没有太多的相似性,真没有吗?回答是有。我们在观察者模式中也提到了触发链(也叫做观察者链)的问题,一个具体的角色既可以是观察者,也可以是被观察者,这样就形成了一个观察者链。这与责任链模式非常类似,它们都实现了事务的链条化处理,比如说在上课的时候你睡着了,打鼾声音太大,盖过了老师讲课声音,老师火了,捅到了校长这里,校长也处理不了,然后告状给你父母,于是你的魔鬼日子来临了,这是责任链模式,老师、校长、父母都是链中的一个具体角色,事件(你睡觉)在链中传递,最终由一个具体的节点来处理,并将结果反馈给调用者(你挨揍了)。那什么是触发链?你还是在课堂上睡觉,还是打鼾声音太大,老师火了,但是老师掏出个扩音器来讲课,于是你睡不着了,同时其他同学的耳朵遭殃了,这就是触发链,其中老师既是观察者(相对你)也是被观察者(相对其他同学),事件从“你睡觉”到老师这里转化为“扩音器放大声音”,这也是一个链条结构,但是链结构中传递的事件改变了。

我们还是以一个具体的例子来说明两者的区别,DNS协议相信大家都听说过,只要在“网络设置”中设置一个DNS服务器地址就可以把我们需要的域名翻译成IP地址。DNS协议还是比较简单的,传递过去一个域名以及记录标志(比如是要A记录还是要MX记录),DNS就开始查找自己的记录树,找到后把IP地址反馈给请求者。我们可以在Windows操作系统中了解一下DNS解析过程,在DOS窗口下输入nslookup命令后,结果如图6所示。

我们的意图就是要DNS服务器192.168.10.1解析出www.xxx.com.cn的IP地址,DNS服务器是如何工作的呢?图6中的192.168.10.1这个DNS Server存储着全球的域名和IP之间的对应关系吗?不可能,目前全球的域名数量是1.7亿个,如此庞大的数字,每个DNS服务器都存储一份,还怎么快速响应?DNS解析的响应时间一般都是毫秒级别的,如此高的性能要求还怎么让DNS服务器遍地开花呢?而且域名变更非常频繁,数据读写的量也非常大,不可能每个DNS服务器都保留这1.7亿数据,那么是怎么设计的呢?DNS协议还是很聪明的,它规定了每个区域的DNS服务器(Local DNS)只保留自己区域的域名解析,对于不能解析的域名,则提交上级域名解析器解析,最终由一台位于美国洛杉矶的顶级域名服务器进行解析,返回结果。很明显这是一个事务的链结构处理,我们使用两种模式来实现该解析过程。

责任链模式实现DNS解析过程

本小节我们用责任链模式来实现DNS解析过程。首先我们定义一下业务场景,这里有三个DNS服务器:上海DNS服务器(区域服务器)、中国顶级DNS服务器(父服务器)、全球顶级DNS服务器,其示意图如图7所示。

假设有请求者发出请求,由上海DNS进行解析,如果能够解析,则返回结果,若不能解析,则提交给父服务器(中国顶级DNS)进行解析,若还不能解析,则提交到全球顶级DNS进行解析,若还不能解析呢?那就返回该域名无法解析。确实,这与责任链模式非常相似,我们把这一过程抽象一下,类图如图8所示。

我们来解释一下类图,Recorder是一个BO对象,它记录DNS服务器解析后的结果,包括域名、IP地址、属主(即由谁解析的),除此之外还有getter/setter方法。DnsServer抽象类中的resolve方法是一个基本方法,每个DNS服务器都必须拥有该方法,它对DNS进行解析,如何解析呢?具体是由echo方法来实现的,每个DNS服务器独自实现。类图还是比较简单的,我们首先看一下解析记录Recorder类,如代码清单31所示。

public class Recorder {
     //域名
     private String domain;
     //IP地址
     private String ip;
     //属主
     private String owner;
     public String getDomain() {
             return domain;
     }
     public void setDomain(String domain) {
             this.domain = domain;
    }
     public String getIp() {
             return ip;
     }
     public void setIp(String ip) {
             this.ip = ip;
     }
     public String getOwner() {
             return owner;
     }
     public void setOwner(String owner) {
             this.owner = owner;
     }
     //输出记录信息
     @Override
     public String toString(){
             String str= "域名:" + this.domain;
             str = str + "\nIP地址:" + this.ip;
             str = str + "\n解析者:" + this.owner;
             return str;
     }
}

为什么要覆写toString方法呢?是为了打印展示的需要,可以直接把Recorder的信息打印出来。我们再来看抽象域名服务器,如代码清单32所示。

public abstract class DnsServer {
     //上级DNS是谁
     private DnsServer upperServer;
     //解析域名
     public final Recorder resolve(String domain){
             Recorder recorder=null;
             if(isLocal(domain)){//是本服务器能解析的域名
                     recorder = echo(domain);
             }else{//本服务器不能解析
                     //提交上级DNS进行解析
                     recorder = upperServer.resolve(domain);
             }
             return recorder;
     }
     //指向上级DNS
    public void setUpperServer(DnsServer _upperServer){
             this.upperServer = _upperServer;
     }
     //每个DNS都有一个数据处理区(ZONE),检查域名是否在本区中
     protected abstract boolean isLocal(String domain);
     //每个DNS服务器都必须实现解析任务
     protected Recorder echo(String domain){
             Recorder recorder = new Recorder();
             //获得IP地址
             recorder.setIp(genIpAddress());
             recorder.setDomain(domain);
             return recorder;
     }
     //随机产生一个IP地址,工具类
     private String genIpAddress(){
             Random rand = new Random();
             String address = rand.nextInt(255) + "." + rand.nextInt(255) + "."+ rand.nextInt(255) + "."+ rand.nextInt(255);
             return address;
     }
}

在该类中有一个方法——genIpAddress方法——没有在类图中展现出来,它用于实现随机生成IP地址,这是我们为模拟DNS解析场景而建立的一个虚拟方法,在实际的应用中是不可能出现的。抽象DNS服务器编写完成,我们再来看具体的DNS服务器,先看上海的DNS服务器,如代码清单33所示。

public class SHDnsServer extends DnsServer {
     @Override
     protected Recorder echo(String domain) {
             Recorder recorder= super.echo(domain);
             recorder.setOwner("上海DNS服务器");
             return recorder;
     }
     //定义上海的DNS服务器能处理的级别
     @Override
     protected boolean isLocal(String domain) {
             return domain.endsWith(".sh.cn");
     }
}

为什么要覆写echo方法?各具体的DNS服务器实现自己的解析过程,属于个性化处理,它代表的是每个DNS服务器的不同处理逻辑。还要注意一下,我们在这里做了一个简化处理,所有以".sh.cn"结尾的域名都由上海DNS服务器解析。其他的中国顶级DNS和全球顶级DNS实现过程类似,如代码清单34、35所示。

public class ChinaTopDnsServer extends DnsServer {
     @Override
     protected Recorder echo(String domain) {
                Recorder recorder = super.echo(domain);
                recorder.setOwner("中国顶级DNS服务器");
                return recorder;
     }
     @Override
     protected boolean isLocal(String domain) {
                return domain.endsWith(".cn");
     }
}
public class TopDnsServer extends DnsServer {
     @Override
     protected Recorder echo(String domain) {
             Recorder recorder = super.echo(domain);
             recorder.setOwner("全球顶级DNS服务器");
             return recorder;
     }
     @Override
     protected boolean isLocal(String domain) {
             //所有的域名最终的解析地点
             return true;
     }
}

所有的DNS服务器都准备好了,下面我们写一个客户端来模拟一下IP地址是怎么解析的,如代码清单36所示。

public class Client {
     public static void main(String[] args) throws Exception {
             //上海域名服务器
             DnsServer sh = new SHDnsServer();
             //中国顶级域名服务器
             DnsServer china = new ChinaTopDnsServer();
             //全球顶级域名服务器
             DnsServer top = new TopDnsServer();
             //定义查询路径
             china.setUpperServer(top);
             sh.setUpperServer(china);
             //解析域名
             System.out.println("=====域名解析模拟器=====");
             while(true){
                     System.out.print("\n请输入域名(输入N退出):");
                     String domain = (new BufferedReader(new InputStreamReader (System.in))).readLine();
                     if(domain.equalsIgnoreCase("n")){
                             return;
                     }
                     Recorder recorder = sh.resolve(domain);
                     System.out.println("----DNS服务器解析结果----");
                     System.out.println(recorder);               
             }
     }
}

我们来模拟一下,运行结果如下所示:

=====域名解析模拟器=====
请输入域名(输入N退出):www.xxx.sh.cn
----DNS服务器解析结果----
域名:www. xxx.sh.cn
IP地址:69.224.162.154
解析者:上海DNS服务器
请输入域名(输入N退出):www. xxx.com.cn
----DNS服务器解析结果----
域名:www. xxx.com.cn
IP地址:51.28.66.140
解析者:中国顶级DNS服务器
请输入域名(输入N退出):www. xxx.com
----DNS服务器解析结果----
域名:www. xxx.com
IP地址:73.247.80.117
解析者:全球顶级DNS服务器
请输入域名(输入N退出):n

请注意看运行结果,以".sh.cn"结尾的域名确实由上海DNS服务器解析了,以".cn"结尾的域名由中国顶级DNS服务器解析了,其他域名都由全球顶级DNS服务器解析。这个模拟过程看起来很完整,它完全就是责任链模式的一个具体应用,把一个请求放置到链中的首节点,然后由链中的某个节点进行解析并将结果反馈给调用者。但是,我可以负责任地告诉你:这个解析过程是有缺陷的,什么缺陷?后面会说明。

触发链模式实现DNS解析过程

上面说到使用责任链模式模拟DNS解析过程是有缺陷的,究竟有什么缺陷?大家是不是觉得这个解析过程很完美了,没什么问题了?那说明你对DNS协议了解得还不太深入。我们来做一个实验,在dos窗口下输入nslookup命令,然后输入多个域名,注意观察返回值有哪些数据是相同的。可以看出,解析者都相同,都是由同一个DNS服务器解析的,准确地说都是由本机配置的DNS服务器做的解析。这与我们上面的模拟过程是不相同的,看看我们模拟的过程,对请求者来说,".sh.cn"是由区域DNS解析的,".com"却是由全球顶级DNS解析的,与真实的过程不相同,这是怎么回事呢?

肯定地说,采用责任链模式模拟DNS解析过程是不完美的,或者说是有缺陷的,怎么来修复这个缺陷呢?我们先来看看真实的DNS解析过程,如图9所示。

解析一个域名的完整路径如图9中的标号①~⑥所示,首先由请求者发送一个请求,然后由上海DNS服务器尝试解析,若不能解析再通过路径②转发给中国顶级DNS进行解析,解析后的结果通过路径⑤返回给上海DNS服务器,然后由上海DNS服务器通过路径⑥返回给请求者。同样,若中国顶级DNS不能解析,则通过路径③转由全球顶级DNS进行解析,通过路径④把结果返回给中国顶级DNS,然后再通过路径⑤返回给上海DNS。注意看标号⑥,不管一个域名最终由谁解析,最终反馈到请求者的还是第一个节点,也就是说首节点负责对请求者应答,其他节点都不与请求者交互,而只与自己的左右节点交互。实际上我们的DNS服务器确实是如此处理的,例如本机请求查询一个www.abcdefg.com的域名,上海DNS服务器解析不到这个域名,于是提交到中国顶级DNS服务器,如果中国顶级DNS服务器有该域名的记录,则找到该记录,反馈到上海DNS服务器,上海DNS服务器做两件事务处理:一是响应请求者,二是存储该记录,以备其他请求者再次查询,这类似于数据缓存。

整个场景我们已经清晰,想想看,我们把请求者看成是被观察者,它的行为或属性变更通知了观察者——上海DNS,上海DNS又作为被观察者出现了自己不能处理的行为(行为改变),通知了中国顶级DNS,依次类推,这是不是一个非常标准的触发链?而且还必须是同步的触发,异步触发已经在该场景中失去了意义(读者可以想想为什么)。

分析了这么多,我们用触发链来模拟DNS的解析过程,如图10所示。

与责任链模式很相似,仅仅多了一个Observable父类和Observer接口,但是在实现上这两种模式有非常大的差异。我们先来解释一下抽象DnsServer的作用。

  • 标示声明

表示所有的DNS服务器都具备双重身份:既是观察者也是被观察者,这很重要,它声明所有的服务器都具有相同的身份标志,具有该标志后就可以在链中随意移动,而无需固定在链中的某个位置(这也是链的一个重要特性)。

  • 业务抽象

方法setUpperServer的作用是设置父DNS,也就是设置自己的观察者,update方法不仅仅是一个事件的处理者,也同时是事件的触发者。

我们来看代码,首先是最简单的,Recorder类与责任链模式中的记录相同,这里不再赘述。那我们就先看看该模式的核心抽象DnsServer,如代码清单37所示。

public abstract class DnsServer extends Observable implements Observer {
     //处理请求,也就是接收到事件后的处理
     public void update(Observable arg0, Object arg1) {
             Recorder recorder = (Recorder)arg1;
             //如果本机能解析
             if(isLocal(recorder)){
                     recorder.setIp(genIpAddress());
             }else{//本机不能解析,则提交到上级DNS
                     responsFromUpperServer(recorder);
             }
             //签名
             sign(recorder);
     }
     //作为被观察者,允许增加观察者,这里上级DNS一般只有一个
     public void setUpperServer(DnsServer dnsServer){
             //先清空,然后再增加
             super.deleteObservers();
             super.addObserver(dnsServer);
     }
     //向父DNS请求解析,也就是通知观察者
     private void responsFromUpperServer(Recorder recorder){
             super.setChanged();
             super.notifyObservers(recorder);
     }
     //每个DNS服务器签上自己的名字
     protected abstract void sign(Recorder recorder);
     //每个DNS服务器都必须定义自己的处理级别
     protected abstract boolean isLocal(Recorder recorder);
     //随机产生一个IP地址,工具类
     private String genIpAddress(){
             Random rand = new Random();
             String address = rand.nextInt(255) + "." + rand.nextInt(255) + "."+ rand.nextInt(255) + "."+ rand.nextInt(255);
             return address;
     }
}

注意看一下responseFromUpperServer方法,它只允许设置一个观察者,因为一般的DNS服务器都只有一个上级DNS服务器。sign方法是签名,这个记录是由谁解析出来的,就由各个实现类独自来实现。三个DnsServer的实现类都比较简单,如代码清单38、39、40所示。

public class SHDnsServer extends DnsServer {
     @Override
     protected void sign(Recorder recorder) {
             recorder.setOwner("上海DNS服务器");
     }
    //定义上海的DNS服务器能处理的级别
     @Override
     protected boolean isLocal(Recorder recorder) {
             return recorder.getDomain().endsWith(".sh.cn");
     }
}
public class ChinaTopDnsServer extends DnsServer {
     @Override
     protected void sign(Recorder recorder) {
             recorder.setOwner("中国顶级DNS服务器");
     }
     @Override
     protected boolean isLocal(Recorder recorder) {
             return recorder.getDomain().endsWith(".cn");
     }
}
public class TopDnsServer extends DnsServer {
     @Override
     protected void sign(Recorder recorder) {
             recorder.setOwner("全球顶级DNS服务器");
     }

     @Override
     protected boolean isLocal(Recorder recorder) {
             //所有的域名最终的解析地点
             return true;
     }
}

我们再建立一个场景类模拟一下DNS解析过程,如代码清单41所示。

public class Client {
     public static void main(String[] args) throws Exception {
             //上海域名服务器
             DnsServer sh = new SHDnsServer();
             //中国顶级域名服务器
             DnsServer china = new ChinaTopDnsServer();
             //全球顶级域名服务器
             DnsServer top = new TopDnsServer();
             //定义查询路径
             china.setUpperServer(top);
             sh.setUpperServer(china);
             //解析域名
             System.out.println("=====域名解析模拟器=====");
             while(true){
                     System.out.print("\n请输入域名(输入N退出):");
                     String domain = (new BufferedReader(new InputStreamReader (System.in))).readLine();
                     if(domain.equalsIgnoreCase("n")){
                             return;
                     }
                     Recorder recorder = new Recorder();
                     recorder.setDomain(domain);
                     sh.update(null,recorder);
                     System.out.println("----DNS服务器解析结果----");
                     System.out.println(recorder);               
             }
     }
}

与责任链模式中的场景类很相似。读者请注意sh.update(null,recorder)这句代码,这是我们虚拟了观察者触发动作,完整的做法是把场景类作为一个被观察者,然后设置观察者为上海DNS服务器,再进行测试,其结果完全相同,我们这里为减少代码量采用了简化处理,有兴趣的读者可以扩充实现。

我们来看看运行结果如何,结果如下所示:

=====域名解析模拟器=====
请输入域名(输入N退出):www.xxx.sh.cn
----DNS服务器解析结果----
域名:www.xxx.sh.cn
IP地址:197.15.34.227
解析者:上海DNS服务器
请输入域名(输入N退出):www.xxx.com.cn
----DNS服务器解析结果----
域名:www.xxx.com.cn
IP地址:201.177.148.99
解析者:上海DNS服务器
请输入域名(输入N退出):www.xxx.com
----DNS服务器解析结果----
域名:www.xxx.com
IP地址:251.41.14.230
解析者:上海DNS服务器
请输入域名(输入N退出):n

可以看出,所有的解析结果都是由上海DNS服务器返回的,这才是真正的DNS解析过程。如何知道它是由上海DNS服务器解析的还是由别的DNS服务器解析的呢?很好办,把代码拷贝过去,然后调试跟踪一下就可以了。或者仔细看看代码,理解一下代码逻辑也可以非常清楚地知道它是如何解析的。

再仔细看一下我们的代码逻辑,上下两个节点之间的关系很微妙,很有意思。

  • 下级节点对上级节点顶礼膜拜

比如我们输入的这个域名www.xxx.com,上海域名服务器只知道它是由父节点(中国顶级DNS服务器)解析的,而不知道父节点把该请求转发给了更上层节点(全球顶级DNS服务器),也就是说下级节点关注的是上级节点的响应,只要是上级反馈的结果就认为是上级的。www.xxx.com这个域名最终是由最高节点(全球顶级DNS服务器)解析的,它把解析结果传递给第二个节点(中国顶级DNS服务器)时的签名为“全球顶级DNS服务器”,而第二个节点把请求传递给首节点(上海DNS服务器)时的签名被修改为“中国顶级DNS服务器”。所有从上级节点反馈的响应都认为是上级节点处理的结果,而不追究到底是不是真的是上级节点处理的。

  • 上级节点对下级节点绝对信任

上级节点只对下级节点负责,它不关心下级节点的请求从何而来,只要是下级发送的请求就认为是下级的。还是以www.xxx.com域名为例,当最高节点(全球顶级DNS服务器)获得解析请求时,它认为这个请求是谁的?当然是第二个节点(中国顶级DNS服务器)的,否则它也不会把结果反馈给它,但是这个请求的源头却是首节点(上海DNS服务器)的。

小结

通过对DNS解析过程的实现,我们发现触发链和责任链虽然都是链结构,但是还是有区别的。

  • 链中的消息对象不同

从首节点开始到最终的尾节点,两个链中传递的消息对象是不同的。责任链模式基本上不改变消息对象的结构,虽然每个节点都可以参与消费(一般是不参与消费),类似于“雁过拔毛”,但是它的结构不会改变,比如从首节点传递进来一个String对象或者Person对象,不会到链尾的时候成了int对象或者Human对象,这在责任链模式中是不可能的,但是在触发链模式中是允许的,链中传递的对象可以自由变化,只要上下级节点对传递对象了解即可,它不要求链中的消息对象不变化,它只要求链中相邻两个节点的消息对象固定。

  • 上下节点的关系不同

在责任链模式中,上下节点没有关系,都是接收同样的对象,所有传递的对象都是从链首传递过来,上一节点是什么没有关系,只要按照自己的逻辑处理就成。而触发链模式就不同了,它的上下级关系很亲密,下级对上级顶礼膜拜,上级对下级绝对信任,链中的任意两个相邻节点都是一个牢固的独立团体。

  • 消息的分销渠道不同

在责任链模式中,一个消息从链首传递进来后,就开始沿着链条向链尾运动,方向是单一的、固定的;而触发链模式则不同,由于它采用的是观察者模式,所以有非常大的灵活性,一个消息传递到链首后,具体怎么传递是不固定的,可以以广播方式传递,也可以以跳跃方式传递,这取决于处理消息的逻辑。

参考文档