CoR 模式 (一种)
?
?
CoR(Chain of Responsibility) 即职责链设计模式：使多个对象都有机会处理请求（Request），从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理他为止。
职责链设计模式 大概有三个角色：
（1）请求（Request）：封装请求信息
（2）处理器（Handler）：处理请求（Request），一个具体处理器一般只处理一种请 求，如果它不能处理传递过来的请求，那么它就把该请求传递给职责链中的下一个处理器（后继处理器 successor）。
（3）客户端（Client）：发送请求
定义不再多说，直接看实现。下面是一个传统的CoR实现：
1，代表抽象请求的接口(Request)
?
?
??? PrintHandler 处理 打印请求（PrintRequest）
看来不同的人有不同的追求。
有很多人在追求代码少。
我则一直在追求可维护性。也许是因为的工作是维护企业系统为主。
再设想开来，做平台的会追求可扩展性。做关键系统的追求安全性，稳定性。etc...<p>反正中国人力资源丰富，程序员工资超低，与其提高个体生产效率，不如多招几个烂 coder。</p>
<p>看见你鼓捣新东西，就会劝你收手，劝你回头干苦活去。</p>
<p>?</p>
<p><span style="color: #efefef;">可能你非常讨厌函式，但是就算 java 消失了，函式编程都依然会存在。</span></p><p>反正中国人力资源丰富，程序员工资超低，与其提高个体生产效率，不如多招几个。</p>
<p>?</p>
<p><span style="color: #efefef;">可能你非常讨厌函式，但是就算 java 消失了，函式编程都依然会存在。</span></p>
</div>
<p>?</p>
<p>上面的代码只是一个 职责链的测试代码，</p>
<p>我不知道重复性的指标有哪几个，那你怎么知道长度决定了 重复性呢</p>
<p>现在的 “长” 是为了以后的 ”短”</p>
<p>?</p>
<p>至于?软件工程 是以工程化方式开发软件的方法，</p>
<p>盖一栋大楼 用几个熟练技工就能完成吗。。笑话</p>
<p>我不认为有?"伟大的产品"，但?"代码的质量" 却是必要的</p>
<p>企业的目的是为了长远地赚钱。图眼前小利 有何前途</p>
<p>?</p>
<p>“反正中国人力资源丰富，程序员工资超低，与其提高个体生产效率，不如多招几个。”</p>
<p>不重视个体生产效率，多招几个就能 提高 生产力吗。。</p>
<p>?</p>
<p>?</p><p>反正中国人力资源丰富，程序员工资超低，与其提高个体生产效率，不如多招几个烂 coder。</p>
<p>看见你鼓捣新东西，就会劝你收手，劝你回头干苦活去。</p>
<p>?</p>
<p><span style="color: #efefef;">可能你非常讨厌函式，但是就算 java 消失了，函式编程都依然会存在。</span></p>
</div>
<p>?</p>
<p>这个远不如delegate方便。。。。。而且不会做无谓的事情。</p> protected Handler successor;
public AbstractHandler(Handler successor) {
this.successor = successor;
}
//定义为final,不能被子类继承
public final void handleRequest(Request request) {
if (canHandleRequest(request)) {
handleRequestMyself(request);
} else {
if (successor != null)
successor.handleRequest(request);
}
}
//这个处理器能否处理整个请求
protected abstract boolean canHandleRequest(Request request);
//处理相应的请求
protected abstract void handleRequestMyself(Request request);
} </pre>
?
<p>?</p> 27 楼 pipilu 2009-06-23 这个模式不一定只用于同一进程中，也可以是跨进程的：各个模块都向外暴露同样的服务接口，模块可以灵活装配。方便扩展和订制。 28 楼 raymond2006k 2009-06-24 不必把职责链理解的那么死。
一个Handler 先处理 request 再交给 successor 那不就成了 “不推卸责任”了吗？
而职责链的缺陷是 Handler 与 Successor 耦合了。
而PipeLine(可以算是一种改进的 职责链模式)的好处是, Handler 是独立的互不耦合；怎样装配Handler，按什么顺序都有 PipeLine 来进行，一般是xml 配置文件，保持了很好的灵活性。 29 楼 步行者 2009-06-24 raymond2006k 写道不必把职责链理解的那么死。
一个Handler 先处理 request 再交给 successor 那不就成了 “不推卸责任”了吗？
而职责链的缺陷是 Handler 与 Successor 耦合了。
而PipeLine(可以算是一种改进的 职责链模式)的好处是, Handler 是独立的互不耦合；怎样装配Handler，按什么顺序都有 PipeLine 来进行，一般是xml 配置文件，保持了很好的灵活性。
主题帖给出的是 职责链模式 的简单实现方式
简单才能直观嘛
“一个Handler 先处理 request 再交给 successor 那不就成了 “不推卸责任”了吗？”
你这么说证明你没好好看主题帖
handler首先检查自己是否能处理这个request，如果能处理，就处理
不能处理再交给successor
PipeLine和传统职责链 的主要区别 也不是你所说
主要区别 是 PipeLine 中的 Value “可能推卸部分职责”
而 传统职责链 中的 handler “如果不能处理则推卸全部职责”
30 楼 lishuaibt 2009-06-24 raymond2006k 写道不必把职责链理解的那么死。
一个Handler 先处理 request 再交给 successor 那不就成了 “不推卸责任”了吗？
而职责链的缺陷是 Handler 与 Successor 耦合了。
而PipeLine(可以算是一种改进的 职责链模式)的好处是, Handler 是独立的互不耦合；怎样装配Handler，按什么顺序都有 PipeLine 来进行，一般是xml 配置文件，保持了很好的灵活性。
同意！其实真正GoF里边介绍的纯的责任链模式我个人觉得适用范围很小！反而这种pipeline的思想用的更多一些吧
31 楼 步行者 2009-06-30 xiaohui5850 写道实际上这个就是一个方法回调
啥时候成模式了
？？？
java 不用方法调用，怎么实现模式啊。。。 32 楼 rain2005 2009-06-30 我一直没有模式的概念，就知道不断的重构，抽象。 33 楼 艾建锋 2009-07-02 if(action.equal("help")
{
HelpClass.fun();
}
else if(..)
{
....
}
else
{
...
}
是不是这个意思？ 34 楼 步行者 2009-07-02 艾建锋 写道if(action.equal("help")
{
HelpClass.fun();
}
else if(..)
{
....
}
else
{
...
}
是不是这个意思？
你这个是什么意思？？？
