23种设计模式(11):责任连模式

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

类型:行为类模式

类图:

        首先来看一段代码:

[java]  view plain copy
  1. public void test(int i, Request request){  
  2.     if(i==1){  
  3.         Handler1.response(request);  
  4.     }else if(i == 2){  
  5.         Handler2.response(request);  
  6.     }else if(i == 3){  
  7.         Handler3.response(request);  
  8.     }else if(i == 4){  
  9.         Handler4.response(request);  
  10.     }else{  
  11.         Handler5.response(request);  
  12.     }  
  13. }  

       代码的业务逻辑是这样的,方法有两个参数:整数i和一个请求request,根据i的值来决定由谁来处理request,如果i==1,由Handler1来处理,如果i==2,由Handler2来处理,以此类推。在编程中,这种处理业务的方法非常常见,所有处理请求的类有if…else…条件判断语句连成一条责任链来对请求进行处理,相信大家都经常用到。这种方法的优点是非常直观,简单明了,并且比较容易维护,但是这种方法也存在着几个比较令人头疼的问题:

  • 代码臃肿:实际应用中的判定条件通常不是这么简单地判断是否为1或者是否为2,也许需要复杂的计算,也许需要查询数据库等等,这就会有很多额外的代码,如果判断条件再比较多,那么这个if…else…语句基本上就没法看了。
  • 耦合度高:如果我们想继续添加处理请求的类,那么就要继续添加else if判定条件;另外,这个条件判定的顺序也是写死的,如果想改变顺序,那么也只能修改这个条件语句。

        既然缺点我们已经清楚了,就要想办法来解决。这个场景的业务逻辑很简单:如果满足条件1,则由Handler1来处理,不满足则向下传递;如果满足条件2,则由Handler2来处理,不满足则继续向下传递,以此类推,直到条件结束。其实改进的方法也很简单,就是把判定条件的部分放到处理类中,这就是责任连模式的原理。

 

责任连模式的结构

        责任连模式的类图非常简单,它由一个抽象地处理类和它的一组实现类组成:

  • 抽象处理类:抽象处理类中主要包含一个指向下一处理类的成员变量nextHandler和一个处理请求的方法handRequest,handRequest方法的主要主要思想是,如果满足处理的条件,则有本处理类来进行处理,否则由nextHandler来处理。
  • 具体处理类:具体处理类主要是对具体的处理逻辑和处理的适用条件进行实现。

        了解了责任连模式的大体思想之后,再看代码就比较好理解了:

[java]  view plain copy
  1. class Level {  
  2.     private int level = 0;  
  3.     public Level(int level){  
  4.         this.level = level;  
  5.     };  
  6.       
  7.     public boolean above(Level level){  
  8.         if(this.level >= level.level){  
  9.             return true;  
  10.         }  
  11.         return false;  
  12.     }  
  13. }  
  14.   
  15. class Request {  
  16.     Level level;  
  17.     public Request(Level level){  
  18.         this.level = level;  
  19.     }  
  20.       
  21.     public Level getLevel(){  
  22.         return level;  
  23.     }  
  24. }  
  25.   
  26. class Response {  
  27.   
  28. }  
  29.   
  30. abstract class Handler {  
  31.     private Handler nextHandler;      
  32.     public final Response handleRequest(Request request){  
  33.         Response response = null;  
  34.           
  35.         if(this.getHandlerLevel().above(request.getLevel())){  
  36.             response = this.response(request);  
  37.         }else{  
  38.             if(this.nextHandler != null){  
  39.                 this.nextHandler.handleRequest(request);  
  40.             }else{  
  41.                 System.out.println("-----没有合适的处理器-----");  
  42.             }  
  43.         }  
  44.         return response;  
  45.     }  
  46.     public void setNextHandler(Handler handler){  
  47.         this.nextHandler = handler;  
  48.     }  
  49.     protected abstract Level getHandlerLevel();  
  50.     public abstract Response response(Request request);  
  51. }  
  52.   
  53. class ConcreteHandler1 extends Handler {  
  54.     protected Level getHandlerLevel() {  
  55.         return new Level(1);  
  56.     }  
  57.     public Response response(Request request) {  
  58.         System.out.println("-----请求由处理器1进行处理-----");  
  59.         return null;  
  60.     }  
  61. }  
  62.   
  63. class ConcreteHandler2 extends Handler {  
  64.     protected Level getHandlerLevel() {  
  65.         return new Level(3);  
  66.     }  
  67.     public Response response(Request request) {  
  68.         System.out.println("-----请求由处理器2进行处理-----");  
  69.         return null;  
  70.     }  
  71. }  
  72.   
  73. class ConcreteHandler3 extends Handler {  
  74.     protected Level getHandlerLevel() {  
  75.         return new Level(5);  
  76.     }  
  77.     public Response response(Request request) {  
  78.         System.out.println("-----请求由处理器3进行处理-----");  
  79.         return null;  
  80.     }  
  81. }  
  82.   
  83. public class Client {  
  84.     public static void main(String[] args){  
  85.         Handler handler1 = new ConcreteHandler1();  
  86.         Handler handler2 = new ConcreteHandler2();  
  87.         Handler handler3 = new ConcreteHandler3();  
  88.   
  89.         handler1.setNextHandler(handler2);  
  90.         handler2.setNextHandler(handler3);  
  91.           
  92.         Response response = handler1.handleRequest(new Request(new Level(4)));  
  93.     }  
  94. }  

       代码中Level类是模拟判定条件;Request,Response分别对应请求和响应;抽象类Handler中主要进行条件的判断,这里模拟一个处理等级,只有处理类的处理等级高于Request的等级才能处理,否则交给下一个处理者处理。在Client类中设置好链的前后执行关系,执行时将请求交给第一个处理类,这就是责任连模式,它完成的功能与前文中的if…else…语句是一样的。

 

责任链模式的优缺点

        责任链模式与if…else…相比,他的耦合性要低一些,因为它把条件判定都分散到了各个处理类中,并且这些处理类的优先处理顺序可以随意设定。责任链模式也有缺点,这与if…else…语句的缺点是一样的,那就是在找到正确的处理类之前,所有的判定条件都要被执行一遍,当责任链比较长时,性能问题比较严重。

 

责任链模式的适用场景

       就像开始的例子那样,假如使用if…else…语句来组织一个责任链时感到力不从心,代码看上去很糟糕时,就可以使用责任链模式来进行重构。

 

总结

       责任链模式其实就是一个灵活版的if…else…语句,它就是将这些判定条件的语句放到了各个处理类中,这样做的优点是比较灵活了,但同样也带来了风险,比如设置处理类前后关系时,一定要特别仔细,搞对处理类前后逻辑的条件判断关系,并且注意不要在链中出现循环引用的问题。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值