标签:
职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。
适用场景:
1、有多个的对象可以处理一个请求,哪个对象处理该请求运行时刻自动确定;
2、在不明确指定接收者的情况下,向多个对象中的一个提交一个请求;
3、处理一个请求的对象集合应被动态指定。
在大学里面当班干部,时常要向上级申请各方面的东西。譬如申请全班外出秋游,普通同学将申请表交给班长,班长签字之后交给辅导员,辅导员批准之后上交到主任办公室…就是这样,一个请求(这里是一份申请表)有时候需要经过好几个级别的处理者(这里是辅导员、主任)的审查才能够最终被确定可行与否。
在这里表现出来的是一个职责链,即不同的处理者对同一个请求可能担负着不同的处理方式、权限,但是我们希望这个请求必须到达最终拍板的处理者(否则秋游就没戏了)。这种关系就很适合使用职责链模式了。
代码实现如下:
- interface Levels {
- public static final int LEVEL_01 = 1;
- public static final int LEVEL_02 = 2;
- public static final int LEVEL_03 = 3;
- }
- abstract class AbstractRequest {
- private String content = null;
-
- public AbstractRequest(String content) {
- this.content = content;
- }
-
- public String getContent() {
- return this.content;
- }
-
-
- public abstract int getRequestLevel();
- }
- class Request01 extends AbstractRequest {
- public Request01(String content) {
- super(content);
- }
-
- @Override
- public int getRequestLevel() {
- return Levels.LEVEL_01;
- }
- }
-
- class Request02 extends AbstractRequest {
- public Request02(String content) {
- super(content);
- }
-
- @Override
- public int getRequestLevel() {
- return Levels.LEVEL_02;
- }
- }
-
- class Request03 extends AbstractRequest {
- public Request03(String content) {
- super(content);
- }
-
- @Override
- public int getRequestLevel() {
- return Levels.LEVEL_03;
- }
- }
- abstract class AbstractHandler {
-
- private AbstractHandler nextHandler = null;
-
-
- public final void handleRequest(AbstractRequest request) {
-
-
- if (this.getHandlerLevel() == request.getRequestLevel()) {
- this.handle(request);
- } else {
-
- if (this.nextHandler != null) {
- System.out.println("当前 处理者-0" + this.getHandlerLevel()
- + " 不足以处理 请求-0" + request.getRequestLevel());
-
-
- this.nextHandler.handleRequest(request);
- } else {
- System.out.println("职责链上的所有处理者都不能胜任该请求...");
- }
- }
- }
-
-
- public void setNextHandler(AbstractHandler nextHandler) {
- this.nextHandler = nextHandler;
- }
-
-
- protected abstract int getHandlerLevel();
-
-
- protected abstract void handle(AbstractRequest request);
- }
- class Handler01 extends AbstractHandler {
- @Override
- protected int getHandlerLevel() {
- return Levels.LEVEL_01;
- }
-
- @Override
- protected void handle(AbstractRequest request) {
- System.out.println("处理者-01 处理 " + request.getContent() + "\n");
- }
- }
-
- class Handler02 extends AbstractHandler {
- @Override
- protected int getHandlerLevel() {
- return Levels.LEVEL_02;
- }
-
- @Override
- protected void handle(AbstractRequest request) {
- System.out.println("处理者-02 处理 " + request.getContent()+ "\n");
- }
- }
-
- class Handler03 extends AbstractHandler {
- @Override
- protected int getHandlerLevel() {
- return Levels.LEVEL_03;
- }
-
- @Override
- protected void handle(AbstractRequest request) {
- System.out.println("处理者-03 处理 " + request.getContent()+ "\n");
- }
- }
- public class Client {
- public static void main(String[] args) {
-
- AbstractHandler handler01 = new Handler01();
- AbstractHandler handler02 = new Handler02();
- AbstractHandler handler03 = new Handler03();
-
-
- handler01.setNextHandler(handler02);
- handler02.setNextHandler(handler03);
-
-
- AbstractRequest request01 = new Request01("请求-01");
- AbstractRequest request02 = new Request02("请求-02");
- AbstractRequest request03 = new Request03("请求-03");
-
-
- handler01.handleRequest(request01);
- handler01.handleRequest(request02);
- handler01.handleRequest(request03);
- }
- }
测试结果:
- 处理者-01 处理 请求-01
-
- 当前 处理者-01 不足以处理 请求-02
- 处理者-02 处理 请求-02
-
- 当前 处理者-01 不足以处理 请求-03
- 当前 处理者-02 不足以处理 请求-03
- 处理者-03 处理 请求-03
在上面抽象处理者 AbstractHandler 类的 handleRequest() 方法中,被 protected 修饰,并且该方法中调用了两个必须被子类覆盖实现的抽象方法,这里是使用了模板方法模式(Template Mehtod)。其实在这里,抽象父类的 handleRequest() 具备了请求传递的功能,即对某些请求不能处理时,马上提交到下一结点(处理者)中,而每个具体的处理者仅仅完成了具体的处理逻辑,其他的都不用理。
记得第一次看到职责链模式的时候,我很惊讶于它能够把我们平时在代码中的 if..else.. 的语句块变成这样灵活、适应变化。例如:如果现在辅导员请长假了,但我们的秋游还是要争取申请成功呀,那么我们在 Client 类中可以不要创建 handler02,即不要将该处理者组装到职责链中。这样子处理比 if..else..好多了。或者说,突然来了个爱管闲事的领导,那么我照样可以将其组装到职责链中。
关于上面使用场景中提到的3个点:
1、处理者在运行时动态确定其实是我们在 Client 中组装的链所引起的,因为具体的职责逻辑就在链中一一对应起来;
2、因为不确定请求的具体处理者是谁,所以我们把所有可能的处理者组装成一条链,在遍历的过程中就相当于向每个处理者都提交了这个请求,等待其审查。并且在审查过程中,即使不是最终处理者,也可以进行一些请求的“包装”操作(这种功能类似于装饰者模式),例如上面例子中的签名批准;
3、处理者集合的动态指定跟上面的第1、2点类似,即在 Client 类中创建了所有可能的处理者。
不足之处:
1、对于每一个请求都需要遍历职责链,性能是个问题;
2、抽象处理者 AbstractHandler 类中的 handleRequest() 方法中使用了递归,栈空间的大小也是个问题。
个人看法:
职责链模式对于请求的处理是不知道最终处理者是谁,所以是运行动态寻找并指定;而命令模式中对于命令的处理时在创建命令是已经显式或隐式绑定了接收者。
职责链模式(Chain of Responsibility)的Java实现
标签:
原文地址:http://www.cnblogs.com/loritin/p/5347991.html