设计模式之如何掌握责任链

本篇内容主要讲解“设计模式之如何掌握责任链”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“设计模式之如何掌握责任链”吧!

创新互联是专业的凌海网站建设公司,凌海接单;提供成都网站建设、做网站,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行凌海网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!

例子

假设你也"穿越"到了清朝,是会写代码的和珅和中堂,皇上马上要南巡。请你用代码封装并模拟"乾隆下江南"这件事。

你要怎么安排万岁爷的行程?要知道这可是个大工程,中间可不能有差错,一旦出了什么岔子可是要掉脑袋的 ??

但皇上又是性情中人,行程可能经常更改,甚至半路就微服私访。

所以我们在伺候皇上下江南的时候,既得让皇上的行程有序进行,又要尽量适应圣上由于一时兴起而可能做出的变化。

怎么设计呢?如果把皇上的行程都写在一起执行,有两个不好的地方:

行程太多,而且全都事关重大,这么远的路,全都要你一个人打理,哪里一不注意出了乱子,脑袋就要搬家;

行程多,所以增改起来太麻烦,一旦有改动圣上的行程表容易乱。毕竟行程写在一起,好似 一堆乱麻,条理不清。

所以问题来啦,和大人您可怎么排圣上的行程呢?

和大人莫急,看看地图我们就知道,乾隆从北京到杭州要顺序经过直隶、山东、江苏、浙江四省(基本就是现在京沪高铁的路子):

设计模式之如何掌握责任链

这样和大人就可以按省把任务大致划分为四个部分,责成四省的官员们分担这一个大工程,把他们应尽的的责任连成一个有序的链条,然后依次让他们执行伺候皇上的任务。

这样一来解决了行程过于丰富,和大人一个人安排不过来的问题,二来保证了各个步骤的灵活安排(后面的例子讲),三来哪一步出了问题还便于问责(甩锅,否则全是自己的错)。

好了,说了这么多,现在切入技术层面。

设计

Step1:

首先总结一下我们所研究的问题中的名词,来确定大概需要哪些类:

皇帝(乾隆)

行程的管理者(和中堂)

各省官员(具体干活的公仆们)

Step2:

再来确定各个类之间的关系:

最容易看出来的是各省官员是同僚关系,他们都要接待乾隆,只是在皇上南巡的过程中出场顺序和做的具体接待行为不一样,比如:

  • 直隶总督会带乾隆去避暑山庄,

  • 山东巡抚会张罗着皇上祭拜孔庙,

  • 苏州织造让皇上游览园林,

  • 而杭州知州就带着皇上去西湖苏堤。

这里告诉大家 OOD 中一个优化设计的小口诀:变化的抽接口,相同的建模版。

所以我们在这里面对官员们不同的行为,最好把他们抽象成接口或者抽象类,这里我们采用官员(Official) 这个抽象类。

而和大人作为总管,他既要掌握皇帝的动向,又要辖制各省官员,所以在类的层面上和大人(PrimeMinister)这个类就得有指向皇帝(Emperor)和官员列表的引用。

下面上 UML 图。

UML 图

各省同僚:

设计模式之如何掌握责任链

而你和大人,作为乾隆面前的红人,得统筹安排皇帝的行程,既要挟持皇帝,又要掌管各省官员,让他们有序地执行任务:

设计模式之如何掌握责任链

责任链一般都至少有一个被处理的对象,作为参数传入各个步骤,这里的乾隆就是这个被处理(伺候)的对象。

代码

作为官员这个抽象类,我们考虑到实际情况,他要安排一个地方并陪同皇帝参观、游览,其实就是一句话:伺候皇上。

所以他有一个抽象方法 serve,接受皇帝(Emperor)这个对象

@Data public abstract class Official {     protected String title;      protected abstract void serve(Emperor emperor);      @Override     public String toString() {         return title;     } }

这里为了区别不同的官员,我们还给了官员(Official)类一个成员变量 title。

Official 下面有具体实现的类,代表各省官员,他们自己有自己具体的方式去服务吾皇,比如直隶总督,他是这么干的:

public class HebeiOfficial extends Official {      public HebeiOfficial() {         this.title = "直隶总督";     }      @Override     protected void serve(Emperor emperor) {         emperor.play(this, "避暑山庄");     } }

这里在 serve 里面完全让参数"皇帝"自己决定怎么玩,(顺便说句题外话,这种让参数这个"外来的和尚"念经的方式,在各种设计模式里很常见。如果把这里的  Emperor 换成 Comparator,相信很多小伙伴就感觉有点像策略模式了。而且"直隶总督"也可以在皇帝 play 之前或者之后分别做一些事情,这像不像用  JDK 的代理的时候中那个 InvocationHandler 对待 Method 的方式?或者 Spring 中对于 Aspect 的处理?另外在  Visitor 等设计模式中你也能看到这种写法的身影)

其他官员的写法类似,只是换个地方供皇帝游览而已,参见后面的输出结果,这里略。

而作为皇帝,乾隆只管着玩就好,当然了,你和中堂可以安排当地的官员陪同,所以 皇帝类只有一个 play 方法,这里用一个字符串简单表示去游览的地方。

为了防止乾隆南下期间有人在北京"另立新君"(执行 new Emperor()),这个"皇帝"对象的创建过程采用了单例模式,保证整个 JVM  里面就只有这么一个皇上,而且名字叫"乾隆":

public class Emperor {     private static final Emperor INSTANCE = new Emperor("乾隆");     private final String name;      private Emperor(String name) {         this.name = name;     }      public static Emperor getInstance() {         return INSTANCE;     }      public void play(Official official, String place){         System.out.println(official.getTitle() + " 安排 " + name + "皇帝游览了: " + place);     } }

而你,和珅和大人,只需要按各省顺序,合理安排好下面的官员,然后请出皇上并昭告天下:圣上下江南了,沿途各省小心伺候就好:

public class PrimeMinister {     private static List list = new ArrayList<>();      public static void main(String[] args) {         // 下令沿途各省官员准备好         list.add(new HebeiOfficial());         list.add(new ShandongOfficial());         list.add(new JiangsuOfficial());         list.add(new ZhejiangOfficial());         // 请出皇上         Emperor emperor = Emperor.getInstance();         // 昭告天下:万岁爷起驾下江南!沿途各省依次伺候圣上         System.out.println("乾隆下江南!");         start(list, emperor);     }      private static void start(List officials, Emperor emperor) {         for (Official o : officials) {             o.serve(emperor);         }     } }

看看,你的任务是不是简明多了,只需要维护好这个沿途各省官员的花名册即可。

更重要的是,你不用亲自负责了,下面的人谁办事不力,就要谁的脑袋!

只要自己的这个"花名册"或者"行程表"没写错,咱的脑袋就算保住啦。

而且各个官员的任务也比较单一,他们自己也更不容易出错。下面是整个行程模拟的执行情况:

乾隆下江南!

  • 直隶总督 安排 乾隆皇帝游览了: 避暑山庄

  • 山东巡抚 安排 乾隆皇帝游览了: 曲阜孔庙

  • 苏州织造 安排 乾隆皇帝游览了: 苏州园林

  • 杭州知州 安排 乾隆皇帝游览了: 西湖苏堤

嗯,一切看上去似乎还不错,各省官员按照顺序,依次完成了任务,把万岁爷伺候的还不错,没有什么异常状况发生,总算松了口气。

但是,现在来了个突发情况:皇上突然要求,在路过山东的时候加一个环节——大明湖畔三日游!

为啥要特意去那里?咱也不敢问呐!只管准备就好。

幸好我们的行程又已经有了大致框架,赶紧查,大明湖那里归谁管,哦,济南知府,就是他了!

现在只需把他也加到"花名册":责令济南知府安排皇上在大明湖畔三天的行程,不得有误,否则拿你试问!下面是和大人这边要做的改动:

...以上略...    list.add(new HeibeiOfficial());    // 加入济南知府,让他干活,他知道在大明湖畔该怎么玩    list.add(new JinanOfficial());    list.add(new ShandongOfficial());    list.add(new JiangsuOfficial());    list.add(new ZhejiangOfficial());    ...以下略...

而另一边济南知府这里,他也是属于官僚体制了(Official 的子类),所以也要极尽所能,让圣上在大明湖畔玩得开心:

public class JinanOfficial extends Official{     public JinanOfficial() {         title = "济南知府";     }      @Override     protected void serve(Emperor emperor) {         emperor.play(this, "大明湖畔");     } }

再次执行程序,模拟圣上的行程,结果输出如下:

  • 乾隆下江南!

  • 直隶总督 安排 乾隆皇帝游览了: 避暑山庄

  • 济南知府 安排 乾隆皇帝游览了: 大明湖畔

  • 山东巡抚 安排 乾隆皇帝游览了: 曲阜孔庙

  • 苏州织造 安排 乾隆皇帝游览了: 苏州园林

  • 杭州知州 安排 乾隆皇帝游览了: 西湖苏堤

嗯,这下总算又迎合了圣意,以后皇上再来什么其他的行程也不怕了(只要他不微服私访,微服私访您找纪晓岚去啊,单一责任原则,专门的类干专门的事儿不是?)。

只要找到当地具体的官员,一纸命令:你给我极尽所能招待皇上,具体怎么招待,你看着办,伺候不好万岁爷,我要你脑袋!

当然了,皇帝也可能临时删掉南巡中的某个环节,我们直接把它从行程列表中删除就好,而且什么时候想再重新加进来还可以随时添加,做到了可以"灵活插拔",把代码的改动减到了最小,有新的业务逻辑加进来的时候,只是做添加,这样既不容易出错,也确保了代码的弹性扩展,而且当前责任链中的步骤,如果没有状态相关的信息的话,也可以被组装到其他的责任链中。

如果是我们的真实项目,我们甚至可以把工作步骤的列表配置在 Spring Boot  的配置文件里,开启流程的这个类,只要读取配置,然后把各个步骤依次执行。

这样如果有修改只要改动配置文件即可,在 Java 代码里无需任何改动。

总结与拓展

以上其实只是一个责任链模式最简单的应用,它是一个有序列表里面装了各个任务的步骤,然后依次运行到最后。

我们可以把它写在自己的程序里,也可以把它抽象出来做成产品,让其他人自由扩展与配置,尽量减少重复制造轮子。

有很多工作流引擎便是这样,比如 Activiti、Netflix 的 Conductor 等。不光这些,就连你 最常用的 SpringMVC 甚至是  Tomcat  都用到了责任链模式,只不过他们的责任链是双向的,分别处理请求和响应,而且他们的处理顺序是刚好相反的,本质上是用类似递归的方法正序倒序各遍历了一次(Filter  或 Interceptor 的)数组。

另外在一些持续集成和持续部署的框架中,如 Jenkins,会有管道(Pipeline)的概念,当你在做出 git push  提交代码之后,会触发整个流程开始一步步地运作:拉取代码(Checkout  code)、构建(Build)、测试(Test)等,直到部署(Deploy)完成并运行脚本关闭旧版本的服务并启动最新部署的服务。这个"流水线"(Pipeline)其实也是一个可以让你用代码脚本来配置的责任链。

没有责任链模式的应用,你甚至都无法运行任何一个 Java 程序。因为类加载一般遵循"双亲委派"机制,实际上是用类似递归的方法正序和倒序各遍历了一次  Classloader  类所构成的链表(题外话,想把一个链表翻转过来,可以参见齐姐之前写过的:),只不过其中的逻辑比较复杂,而且还应用了"模板方法"这一设计模式。由于本文只是做一个责任链模式的简单入门,这些不做过多展开了。

到此,相信大家对“设计模式之如何掌握责任链”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!


分享文章:设计模式之如何掌握责任链
文章出自:http://myzitong.com/article/jeespg.html