- 浏览: 109344 次
- 性别:
- 来自: 成都
最近访客 更多访客>>
文章分类
最新评论
-
dev_liu:
lipengyu2006 写道现在怎么样儿了啊 房子多少钱买 ...
最近比较心烦 -
lipengyu2006:
现在怎么样儿了啊 房子多少钱买的。
最近比较心烦 -
cynan168:
...
hibernate数据查询的几种方式 -
My_Choice:
joram中文文档 -
My_Choice:
非常感谢,太有用了,中文文档不好找啊,而且是这么详细的
joram中文文档
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.
CoR 的优点:
因为无法预知来自外界的请求是属于哪种类型,每个类如果碰到它不能处理的请求只要放弃
就可以。无疑这降低了类之间的耦合性。
缺点是效率低,因为一个请求的完成可能要遍历到最后才可能完成,当然也可以用树的概念
优化。 在Java AWT1.0 中,对于鼠标按键事情的处理就是使用CoR,到Java.1.1 以后,就
使用Observer 代替CoR
扩展性差,因为在CoR 中,一定要有一个统一的接口Handler.局限性就在这里。
发表评论
-
追MM与Java的23种设计模式[转]
2007-01-20 03:09 1151... -
设计模式之Factory
2007-01-20 02:58 1132定义:提供创建对象的接口. 为何使用? 工厂模式是我们最常用的 ... -
设计模式之Visitor
2007-01-20 02:54 1086Visitor 定义 作用于某个对象群中各个对象的操作. 它 ... -
设计模式之Interpreter(解释器)
2007-01-20 02:53 1138Interpreter 定义: 定义语言的文法 ,并且建立一 ... -
设计模式之Mediator(中介者)
2007-01-20 02:53 1159Mediator 定义: 用一个中介对象来封装一系列关于对象 ... -
设计模式之Strategy(策略)
2007-01-20 02:51 1069Strategy 是属于设计模式中 对象行为型模式,主要是定 ... -
设计模式之State
2007-01-20 02:51 1047设计模式之State State 的 ... -
设计模式之Command
2007-01-20 02:49 959Command 模式是最让我疑惑的一个模式,我在阅读了很多代 ... -
设计模式之Observer
2007-01-20 02:46 958Java 深入到一定程度,就 ... -
设计模式之Memento(备忘机制)
2007-01-20 02:45 1071Memento 定义: memento 是一个保存另外一个对 ... -
设计模式之Template
2007-01-20 02:41 820Template 定义: 定义一个操作中算法的骨架,将一些步 ... -
设计模式之Flyweight(享元)
2007-01-20 02:40 960板桥里人 http://www.jdon.com 2002/ ... -
设计模式之Bridge
2007-01-20 02:39 923Bridge 定义 : 将抽象和行为划分开来,各自独立,但能 ... -
设计模式之Composite(组合)
2007-01-20 02:38 862Composite 定义: 将对象以树形结构组织起来,以达成 ... -
设计模式之Adapter(适配器)
2007-01-20 02:36 812定义: 将两个不兼容的 ... -
设计模式之Proxy(代理)
2007-01-20 02:35 1084理解并使用设计模式, ... -
设计模式之Facade(外观)
2007-01-20 02:34 813Facade 的定义: 为子系统中的一组接口提供一个一致的界 ... -
设计模式之Builder
2007-01-20 02:33 939Builder 模式定义: 将一个复杂对象的构建与它的表示分 ... -
设计模式之Singleton(单态)
2006-12-28 21:28 1023定义: Singleton 模式主要作用是保证在Java 应 ... -
设计模式之Prototype(原型)
2006-12-28 21:22 1167定义: 用原型实例指定创建对象的种类,并且通过拷贝这些原型 ...
相关推荐
C#面向对象设计模式 (行为型模式) Chain Of Responsibility 职责链模式 视频讲座下载
C#面向对象设计模式 Chain of Responsibility 职责链模式 视频讲座下载
C#面向对象设计模式纵横谈(20):(行为型模式) Chain Of Responsibility 职责链模式
C#面向对象设计模式纵横谈(14):Chain of Responsibility 职责链模式(行为型模式) (Level 300)
C#面向对象设计模式纵横谈(14):Chain of Responsibility 职责链模式(行为型模式)
职责链模式 设计模式 Chain of Responsibility 若有问题望指出。
创建模式: ...设计模式之Chain of Responsibility(职责链) 设计模式之Command 设计模式之State 设计模式之Strategy(策略) 设计模式之Mediator(中介者) 设计模式之Interpreter(解释器) 设计模式之Visitor
设计模式参考文档 ...设计模式之Chain of Responsibility(职责链) 设计模式之Command 设计模式之State 设计模式之Strategy(策略) 设计模式之Mediator(中介者) 设计模式之Interpreter(解释器) 设计模式之Visitor
php /** * 职责链模式 * * 为解除请求的发送者和接收者之间的耦合,而使用多个对象都用机会处理这个请求,将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它 * */ abstract class Handler { ...
本文实例讲述了Python设计模式之职责链模式原理与用法。分享给大家供大家参考,具体如下: 职责链模式(Chain Of Responsibility):使多个对象都有机会处理请求,从而避免发送者和接收者的耦合关系。将对象连成链并...
C#面向对象设计模式纵横谈(14):Chain of Responsibility 职责链模式(行为型模式) C#面向对象设计模式纵横谈(15):(行为型模式) Command 命令模式 C#面向对象设计模式纵横谈(16):(行为型模式) Interpreter 解释...
职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。 职责链模式的一个...
用C++简单的实现职责链(Chain of Responsibility)。
创建型: 1. 单件模式(Singleton ... 职责链模式(Chain of Responsibility Pattern) 20. 备忘录模式(Memento Pattern) 21. 策略模式(Strategy Pattern) 22. 访问者模式(Visitor Pattern) 23. 状态模式(State Pattern)
13)职责链模式(Chain of Responsibility) 14)命令模式(Command) 15)解析器模式(Interpreter) 16)迭代器模式(Iterator) 17)中介模式(Mediator) 18)备忘录模式(Memento) 19)观察者模式(Observer)...
本电子书一共两个压缩文档,本文件为part2. ...第23章 职责链模式(Chain of Responsibility) 第24章 桥接模式(Bridge) 第25章 访问者模式(Visitor) 附录A常见面向对象设计原则 附录BUML简介 参考文献
责任链模式(Chain of Responsibility Pattern) 命令模式(Command Pattern) 解释器模式(Interpreter Pattern) 迭代器模式(Iterator Pattern) 中介者模式(Mediator Pattern) 备忘录模式...