设计模式袖珍版 连续转载之 - Chain of Responsibility(职责链)

原创 2005年06月01日 01:07:00
Chain of Responsibility定义
Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求request,这些类之间是一个松散的耦合,唯一共同点是在他们之间传递request. 也就是说,来了一个请求,A类先处理,如果没有处理,就传递到B类处理,如果没有处理,就传递到C类处理,就这样象一个链条(chain)一样传递下去。

如何使用?
虽然这一段是如何使用CoR,但是也是演示什么是CoR.

有一个Handler接口:
程序代码:

  1. public interface Handler{
  2.   public void handleRequest();
  3. }


这是一个处理request的事例, 如果有多种request,比如 请求帮助 请求打印 或请求格式化:

最先想到的解决方案是:在接口中增加多个请求:
程序代码:

  1. public interface Handler{
  2.   public void handleHelp();
  3.   public void handlePrint();
  4.   public void handleFormat();
  5. }


具体是一段实现接口Handler代码:
程序代码:

  1. public class ConcreteHandler implements Handler{
  2.   private Handler successor;
  3.   public ConcreteHandler(Handler successor){
  4.   this.successor=successor;
  5. }
  6.   public void handleHelp(){
  7.     //具体处理请求Help的代码
  8.     ...
  9.   }
  10.   public void handlePrint(){
  11.     //如果是print 转去处理Print
  12.     successor.handlePrint();
  13.   }
  14.   public void handleFormat(){
  15.     //如果是Format 转去处理format
  16.     successor.handleFormat();
  17.   }
  18. }


一共有三个这样的具体实现类,上面是处理help,还有处理Print 处理Format这大概是我们最常用的编程思路。

虽然思路简单明了,但是有一个扩展问题,如果我们需要再增加一个请求request种类,需要修改接口及其每一个实现。

第二方案:将每种request都变成一个接口,因此我们有以下代码 :
程序代码:

  1. public interface HelpHandler{
  2.   public void handleHelp();
  3. }
  4. public interface PrintHandler{
  5.   public void handlePrint();
  6. }
  7. public interface FormatHandler{
  8.   public void handleFormat();
  9. }
  10. public class ConcreteHandler
  11.   implements HelpHandler,PrintHandler,FormatHandlet{
  12.   private HelpHandler helpSuccessor;
  13.   private PrintHandler printSuccessor;
  14.   private FormatHandler formatSuccessor;
  15.   public ConcreteHandler(HelpHandler helpSuccessor,
  16.         PrintHandler printSuccessor,FormatHandler formatSuccessor)
  17.   {
  18.     this.helpSuccessor=helpSuccessor;
  19.     this.printSuccessor=printSuccessor;
  20.     this.formatSuccessor=formatSuccessor;
  21.   }
  22.   public void handleHelp(){
  23.     .......
  24.   }
  25.   public void handlePrint(){this.printSuccessor=printSuccessor;}
  26.   public void handleFormat(){this.formatSuccessor=formatSuccessor;}
  27. }


这个办法在增加新的请求request情况下,只是节省了接口的修改量,接口实现ConcreteHandler还需要修改。而且代码显然不简单美丽。

解决方案3: 在Handler接口中只使用一个参数化方法:
程序代码:

  1. public interface Handler{
  2.   public void handleRequest(String request);
  3. }
  4. 那么Handler实现代码如下:
  5. public class ConcreteHandler implements Handler{
  6.   private Handler successor;
  7.   public ConcreteHandler(Handler successor){
  8.     this.successor=successor;
  9.   }
  10.   public void handleRequest(String request){
  11.     if (request.equals("Help")){
  12.       //这里是处理Help的具体代码
  13.     }else
  14.       //传递到下一个
  15.       successor.handle(request);
  16.     }
  17.   }
  18. }


这里先假设request是String类型,如果不是怎么办?当然我们可以创建一个专门类Request


最后解决方案:接口Handler的代码如下:
程序代码:

  1. public interface Handler{
  2.   public void handleRequest(Request request);
  3. }
  4. Request类的定义:
  5. public class Request{
  6.   private String type;
  7.   public Request(String type){this.type=type;}
  8.   public String getType(){return type;}
  9.   public void execute(){
  10.     //request真正具体行为代码
  11.   }
  12. }

那么Handler实现代码如下:
程序代码:

  1. public class ConcreteHandler implements Handler{
  2.   private Handler successor;
  3.   public ConcreteHandler(Handler successor){
  4.     this.successor=successor;
  5.   }
  6.   public void handleRequest(Request request){
  7.     if (request instanceof HelpRequest){
  8.       //这里是处理Help的具体代码
  9.     }else if (request instanceof PrintRequst){
  10.       request.execute();
  11.     }else
  12.       //传递到下一个
  13.       successor.handle(request);
  14.     }
  15.   }
  16. }


这个解决方案就是CoR, 在一个链上,都有相应职责的类,因此叫Chain of Responsibility.

CoR的优点:
因为无法预知来自外界的请求是属于哪种类型,每个类如果碰到它不能处理的请求只要放弃就可以。无疑这降低了类之间的耦合性。

缺点是效率低,因为一个请求的完成可能要遍历到最后才可能完成,当然也可以用树的概念优化。 在Java AWT1.0中,对于鼠标按键事情的处理就是使用CoR,到Java.1.1以后,就使用Observer代替CoR

扩展性差,因为在CoR中,一定要有一个统一的接口Handler.局限性就在这里。


设计模式之职责链(Chain Of Responsibility)

使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系.将这些对象 连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止. 适用性: 1.有多个对象可以处理一个请...

设计模式--职责链(Chain of Responsibility)

 Chain of Responsibility看一个例子: 网管接收帧的处理:// 这个模式需要定义个公共接口,属于这条链里的对象,全部派生于它 class Poll { public: ...

GOF设计模式之CHAIN OF RESPONSIBILITY(职责链)

概述本文将和读者一起来理解GOF设计模式之CHAIN OF RESPONSIBILITY(职责链)。同样,本文将用Java对GOF中的示例代码改些,同时附上测试用例。模式结构 职责链模式逻辑很清晰,...

C++设计模式之十三:Chain of Responsibility(职责链)

一、意图: 使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。 二、类图: 三、...

Chain of Responsibility(职责链设计模式)

一、概念 使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理他为止。 二、模式结构图...

设计模式之Chain of Responsibility(职责链)

Chain of Responsibility定义 Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求request,这些类之间是一个松散的耦合...

【设计模式】行为模式之Chain of Responsibility职责链

Chain of Responsibility职责链是一种对象行为型设计模式,目的是使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递该请求...
  • iEearth
  • iEearth
  • 2016年08月21日 13:55
  • 485

【设计模式基础】行为模式 - 3 - 职责链(Chain of responsibility)

1. 模式意图 使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。 在职责链模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,知道链上的某一个对...

设计模式C++描述----05.职责链(Chain of Responsibility)模式

一. 概述 职责链模式: 使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。 二. 举个例子 ...

设计模式C++描述__职责链(Chain of Responsibility)模式

其他模式链接地址:点击打开链接 一. 概述 职责链模式: 使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:设计模式袖珍版 连续转载之 - Chain of Responsibility(职责链)
举报原因:
原因补充:

(最多只允许输入30个字)