- 浏览: 111674 次
- 性别:
- 来自: 成都
最近访客 更多访客>>
文章分类
最新评论
-
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 1182... -
设计模式之Factory
2007-01-20 02:58 1168定义:提供创建对象的接口. 为何使用? 工厂模式是我们最常用的 ... -
设计模式之Visitor
2007-01-20 02:54 1111Visitor 定义 作用于某个对象群中各个对象的操作. 它 ... -
设计模式之Interpreter(解释器)
2007-01-20 02:53 1170Interpreter 定义: 定义语言的文法 ,并且建立一 ... -
设计模式之Mediator(中介者)
2007-01-20 02:53 1184Mediator 定义: 用一个中介对象来封装一系列关于对象 ... -
设计模式之Strategy(策略)
2007-01-20 02:51 1119Strategy 是属于设计模式中 对象行为型模式,主要是定 ... -
设计模式之State
2007-01-20 02:51 1077设计模式之State State 的 ... -
设计模式之Command
2007-01-20 02:49 1012Command 模式是最让我疑惑的一个模式,我在阅读了很多代 ... -
设计模式之Observer
2007-01-20 02:46 995Java 深入到一定程度,就 ... -
设计模式之Memento(备忘机制)
2007-01-20 02:45 1129Memento 定义: memento 是一个保存另外一个对 ... -
设计模式之Template
2007-01-20 02:41 845Template 定义: 定义一个操作中算法的骨架,将一些步 ... -
设计模式之Flyweight(享元)
2007-01-20 02:40 1008板桥里人 http://www.jdon.com 2002/ ... -
设计模式之Bridge
2007-01-20 02:39 954Bridge 定义 : 将抽象和行为划分开来,各自独立,但能 ... -
设计模式之Composite(组合)
2007-01-20 02:38 906Composite 定义: 将对象以树形结构组织起来,以达成 ... -
设计模式之Adapter(适配器)
2007-01-20 02:36 854定义: 将两个不兼容的 ... -
设计模式之Proxy(代理)
2007-01-20 02:35 1117理解并使用设计模式, ... -
设计模式之Facade(外观)
2007-01-20 02:34 843Facade 的定义: 为子系统中的一组接口提供一个一致的界 ... -
设计模式之Builder
2007-01-20 02:33 964Builder 模式定义: 将一个复杂对象的构建与它的表示分 ... -
设计模式之Singleton(单态)
2006-12-28 21:28 1059定义: Singleton 模式主要作用是保证在Java 应 ... -
设计模式之Prototype(原型)
2006-12-28 21:22 1214定义: 用原型实例指定创建对象的种类,并且通过拷贝这些原型 ...
相关推荐
C#面向对象设计模式 (行为型模式) Chain Of Responsibility 职责链模式 视频讲座下载
C#面向对象设计模式 Chain of Responsibility 职责链模式 视频讲座下载
职责链模式(Chain of Responsibility)是一种行为型设计模式,它允许将请求沿着处理者对象的链进行传递,直到某个对象能够处理这个请求。在C#中,职责链模式的应用可以帮助我们构建灵活、可扩展的系统,减少对象...
职责链模式(Chain of Responsibility Pattern)是一种行为设计模式,它允许将请求的发送者和接收者解耦,使得多个对象都有可能处理一个请求,而无需显式指定接收者。在这个模式中,请求沿着一个处理者链进行传递,...
### C#面向对象设计模式纵横谈(14):Chain of Responsibility 职责链模式(行为型模式) #### 概述 在本篇文章中,我们将深入探讨C#中的Chain of Responsibility(职责链)模式,这是行为型设计模式的一种。虽然标题...
职责链模式(Chain of Responsibility)是一种行为型设计模式,它允许你将请求沿着处理者对象的链进行传递,直到某个对象处理该请求。在C#编程中,职责链模式能够帮助我们实现一种松耦合的架构,使得请求的发送者和...
Chain of Responsibility模式是GOF(GoF,Gang of Four)在他们的经典著作《设计模式:可复用面向对象软件的基础》中提出的23种设计模式之一,属于行为模式类别。这个模式的主要目的是允许在对象之间传递请求,同时...
创建模式: ...设计模式之Chain of Responsibility(职责链) 设计模式之Command 设计模式之State 设计模式之Strategy(策略) 设计模式之Mediator(中介者) 设计模式之Interpreter(解释器) 设计模式之Visitor
**PHP设计模式:Chain Of Responsibility(职责链模式)** 职责链模式是一种行为设计模式,它的主要目的是解耦请求的发送者和接收者,通过创建一个处理请求的对象链,使得多个对象都有机会处理这个请求。在PHP中,...
设计模式参考文档 ...设计模式之Chain of Responsibility(职责链) 设计模式之Command 设计模式之State 设计模式之Strategy(策略) 设计模式之Mediator(中介者) 设计模式之Interpreter(解释器) 设计模式之Visitor
职责链模式(Chain of Responsibility)是设计模式中的一种行为模式,它允许将请求沿着处理者对象的链式结构进行传递,直到某个对象决定处理这个请求。这种模式的主要优点在于可以解耦发送者和接收者,使得系统更加...
职责链模式(Chain of Responsibility)是一种行为设计模式,它的核心思想是将一系列处理请求的对象组织成一条链,每个对象都包含对请求的处理或传递的责任。在C++中实现职责链模式,我们可以创建一个抽象处理器类,...
**职责链模式**(Chain of Responsibility Pattern)是一种行为设计模式,它使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个...
**职责链模式**(Chain of Responsibility Pattern)是行为型设计模式的一种,其核心在于避免请求发送者与接收者的直接耦合,通过构建一系列处理对象的链路,使请求能在链上逐级传递直至被某个对象处理。这种模式的...
本文实例讲述了Python设计模式之职责链模式原理与用法。分享给大家供大家参考,具体如下: 职责链模式(Chain Of Responsibility):使多个对象都有机会处理请求,从而避免发送者和接收者的耦合关系。将对象连成链并...
在软件设计领域,职责链(Chain of Responsibility)模式是一种行为设计模式,它允许将请求沿着处理者对象的链式结构进行传递,直到被某个对象处理。这种模式在C++中广泛应用,可以有效地解耦发送者和接收者,使得...
C#面向对象设计模式纵横谈(14):Chain of Responsibility 职责链模式(行为型模式) C#面向对象设计模式纵横谈(15):(行为型模式) Command 命令模式 C#面向对象设计模式纵横谈(16):(行为型模式) Interpreter 解释...