CoR 模式 (一种)

譬如楼主那个 main 函数， 简直就是一个 handler 的矩阵 …… 唐僧都不带这么说话的。

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());

重复性高，大量复制粘贴出来的代码，一改就要改一片，维护起来非常痛苦。

重复性的指标有两个： 一个是熵，不过很难算，另一个就是长度，指导实践是最简单容易的了。

 

另外 bla 几句：

软件工程就是让烂程序员不会把项目搞得太糟糕的学问。

企业不关心程序怎么写，写程序是否开心愉快。企业的目的是赚钱，什么"伟大的产品" "代码的质量"都是手段而不是目的。

反正中国人力资源丰富，程序员工资超低，与其提高个体生产效率，不如多招几个烂 coder。

看见你鼓捣新东西，就会劝你收手，劝你回头干苦活去。

 

可能你非常讨厌函式，但是就算 java 消失了，函式编程都依然会存在。

 

上面的代码只是一个 职责链的测试代码，

我不知道重复性的指标有哪几个，那你怎么知道长度决定了 重复性呢

现在的 “长” 是为了以后的 ”短”

 

至于 软件工程 是以工程化方式开发软件的方法，

盖一栋大楼 用几个熟练技工就能完成吗。。笑话

我不认为有 "伟大的产品"，但 "代码的质量" 却是必要的

企业的目的是为了长远地赚钱。图眼前小利 有何前途

 

“反正中国人力资源丰富，程序员工资超低，与其提高个体生产效率，不如多招几个。”

不重视个体生产效率，多招几个就能 提高 生产力吗。。

 

 

 

这个远不如delegate方便。。。。。而且不会做无谓的事情。

我觉得按你的思路，这代码以后也不会变短，用起来也不会更舒服，改起来还得复制粘贴 ……

呵呵 极端了
我的意思是不要把所有事想的太极端
我说了 现在的 “长” 是为了以后的 ”短”
现在“长”不是错，为了以后能更短
长的东西就一定会重复吗。。
一定要复制粘贴吗。。

似乎应该做个抽象父类。然后其他几个handler继承这个抽象父类。

public abstract class AbstractHandler implements Handler {
	
	protected Handler successor;

	public AbstractHandler(Handler successor) {
		this.successor = successor;
	}

	public void handleRequest(Request request) {
		if (this.getClass().isInstance(request)) {
			System.out.println("handle "
					+ request.getClass().getSimpleName());
		} else {
			System.out.println("can't handle "
					+ request.getClass().getSimpleName());
			if (successor != null)
				successor.handleRequest(request);
		}
	}
}

BTW:此类模式应用真的不多见了。链式处理过程，无非两种：有顺序的和无顺序的。而且现代点的代码大多是配置型的，最著名的莫过于Servlet的Filter了。

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

public abstract class AbstractHandler implements Handler {  
    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);
} 

 

 

这个模式不一定只用于同一进程中，也可以是跨进程的：各个模块都向外暴露同样的服务接口，模块可以灵活装配。方便扩展和订制。

不必把职责链理解的那么死。
一个Handler 先处理 request 再交给 successor 那不就成了  “不推卸责任”了吗？

而职责链的缺陷是 Handler 与 Successor 耦合了。
而PipeLine(可以算是一种改进的 职责链模式)的好处是, Handler 是独立的互不耦合；怎样装配Handler，按什么顺序都有 PipeLine 来进行，一般是xml 配置文件，保持了很好的灵活性。

主题帖给出的是 职责链模式 的简单实现方式
简单才能直观嘛

“一个Handler 先处理 request 再交给 successor 那不就成了  “不推卸责任”了吗？”
你这么说证明你没好好看主题帖
handler首先检查自己是否能处理这个request，如果能处理，就处理
不能处理再交给successor

PipeLine和传统职责链 的主要区别 也不是你所说
主要区别 是 PipeLine 中的 Value “可能推卸部分职责”
而 传统职责链 中的 handler “如果不能处理则推卸全部职责”