CoR 模式 (一种)

 

 

CoR(Chain of Responsibility) 即职责链设计模式：使多个对象都有机会处理请求（Request），从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理他为止。

职责链设计模式 大概有三个角色：
（1）请求（Request）：封装请求信息
（2）处理器（Handler）：处理请求（Request），一个具体处理器一般只处理一种请 求，如果它不能处理传递过来的请求，那么它就把该请求传递给职责链中的下一个处理器（后继处理器 successor）。
（3）客户端（Client）：发送请求

定义不再多说，直接看实现。下面是一个传统的CoR实现：

1，代表抽象请求的接口(Request)

 

public interface Request{
    //......
} 

2，实现Request接口的实现类，HelpRequest，PrintRequest，SaveRequest
    假设有一个文本编辑器，用户界面上有三个按钮 Help，Print 和 Save
    HelpRequest 代表 当用户点击 Help 按钮时产生的 帮助请求，

    PrintRequest 代表 当用户点击 Print 按钮时产生的 打印请求，
    SaveRequest 代表 当用户点击 Save 按钮时产生的 保存请求。

//帮助请求
public class HelpRequest implements Request{
    //......
}
//打印请求
public class PrintRequest implements Request{
    //......
}
//保存请求
public class SaveRequest implements Request{
    //......
}

 

3，代表抽象处理器的接口Handler：

public interface Handler{
    void handleRequest(Request request);
}

 

4，实现处理器接口的实现类 HelpHandler，PrintHandler，SaveHandler：
  HelpHandler 处理 帮助请求（HelpRequest）

public class HelpHandler implements Handler{
    //后继处理器
    private Handler successor;
    public HelpHandler(Handler successor){this.successor = successor;}
    public void handleRequest(Request request) {
        if(request instanceof HelpRequest){
             System.out.println("HelpHandler handle " +request.getClass().getSimpleName());
             // handle request
        }else{
            System.out.println("PrintHandler can't handle "+request.getClass().getSimpleName());
            if(successor != null)
                successor.handleRequest(request);
        }
    }
}

 

    PrintHandler 处理 打印请求（PrintRequest）

public class PrintHandler implements Handler{
    //后继处理器
    private Handler successor;
    public PrintHandler(Handler successor){this.successor = successor;}
    public void handleRequest(Request request) {
        if(request instanceof PrintRequest){
            System.out.println("PrintHandler handle "+request.getClass().getSimpleName());
            // handle request
        }else{
            System.out.println("PrintHandler can't handle "+request.getClass().getSimpleName());
           if(successor != null)
                successor.handleRequest(request);
        }
    }
}

 

    SaveHandler处理 保存请求（SaveRequest）

 

 

public class SaveHandler implements Handler{
    //后继处理器
    private Handler successor;
    public SaveHandler(Handler successor){this.successor = successor;}
    public void handleRequest(Request request) {
        if(request instanceof SaveRequest){
            System.out.println("SaveHandler handle "+request.getClass().getSimpleName());
            // handle request
        }else{
            System.out.println("SaveHandler can't handle "+request.getClass().getSimpleName());
            if(successor != null)
                successor.handleRequest(request);
        }
    }
}

 

5，客户端 Client 类

public class Client{
    public static void main(String[] args){
        Handler handler1 = new HelpHandler(null);
        Handler handler2 = new PrintHandler(handler1);
        Handler handler3 = new SaveHandler(handler2);

        handler3.handleRequest(new HelpRequest());
        handler3.handleRequest(new PrintRequest());
        handler3.handleRequest(new SaveRequest());
    }
}

 

运行 Client 类 输出如下：

SaveHandler can't handle HelpRequest
PrintHandler can't handle HelpRequest
HelpHandler handle HelpRequest
SaveHandler can't handle PrintRequest
PrintHandler handle PrintRequest
SaveHandler handle SaveRequest

相关链接 ： http://www.iteye.com/topic/411222 CoR 模式 (另一种)

 

-----------------------------------------------------

 

用抽象类也可以，不过要把 handleRequest 中
（1）这个处理器是否能处理这个请求
和
（2）处理相应的请求
这两个功能分离出来，定义成抽象方法供子类（具体处理器）实现

 

 

-----------------------------------------------------

 

PipeLine + Value

责任链模式我个人觉得，这种纯的责任链似乎并没有太大的意义，反而感觉效率不高，虽然看起来很规整。tomcat的pipeline的概念和valve的概念，虽然不是纯的责任链模式，但是我觉得这个的应用范围更广一些吧。。。也更为合适一点吧

职责链模式 效率是差了一些
“tomcat的pipeline的概念和valve的概念”，能说明一下吗？

其实纯的责任链模式我的理解是，一种责任推卸的模式，直到有承担责任的模块接收这个请求，并处理这个请求。这样的情况确实不太多吧。（个人觉得哈）。
    所谓的pipeline的概念，在以前的turbine框架（一个非常优秀的MVC框架）中就有使用。其大体模式和概念如下：
    其实PipeLine类似于Servlet里的FilterChain的概念，而valve类似于Filter。就是一个请求流经这个PipeLine中的每个Valve节点，该节点都对这个请求做一定的处理，而不是纯的责任链模式那样，把责任往下推。是想做了相应的处理后，在把处理后的请求移交给下一个Valve进行处理。举个例子：在一次请求Servlet的过程中，可能有些处理是所有的请求都需要做的，比如设置CharSet，权限验证，或者URL的解析等等，这些处理构成了一个请求的Chain，所有的请求都要经过这些处理，才能进行下面的具体的业务处理。这个时候既可以这些共有的处理抽象出来，做成一个pipeline，这个pipeline有过个valve节点组成。。。。

   差不多就这个意思吧。。。用文字形容确实不太好说。
 
   pipeline：管道
   valve：阀门
   顾名思义就好理解了吧

PipeLine + Value 中的
Value类似于职责链中的Handler
只不过Value可以处理请求的一部分，并把未处理的部分
通过 PipeLine 传给下一个Value，直到请求全部被处理为止。。
是这个意思吧

谢谢解释 ！
管道 + 阀门
很生动。。

个人觉得没有必要去区分各种模式，无招胜有招。。。

但是模式已经作为一种公共词汇存在了（Builder,Factory,Singleton,...），
为了看懂别人的代码 和 便于交流，
你也必须了解这些词汇，
要达到“无招胜有招”的境界，
首先也得知己知彼啊。。

也有道理。。。。

这种模式好处在哪 不好的地方在哪能说下吗?