设计模式--责任链模式ChainOfResponsibility(行为型)
2014-04-14 11:41
274 查看
1 定义:
1.1 定义:Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along
the chain until an object handles it.(使多个对象都有机会处理请求,从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止。)
1.2 通用类图:
责任链模式的重点是在“链”上,由一条链去处理相似的请求在链中决定谁来处理这个请求,并返回相应的结果。
1.3 通用代码:
在实际应用中,一般会有一个封装类对责任模式进行封装,也就是替代Client类,直接返回链中第一个处理者,具体链的设置不需要高层次模块关系,这样更简化了高层次模块的调用,减少模块间的耦合,提高系统的灵活性。
2 优点
2.1 最显著就是:请求和处理分开。请求者可以不用知道是谁处理的,处理者可以不用知道请求的全貌,两者解耦,提高系统的灵活性。
2.2 承接第一点,个人认为最大的好处就是把星状的耦合关系变成直线型的耦合关系,使原本“一对多”的耦合关系,变为“一对一”耦合(因为事件只与第一个处理对象耦合,每个处理对象又只与后面一个对象耦合)。
3 缺点
3.1 性能问题:每个请求都从链头遍历到链尾,特别是在链比较长的时候,性能是一个非常大的问题。
3.2 不便于调试,由于采用了类似于递归的方式,调试时逻辑比较复杂。
4 应用场景
责任链模式的核心是屏蔽了请求的处理过程(即请求者可以不用知道到底是谁来处理的)。
其表面上看来,用面向对象的“链表+遍历+函数调用+判断”来替换面向过程的“若干if-else判断”,以至于我起初认为这个模式完全是为了面向对象取代if判断而生的。
但实质上,降低了请求与处理对象之间的耦合,分析见上。
4.1某一请求根据条件,只需少数(或一个)对象处理,但却需要在较多对象中做选择的情况;
4.2 请求处理时,不能越权,只能按步骤判断处理的情况;
5 注意事项
5.1 链长需要控制,应避免出现超长链的情况;
6 扩展
6.1某事件需要多个大对象共同参与处理的情况(每个对象处理一部分,但非每个对象每时每刻都参与的情境);[冒似此景下最能发挥效能,但要考虑设计是否有问题。。。]
7 范例
(小例,请假,因为不能越权嘛,你只能访问直接上司。。。)
类图如下:
源代码
结果:
请假5天,是否批准? true
请假15天,是否批准? true
请假16天,是否批准? false
转自:/article/1491888.html
1.1 定义:Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along
the chain until an object handles it.(使多个对象都有机会处理请求,从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止。)
1.2 通用类图:
责任链模式的重点是在“链”上,由一条链去处理相似的请求在链中决定谁来处理这个请求,并返回相应的结果。
1.3 通用代码:
/** * @author cbf4Life cbf4life@126.com I'm glad to share my knowledge with you * all. */ public abstract class Handler { private Handler nextHandler; // 每个处理者都必须对请求做出处理 public final Response handlerMessage(Request request) { Response response = null; // 判断是否是自己的处理级别 if (this.getHandlerLevel().equals(request.getRequestLevel())) { response = this.echo(request); } else { // 不属于自己的处理级别 // 判断是否有下一个处理者 if (this.nextHandler != null) { response = this.nextHandler.handlerMessage(request); } else { // 没有适当的处理者,业务自行处理 } } return response; } // 设置下一个处理者是谁 public void setNext(Handler _handler) { this.nextHandler = _handler; } // 每个处理者都有一个处理级别 protected abstract Level getHandlerLevel(); // 每个处理者都必须实现处理任务 protected abstract Response echo(Request request); } // 抽象的处理者实现三个职责:一是定义一个请求的处理方法handleMessage,唯一对外开放的方法;二是定义一个链的编排方法setNext,设置下一个处理者;三是定 义了具体的请求者必须实现的两个方法:定义自己能够处理的级别与具体的处理任务。 public class ConcreteHandler1 extends Handler { // 定义自己的处理逻辑 protected Response echo(Request request) { // 完成处理逻辑 return null; } // 设置自己的处理级别 protected Level getHandlerLevel() { // 设置自己的处理级别 return null; } } public class ConcreteHandler2 extends Handler { // 定义自己的处理逻辑 protected Response echo(Request request) { // 完成处理逻辑 return null; } // 设置自己的处理级别 protected Level getHandlerLevel() { // 设置自己的处理级别 return null; } } public class ConcreteHandler3 extends Handler { // 定义自己的处理逻辑 protected Response echo(Request request) { // 完成处理逻辑 return null; } // 设置自己的处理级别 protected Level getHandlerLevel() { // 设置自己的处理级别 return null; } } public class Level { // 定义一个请求和处理等级 } public class Request { // 请求的等级 public Level getRequestLevel() { return null; } } public class Response { // 处理者返回的数据 } public class Client { public static void main(String[] args) { // 声明出所有的处理节点 Handler handler1 = new ConcreteHandler1(); Handler handler2 = new ConcreteHandler2(); Handler handler3 = new ConcreteHandler3(); // 设置链中的阶段顺序,1-->2-->3 handler1.setNext(handler2); handler2.setNext(handler3); // 提交请求,返回结果 Response response = handler1.handlerMessage(new Request()); } }
在实际应用中,一般会有一个封装类对责任模式进行封装,也就是替代Client类,直接返回链中第一个处理者,具体链的设置不需要高层次模块关系,这样更简化了高层次模块的调用,减少模块间的耦合,提高系统的灵活性。
2 优点
2.1 最显著就是:请求和处理分开。请求者可以不用知道是谁处理的,处理者可以不用知道请求的全貌,两者解耦,提高系统的灵活性。
2.2 承接第一点,个人认为最大的好处就是把星状的耦合关系变成直线型的耦合关系,使原本“一对多”的耦合关系,变为“一对一”耦合(因为事件只与第一个处理对象耦合,每个处理对象又只与后面一个对象耦合)。
3 缺点
3.1 性能问题:每个请求都从链头遍历到链尾,特别是在链比较长的时候,性能是一个非常大的问题。
3.2 不便于调试,由于采用了类似于递归的方式,调试时逻辑比较复杂。
4 应用场景
责任链模式的核心是屏蔽了请求的处理过程(即请求者可以不用知道到底是谁来处理的)。
其表面上看来,用面向对象的“链表+遍历+函数调用+判断”来替换面向过程的“若干if-else判断”,以至于我起初认为这个模式完全是为了面向对象取代if判断而生的。
但实质上,降低了请求与处理对象之间的耦合,分析见上。
4.1某一请求根据条件,只需少数(或一个)对象处理,但却需要在较多对象中做选择的情况;
4.2 请求处理时,不能越权,只能按步骤判断处理的情况;
5 注意事项
5.1 链长需要控制,应避免出现超长链的情况;
6 扩展
6.1某事件需要多个大对象共同参与处理的情况(每个对象处理一部分,但非每个对象每时每刻都参与的情境);[冒似此景下最能发挥效能,但要考虑设计是否有问题。。。]
7 范例
(小例,请假,因为不能越权嘛,你只能访问直接上司。。。)
类图如下:
源代码
package _10_ChainOfResponsibility; public abstract class Handler { private Handler nextHandler; public final AskForLeave handleMessage(AskForLeave ask) { AskForLeave leave = null; if (ask.getDays() <= this.getDays()) { leave = this.echo(ask); } else { if (this.nextHandler != null) leave = this.nextHandler.handleMessage(ask); else ;// 没有处理者 } return leave; } // 设置下一者 public void setNext(Handler handler) { nextHandler = handler; } // 每个处理者都有处理等级 protected abstract int getDays(); // 每个处理者都必须实现处理任务 protected abstract AskForLeave echo(AskForLeave ask); } public class HeadHandler extends Handler { @Override protected int getDays() { return 1; } @Override protected AskForLeave echo(AskForLeave ask) { ask.setResult(true); return ask; } } public class ManagerHandler extends Handler { @Override protected int getDays() { return 3; } @Override protected AskForLeave echo(AskForLeave ask) { ask.setResult(true); return ask; } } public class ChiefHandler extends Handler { @Override protected int getDays() { return 7; } @Override protected AskForLeave echo(AskForLeave ask) { ask.setResult(true); return ask; } } public class HumanResourceHandler extends Handler { @Override protected int getDays() { return 15; } @Override protected AskForLeave echo(AskForLeave ask) { ask.setResult(true); return ask; } } public class AskForLeave { private int days; private boolean result = false; public AskForLeave(int days) { this.days = days; } public boolean getResult() { return result; } public void setResult(boolean result) { this.result = result; } public int getDays() { return days; } } public class Client { public static void main(String[] args) { Handler h1 = new HeadHandler(); Handler h2 = new ManagerHandler(); Handler h3 = new ChiefHandler(); Handler h4 = new HumanResourceHandler(); h1.setNext(h2); h2.setNext(h3); h3.setNext(h4); AskForLeave ask1 = new AskForLeave(5); AskForLeave ask2 = new AskForLeave(15); AskForLeave ask3 = new AskForLeave(16); h1.handleMessage(ask1); System.out.println("请假5天,是否批准? " + ask1.getResult()); h1.handleMessage(ask2); System.out.println("请假15天,是否批准? " + ask2.getResult()); h1.handleMessage(ask3); System.out.println("请假16天,是否批准? " + ask3.getResult()); } }
结果:
请假5天,是否批准? true
请假15天,是否批准? true
请假16天,是否批准? false
转自:/article/1491888.html
相关文章推荐
- 设计模式学习之备忘录模式(Memento,行为型模式)(19)
- 设计模式笔记 15. Interpreter 解释器模式(行为型模式)
- 设计模式之行为型模式一
- python重温设计模式===>行为型
- 设计模式学习日志(15)-Command命令(行为型模式) (引用)
- 设计模式笔记--行为型模式之九--Strategy模式
- 【设计模式】—-(22)责任链模式(行为型)
- [导入]C#面向对象设计模式纵横谈(14):Chain of Responsibility 职责链模式(行为型模式).zip(9.54 MB)
- 设计模式 ( 十八 ) 策略模式Strategy(对象行为型)
- [导入]C#面向对象设计模式纵横谈(18):(行为型模式) Iterator 迭代器模式.zip(8.04 MB)
- 设计模式笔记(14)---模板方法模式(行为型)
- 设计模式23——行为型模式之模板方法模型
- 设计模式(十三)观察者模式(行为型)
- Mediator中介者(行为型设计模式)
- 设计模式(4)-行为型-命令模式(Command)
- 行为型设计模式
- Java设计模式之行为型模式(观察者模式)
- 【23种设计模式】行为型模式 > 责任链模式
- 设计模式 : Template method 模板方法模式 -- 行为型
- 【设计模式攻略】行为型模式之Iterator模式