博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
设计模式(十六)责任链模式(行为型)
阅读量:5037 次
发布时间:2019-06-12

本文共 7308 字,大约阅读时间需要 24 分钟。

概述

职责链模式(Chain of Responsibility  Pattern):避免请求发送者与接收者耦合在一起,让多个对象都有可能接收请求,将这些对象连接成一条链,并且沿着这条链传递请求,直到有对象处理它为止。职责链模式是一种对象行为型模式。

587773-20151025122236380-1100250565.gif

  在职责链模式结构图中包含如下几个角色:

      ● Handler(抽象处理者):它定义了一个处理请求的接口,一般设计为抽象类,由于不同的具体处理者处理请求的方式不同,因此在其中定义了抽象请求处理方法。因为每一个处理者的下家还是一个处理者,因此在抽象处理者中定义了一个抽象处理者类型的对象(如结构图中的successor),作为其对下家的引用。通过该引用,处理者可以连成一条链。

      ●ConcreteHandler(具体处理者):它是抽象处理者的子类,可以处理用户请求,在具体处理者类中实现了抽象处理者中定义的抽象请求处理方法,在处理请求之前需要进行判断,看是否有相应的处理权限,如果可以处理请求就处理它,否则将请求转发给后继者;在具体处理者中可以访问链中下一个对象,以便请求的转发。

      在职责链模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任

职责链模式的核心在于抽象处理者类的设计,抽象处理者的典型代码如下所示:

abstract class Handler {      //维持对下家的引用  protected Handler successor;            public void setSuccessor(Handler successor) {          this.successor=successor;      }            public abstract void handleRequest(String request);  }

上述代码中,抽象处理者类定义了对下家的引用对象,以便将请求转发给下家,该对象的访问符可设为protected,在其子类中可以使用。在抽象处理者类中声明了抽象的请求处理方法,具体实现交由子类完成。

        具体处理者是抽象处理者的子类,它具有两大作用:第一是处理请求,不同的具体处理者以不同的形式实现抽象请求处理方法handleRequest();第二是转发请求,如果该请求超出了当前处理者类的权限,可以将该请求转发给下家。具体处理者类的典型代码如下:

class ConcreteHandler extends Handler {      public void handleRequest(String request) {          if (请求满足条件) {              //处理请求          }          else {              this.successor.handleRequest(request);  //转发请求          }      }  }

在具体处理类中通过对请求进行判断可以做出相应的处理。

        需要注意的是,职责链模式并不创建职责链,职责链的创建工作必须由系统的其他部分来完成,一般是在使用该职责链的客户端中创建职责链。职责链模式降低了请求的发送端和接收端之间的耦合,使多个对象都有机会处理这个请求。 

Demo

// 全局变量,接口类型  /**   * 使用Java中的interface定义全局变量,可根据具体需要在    * 具体的包中使用静态导入相关的全局变量,语法如下:    *  import static package01.package02.*;   */ interface Levels {      public static final int LEVEL_01 = 1;      public static final int LEVEL_02 = 2;      public static final int LEVEL_03 = 3;  }
// 抽象请求类  abstract class AbstractRequest {      private String content = null;       public AbstractRequest(String content) {          this.content = content;      }       public String getContent() {          return this.content;      }       // 获得请求的级别      public abstract int getRequestLevel();  }
// 具体请求类01  class Request01 extends AbstractRequest {      public Request01(String content) {          super(content);      }       @Override     public int getRequestLevel() {          return Levels.LEVEL_01;      }  }   // 具体请求类02  class Request02 extends AbstractRequest {      public Request02(String content) {          super(content);      }       @Override     public int getRequestLevel() {          return Levels.LEVEL_02;      }  }   // 具体请求类03  class Request03 extends AbstractRequest {      public Request03(String content) {          super(content);      }       @Override     public int getRequestLevel() {          return Levels.LEVEL_03;      }  }
// 抽象处理者类,  abstract class AbstractHandler {      // 责任链的下一个节点,即处理者      private AbstractHandler nextHandler = null;       // 捕获具体请求并进行处理,或是将请求传递到责任链的下一级别      public final void handleRequest(AbstractRequest request) {           // 若该请求与当前处理者的级别层次相对应,则由自己进行处理          if (this.getHandlerLevel() == request.getRequestLevel()) {              this.handle(request);          } else {              // 当前处理者不能胜任,则传递至职责链的下一节点              if (this.nextHandler != null) {                  System.out.println("当前 处理者-0" + this.getHandlerLevel()                          + " 不足以处理 请求-0" + request.getRequestLevel());                                    // 这里使用了递归调用                  this.nextHandler.handleRequest(request);              } else {                  System.out.println("职责链上的所有处理者都不能胜任该请求...");              }          }      }       // 设置责任链中的下一个处理者      public void setNextHandler(AbstractHandler nextHandler) {          this.nextHandler = nextHandler;      }       // 获取当前处理者的级别      protected abstract int getHandlerLevel();       // 定义链中每个处理者具体的处理方式      protected abstract void handle(AbstractRequest request);  }
// 具体处理者-01  class Handler01 extends AbstractHandler {      @Override     protected int getHandlerLevel() {          return Levels.LEVEL_01;      }       @Override     protected void handle(AbstractRequest request) {          System.out.println("处理者-01 处理 " + request.getContent() + "\n");      }  }   // 具体处理者-02  class Handler02 extends AbstractHandler {      @Override     protected int getHandlerLevel() {          return Levels.LEVEL_02;      }       @Override     protected void handle(AbstractRequest request) {          System.out.println("处理者-02 处理 " + request.getContent()+ "\n");      }  }   // 具体处理者-03  class Handler03 extends AbstractHandler {      @Override     protected int getHandlerLevel() {          return Levels.LEVEL_03;      }       @Override     protected void handle(AbstractRequest request) {          System.out.println("处理者-03 处理 " + request.getContent()+ "\n");      }  }
// 测试类  public class Client {      public static void main(String[] args) {          // 创建指责链的所有节点          AbstractHandler handler01 = new Handler01();          AbstractHandler handler02 = new Handler02();          AbstractHandler handler03 = new Handler03();           // 进行链的组装,即头尾相连,一层套一层          handler01.setNextHandler(handler02);          handler02.setNextHandler(handler03);           // 创建请求并提交到指责链中进行处理          AbstractRequest request01 = new Request01("请求-01");          AbstractRequest request02 = new Request02("请求-02");          AbstractRequest request03 = new Request03("请求-03");                    // 每次提交都是从链头开始遍历          handler01.handleRequest(request01);          handler01.handleRequest(request02);          handler01.handleRequest(request03);      }  }

处理者-01 处理 请求-01  

当前 处理者-01 不足以处理 请求-02 

处理者-02 处理 请求-02  

当前 处理者-01 不足以处理 请求-03 

当前 处理者-02 不足以处理 请求-03 

处理者-03 处理 请求-03 

纯与不纯的职责链模式

职责链模式可分为纯的职责链模式和不纯的职责链模式两种:

  • 纯的职责链模式

      一个纯的职责链模式要求一个具体处理者对象只能在两个行为中选择一个:要么承担全部责任,要么将责任推给下家,不允许出现某一个具体处理者对象在承担了一部分或全部责任后又将责任向下传递的情况。而且在纯的职责链模式中,要求一个请求必须被某一个处理者对象所接收,不能出现某个请求未被任何一个处理者对象处理的情况。在前面的采购单审批实例中应用的是纯的职责链模式。

 

  • 不纯的职责链模式

      在一个不纯的职责链模式中允许某个请求被一个具体处理者部分处理后再向下传递,或者一个具体处理者处理完某请求后其后继处理者可以继续处理该请求,而且一个请求可以最终不被任何处理者对象所接收。Java AWT 1.0中的事件处理模型应用的是不纯的职责链模式,其基本原理如下:由于窗口组件(如按钮、文本框等)一般都位于容器组件中,因此当事件发生在某一个组件上时,先通过组件对象的handleEvent()方法将事件传递给相应的事件处理方法,该事件处理方法将处理此事件,然后决定是否将该事件向上一级容器组件传播;上级容器组件在接到事件之后可以继续处理此事件并决定是否继续向上级容器组件传播,如此反复,直到事件到达顶层容器组件为止;如果一直传到最顶层容器仍没有处理方法,则该事件不予处理。每一级组件在接收到事件时,都可以处理此事件,而不论此事件是否在上一级已得到处理,还存在事件未被处理的情况。显然,这就是不纯的职责链模式,早期的Java AWT事件模型(JDK 1.0及更早)中的这种事件处理机制又叫事件浮升(Event Bubbling)机制。从Java.1.1以后,JDK使用观察者模式代替职责链模式来处理事件。目前,在JavaScript中仍然可以使用这种事件浮升机制来进行事件处理。

总结

职责链模式通过建立一条链来组织请求的处理者,请求将沿着链进行传递,请求发送者无须知道请求在何时、何处以及如何被处理,实现了请求发送者与处理者的解耦。在软件开发中,如果遇到有多个对象可以处理同一请求时可以应用职责链模式,例如在Web应用开发中创建一个过滤器(Filter)链来对请求数据进行过滤,在工作流系统中实现公文的分级审批等等,使用职责链模式可以较好地解决此类问题。

  • 主要优点

职责链模式的主要优点如下:

  1. 职责链模式使得一个对象无须知道是其他哪一个对象处理其请求,对象仅需知道该请求会被处理即可,接收者和发送者都没有对方的明确信息,且链中的对象不需要知道链的结构,由客户端负责链的创建,降低了系统的耦合度。
  2. 请求处理对象仅需维持一个指向其后继者的引用,而不需要维持它对所有的候选处理者的引用,可简化对象的相互连接。
  3. 在给对象分派职责时,职责链可以给我们更多的灵活性,可以通过在运行时对该链进行动态的增加或修改来增加或改变处理一个请求的职责。
  4. 在系统中增加一个新的具体请求处理者时无须修改原有系统的代码,只需要在客户端重新建链即可,从这一点来看是符合“开闭原则”的。
  • 主要缺点

职责链模式的主要缺点如下:

  1. 由于一个请求没有明确的接收者,那么就不能保证它一定会被处理,该请求可能一直到链的末端都得不到处理;一个请求也可能因职责链没有被正确配置而得不到处理。
  2. 对于比较长的职责链,请求的处理可能涉及到多个处理对象,系统性能将受到一定影响,而且在进行代码调试时不太方便。
  3. 如果建链不当,可能会造成循环调用,将导致系统陷入死循环。
  • 适用场景

在以下情况下可以考虑使用职责链模式:

  1. 有多个对象可以处理同一个请求,具体哪个对象处理该请求待运行时刻再确定,客户端只需将请求提交到链上,而无须关心请求的处理对象是谁以及它是如何处理的。
  2. 在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。
  3. 可动态指定一组对象处理请求,客户端可以动态创建职责链来处理请求,还可以改变链中处理者之间的先后次序。 

我是天王盖地虎的分割线

转载于:https://www.cnblogs.com/yydcdut/p/4908556.html

你可能感兴趣的文章
javascript中的each遍历
查看>>
String中各方法多数情况下返回新的String对象
查看>>
浅谈tcp粘包问题
查看>>
UVA11524构造系数数组+高斯消元解异或方程组
查看>>
排序系列之——冒泡排序、插入排序、选择排序
查看>>
爬虫基础
查看>>
jquery.lazyload延迟加载图片第一屏问题
查看>>
HDU 1011 Starship Troopers (树形DP)
查看>>
手把手教你写DI_1_DI框架有什么?
查看>>
.net常见的一些面试题
查看>>
OGRE 源码编译方法
查看>>
上周热点回顾(10.20-10.26)
查看>>
C#正则表达式引发的CPU跑高问题以及解决方法
查看>>
云计算之路-阿里云上:“黑色30秒”走了,“黑色1秒”来了,真相也许大白了...
查看>>
APScheduler调度器
查看>>
设计模式——原型模式
查看>>
【jQuery UI 1.8 The User Interface Library for jQuery】.学习笔记.1.CSS框架和其他功能
查看>>
如何一个pdf文件拆分为若干个pdf文件
查看>>
web.xml中listener、 filter、servlet 加载顺序及其详解
查看>>
前端chrome浏览器调试总结
查看>>