Java设计模式之责任链模式(Chain of Responsibility模式)介绍

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

如何使用责任链模式
虽然这一段是如何使用CoR,但是也是演示什么是CoR。

有一个Handler接口:

代码如下:

public interface Handler{
  public void handleRequest();
}

这是一个处理request的事例, 如果有多种request,比如 请求帮助 请求打印 或请求格式化:
◆ 最先想到的解决方案是:在接口中增加多个请求:

代码如下:

public interface Handler{
  public void handleHelp();
  public void handlePrint();
  public void handleFormat();
}

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

代码如下:

public class ConcreteHandler implements Handler{
  private Handler successor;
  public ConcreteHandler(Handler successor){
          this.successor=successor;
        }

  public void handleHelp(){
    //具体处理请求Help的代码
    ...
  }

  public void handlePrint(){
    //如果是print 转去处理Print
    successor.handlePrint();
  }
  public void handleFormat(){
    //如果是Format 转去处理format
    successor.handleFormat();
  }

}

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

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

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

代码如下:

public interface HelpHandler{
  public void handleHelp();
}

public interface PrintHandler{
  public void handlePrint();
}

public interface FormatHandler{
  public void handleFormat();
}

public class ConcreteHandler
  implements HelpHandler,PrintHandler,FormatHandlet{
  private HelpHandler helpSuccessor;
  private PrintHandler printSuccessor;
  private FormatHandler formatSuccessor;

  public ConcreteHandler(HelpHandler helpSuccessor,PrintHandler printSuccessor,FormatHandler             formatSuccessor)
  {
    this.helpSuccessor=helpSuccessor;
    this.printSuccessor=printSuccessor;
    this.formatSuccessor=formatSuccessor;
  }

  public void handleHelp(){
    .......
  }

  public void handlePrint(){this.printSuccessor=printSuccessor;}

  public void handleFormat(){this.formatSuccessor=formatSuccessor;}

}

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

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

代码如下:

public interface Handler{
  public void handleRequest(String request);
}
那么Handler实现代码如下:

public class ConcreteHandler implements Handler{
  private Handler successor;

  public ConcreteHandler(Handler successor){
    this.successor=successor;
  }

  public void handleRequest(String request){
    if (request.equals("Help")){
      //这里是处理Help的具体代码
    }else
      //传递到下一个
      successor.handle(request);

    }
  }

}

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

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

代码如下:

public interface Handler{
  public void handleRequest(Request request);
}
Request类的定义:

public class Request{
  private String type;

  public Request(String type){this.type=type;}

  public String getType(){return type;}

  public void execute(){
    //request真正具体行为代码
  }
}

那么Handler实现代码如下:

代码如下:

public class ConcreteHandler implements Handler{
  private Handler successor;

  public ConcreteHandler(Handler successor){
    this.successor=successor;
  }

  public void handleRequest(Request request){
    if (request instanceof HelpRequest){
      //这里是处理Help的具体代码
    }else if (request instanceof PrintRequst){
      request.execute();
    }else
      //传递到下一个
      successor.handle(request);

    }
  }

}

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

1.CoR的优点:因为无法预知来自外界的请求是属于哪种类型,每个类如果碰到它不能处理的请求只要放弃就可以。无疑这降低了类之间的耦合性。
2.CoR的缺点是效率低,因为一个请求的完成可能要遍历到最后才可能完成,当然也可以用树的概念优化。 在Java AWT1.0中,对于鼠标按键事情的处理就是使用CoR,到Java.1.1以后,就使用Observer代替CoR。

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

(0)

相关推荐

  • 轻松掌握Java桥接模式

    定义:将抽象部分与实现部分分离,使它们都可以独立的变化. 特点:桥接模式基于类的最小设计原则,通过使用封装,聚合以及继承等行为来让不同的类承担不同的责任.它的主要特点是把抽象(abstraction)与行为实现(implementation)分离开来,从而可以保持各部分的独立性以及应对它们的功能扩展. 企业级开发和常用框架中的应用:多继承的结构 只是从定义理解桥接模式,很难理清它的作用,下面举个例子来说明: 电脑城卖电脑,电脑种类分了平板电脑,笔记本电脑,台式电脑:电脑品牌又分了联想,戴尔,华硕

  • Java 中桥接模式——对象结构型模式的实例详解

    Java  中桥接模式--对象结构型模式的实例详解 一.意图 将抽象部分与它的实现部分分离,使他们都可以独立的变化. 二.适用性 以下一些情况使用Bridge模式 你不希望在抽象和它的实现部分之间有一个固定的绑定关系.例如这种情况可能因为,在程序运行时刻实现部分应可以被选择或者切换. 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充.这时Bridge模式使你可以对不同的抽象接口和实现部分进行组合,并分别对他们进行扩充. 对一个抽象的实现部分的修改应对客户不产生影响,即客户代码不必重新编译

  • Java设计模式之抽象工厂模式实例详解

    本文实例讲述了Java设计模式之抽象工厂模式.分享给大家供大家参考,具体如下: 具体工厂类:生产创建某一类具体产品对象. 抽象产品类可以使用接口或者父类来描述产品对象的行为特征. 具体产品类就是某一具体的对象. 那么抽象工厂模式和工厂模式的不同之处呢? 其实最大的不同就在于,在产品类的结构更加复杂时,抽象工厂模式针对不同的产品族(就是一类产品对象)定义了不同的行为,也就是在父类或接口中,定义了不同的产生方法.不同的产品族调用各自的创建方法.同时不同的产品族横向比较,也有可归类的相同特征,这些特征

  • Java结构型设计模式中的适配器模式与桥接模式解析

    适配器模式 定义 适配器模式(英语:adapter pattern)有时候也称包装样式或者包装.将一个类的接口转接成用户所期待的.一个适配使得因接口不兼容而不能在一起工作的类工作在一起. 有两类适配器模式: 1. 对象适配器模式 - 对象适配器通过关联满足用户期待接口,还降低了代码间的不良耦合.在工作中推荐使用"对象适配". 2. 类适配器模式 - 这种适配器模式下,适配器继承自已实现的类(一般多重继承),java中没有多重继承,所以这里不做介绍. 实现 1. Target - 定义C

  • Java设计模式之单例模式实例详解【懒汉式与饿汉式】

    本文实例讲述了Java设计模式之单例模式.分享给大家供大家参考,具体如下: 单例模式就是产生一个对象实例,供外外部访问. 它的应用场景就是在这个类在全局真资源需要统一访问,否则会造成混乱时,才有必要设计成单例. 懒汉式,就是在使用这个对象时,才去查看这个对象是否创建,如果没创建就马上创建,如果已经创建,就返回这个实例. 饿汉式,在加载这个类的时候就先创建好一个对象实例,等待调用. 两者的优缺点也能猜到,使用懒汉式,在反应速度上肯定要比饿汉式慢. 但是这个对象如果不被调用,那就节省了cpu和内存资

  • Java设计模式之模板模式(Template模式)介绍

    Template模式定义:定义一个操作中算法的骨架,将一些步骤的执行延迟到其子类中. 其实Java的抽象类本来就是Template模式,因此使用很普遍.而且很容易理解和使用,我们直接以示例开始: 复制代码 代码如下: public abstract class Benchmark { /** * 下面操作是我们希望在子类中完成 */ public abstract void benchmark(); /** * 重复执行benchmark次数 */ public final long repea

  • Java设计模式之建造者模式实例详解

    本文实例讲述了Java设计模式之建造者模式.分享给大家供大家参考,具体如下: 建造者模式(builder)可以将部件和其组装过程分开.一步一步创建一个复杂的对象. 用户只需要指定复杂对象的类型就可以得到该对象,而无须知道其内部的具体构造细节. 什么情况下会用到建造者模式? 个人理解,当我们创建的对象在创建时需要逻辑的时候. 比如,一个简单的pojo对象,我们想要创建,直接就可以new出来,没有什么逻辑. 当有一个复杂的对象,你想要创建它时,它的各个属性之间是有逻辑关系的. 一个属性赋值取值依赖于

  • java设计模式之工厂模式实例详解

    本文实例讲述了java设计模式之工厂模式.分享给大家供大家参考,具体如下: 工厂模式(factory) 涉及到4个角色:抽象工厂类角色,具体工厂类角色,抽象产品类角色和具体产品类角色. 抽象工厂类角色使用接口或者父类来描述工厂的行为, 具体工厂类角色负责创建某一类型的产品对象. 抽象产品类可以使用接口或者父类来描述产品对象的行为特征. 具体产品类就是某一具体的对象. 工厂模式不同于静态工厂模式的地方: 工厂模式在工厂类也实现了多态,而不仅仅是在产品对象上实现多态. 它可以应对不同类型的产品对应一

  • Java设计模式之桥接模式实例详解

    本文实例讲述了Java设计模式之桥接模式.分享给大家供大家参考,具体如下: 概念: 桥接模式(Bridge Pattern):将抽象部分与它的实现部分分离,使它们都可以独立地变化. 桥接模式将继承关系转换为关联关系,从而降低了类与类之间的耦合,减少了代码编写量. 什么情况下会用桥接模式? 简单的说就是我们在抽象对象的特征时,对象的特征属性又很抽象,不得不把属性再次抽象. 否则的话,具体子类的数量将会成几何增长,而且不易扩展.没办法维护现有代码. 举例,我们在抽象手机这二个对象时,它的几个属性,如

  • java设计模式之桥接模式(Bridge)

    概述 桥接模式一种结构型模式,它主要应对的是:由于实际的需要,某个类具有两个或以上的维度变化,如果只是用继承将无法实现这种需要,或者使得设计变得相当臃肿. 桥接模式的做法是把变化的部分抽象出来,使变化部分与主类分离开来,从而将多个维度的变化彻底分离.最后,提供一个管理类来组合不同维度上的变化,通过这种组合来满足业务的需要. UML结构图 代码示例 package interview; interface Implementor{ void operationImpl(); } abstract

  • Java设计模式之静态工厂模式详解

    本文实例讲述了Java设计模式之静态工厂模式.分享给大家供大家参考,具体如下: 静态工厂模式(static factory)也叫简单工厂模式. 涉及到3个角色:工厂类角色,抽象产品类角色和具体产品类角色. 抽象产品类可以使用接口或者父类来描述产品对象的行为特征. 具体产品类就是某一具体的对象. 静态工厂类有一个静态的方法,含有判断逻辑,决定要创建哪一种具体的产品对象. 其设计模式如下: 抽象产品类  IProduct package org.test.design.sf; public inte

  • Java设计模式之装饰者模式详解和代码实例

    装饰者模式可以给已经存在的对象动态的添加能力.下面,我将会用一个简单的例子来演示一下如何在程序当中使用装饰者模式. 1.装饰者模式 让我们来假设一下,你正在寻找一个女朋友.有很多来自不同国家的女孩,比如:美国,中国,日本,法国等等,他们每个人都有不一样的个性和兴趣爱好,如果需要在程序当中模拟这么一种情况的话,假设每一个女孩就是一个Java类的话,那么就会有成千上万的类,这样子就会造成类的膨胀,而且这样的设计的可扩展性会比较差.因为如果我们需要一个新的女孩,就需要创建一个新的Java类,这实际上也

随机推荐