请问责任链真的是一种设计模式吗

坛子上讨论设计模式的也挺多的，但是关于这个责任链模式还没有人提及，我对责任链模式也有些疑惑，我的疑惑是，责任链真的是一种设计模式吗，我为什么有这种疑惑呢，因为在我用到和学习的责任链一共有3种，但是n多的书上就是那么一种最基础的责任链模式。在我的心里，只要能完成责任传递的都可以称之为责任链。当然也有可能我的这种理解是错误的，但如果我的理解是错误的，那么就是说每种模式都是有固定形态的，简单的模式是有固定形态，这我承认，但是如果说所有的模式都有固定的形态我不太相信，下面我就用文章来说明我的观点。

下面我详细说说我眼里的3种责任链模式：
1， 基本版责任链
这里所谓的基本责任链模式是指书上网上到处都有的责任链模式，其实这种模式网上到处都有，我就炒炒冷菜。让我们来看看下面这个关于它的uml图

图1，见附件
这是最简单的责任链模式，但是事实上我很少看到它在真实的系统中被使用（也有可能经验不足）。大家看到，我在图中给接口和类取的名字是Filter，没错，这个模式待会将会和正真的Filter相比较。下面我们就看看在spring中如何实现这么一种责任链模式。
首先是Filter的接口如下：

/**
 * @author 张荣华(ahuaxuan)
 * {@link http://ahuaxuan.iteye.com}
 * @version $Id$
 */
public interface Filter {
	
	void executeFilter();
	
}

接着是一个抽象类，用来hold住下一个Filter实例的引用

/**
 * @author 张荣华(ahuaxuan)
 * {@link http://ahuaxuan.iteye.com}
 * @version $Id$
 */
public abstract class BaseFilter implements Filter {
	
	private Filter nextFilter;

	public void doNextFilter(){
		if (nextFilter != null) {
			nextFilter.executeFilter();
		} else {
			// do something you need here!
			System.out.println("there is no filter in the chain!!!!!!!!");
		}
	}

	/**
	 * 该方法用来注入下一个filter
	 * @param nextFilter
	 */
	public void setNextFilter(Filter nextFilter) {
		this.nextFilter = nextFilter;
	}
}

接着就是3个具体的filter了。同样，让我们来看一下这3个具体的filter的代码:
1权限检查filter

/**
 * @author 张荣华(ahuaxuan)
 * {@link http://ahuaxuan.iteye.com}
 * @version $Id$
 */
public class AuthFilter extends BaseFilter {

	public void executeFilter(){
		System.out.println("1------------check the user in this filter!");
		doNextFilter();
		System.out.println("2------------check the user in this filter!");
	}
}

2url重写filter

/**
 * @author 张荣华(ahuaxuan)
 * {@link http://ahuaxuan.iteye.com}
 * @version $Id$
 */
public class URLRewriteFilter extends BaseFilter {

	public void executeFilter(){
		System.out.println("1------------do url rewrite in this filter");
		doNextFilter();
		System.out.println("2------------do url rewrite in this filter");
	}
}

3其他的filter

/**
 * @author 张荣华(ahuaxuan)
 * {@link http://ahuaxuan.iteye.com}
 * @version $Id$
 */
public class OtherFilter extends BaseFilter {

	public void executeFilter(){
		System.out.println("1---------------do other things in this filter");
		doNextFilter();
		System.out.println("2---------------do other things in this filter");
	}
}

3个具体的filter有了之后就等组装“链”了。我们看看spring中的配置：

<bean id="authFilter" class="org.easy.sample.designpattern.reschain.one.AuthFilter">
    	<property name="nextFilter" value="urlRewriteFilter"></property>
    </bean>
    <bean id="urlRewriteFilter" class="org.easy.sample.designpattern.reschain.one.URLRewriteFilter">
    	<property name="nextFilter" value="otherFilter"></property>
    </bean>
<bean id="otherFilter" class="org.easy.sample.designpattern.reschain.one.OtherFilter"/>

O了，就这样，当你从spring的的context中得到这个authFilter的时候，你其实得到了一条链，当你调用authFilter的方法是，这个调用会沿着链向下传递。到目前为止，我们已经实现了一个很搓（差）的责任链了，现在如果你在使用struts1.x系列，那么你就可以把这个代码搬到struts1.x里，给action实现它自己的不依赖于servlet容器的拦截器了（当然如果是你真的想的话）。

众所周知的责任链成型了，但是你能忍受这种所谓的责任链模式吗，至少我不能，即使我使用struts1.x，我也不会傻到把上面这个破代码搬到项目里去的。那么就再让我们来看看第二种责任链模式吧

2， 混血版责任链(基于观察者的责任链)
我之前写了一篇关于观察者的文章（ http://www.iteye.com/topic/102068 ），在这篇文章中，我曾经说过观察者稍微改一下就可以变成责任链，也就是说我们可以通过观察者来实现同上面一样的功能。这里我只简单描述一下如何用观察者来实现责任链。当然首先我们必须要理解观察者模式，如果不清楚观察者模式的就看http://www.iteye.com/topic/102068 这篇文章吧。

如果说之前的那个责任链是通过nextFilter引用而形成的话，那么观察者模式中的观察者的集合也可以看作是一个链，只不过这个链上的每一个update方法都是要执行的，我们可以让它们某些执行某些不执行吗，当然可以了，只需要在写update方法的实现判断一下是否需要执行就行了，判断的条件就是update传进去的，比如说被观察者如下：

/**
 * @author 张荣华(ahuaxuan)
 * @version $Id$
 */
public class Subject extends Observable{
	
	/**
	 * 业务方法，一旦执行某个操作，则通知观察者
	 */
	public void doBusiness(){
		if (true) {
			super.setChanged();
		}
		
		
		notifyObservers("mail");
		notifyObservers("jms");
	}

	
	public static void main(String [] args) {
		//创建一个被观察者
		Subject subject = new Subject();
		
		//创建两个观察者
		Observer mailObserver = new MailObserver();
		Observer jmsObserver = new JMSObserver();
		
		//把两个观察者加到被观察者列表中
		subject.addObserver(mailObserver);
		subject.addObserver(jmsObserver);
		
		//执行业务操作
		subject.doBusiness();
		
		
	}
}

两个观察者如下：

/**
 * @author 张荣华(ahuaxuan)
 * @version $Id$
 */
public class JMSObserver implements Observer{

	public void update(Observable o, Object arg) {
		if ("jms".equals(arg)) {
			System.out.println("发送消息给jms服务器的观察者已经被执行");
		}
	}
}

和

/**
 * @author 张荣华(ahuaxuan)
 * @version $Id$
 */
public class MailObserver implements Observer{

	/**
	 * 这个类取名为MailObserver，顾名思义，她是一个用来发送邮件的观察者
	 */
	public void update(Observable o, Object arg) {
		if ("mail".equals(arg)) {
			System.out.println("发送邮件的观察者已经被执行");
		}
	}

}

这样的话，每次通知观察者，在观察者列表中只有一个或多个观察者被执行了，如此一来，也实现了第一中观察者的功能。那么如果要为struts1.x实现不依赖于servlet容器的拦截器的时候我会用它吗？还是不会，因为虽然我也认为它是责任链，但事实上它更具备观察者的特征，比如说有一个列表，执行的时候需要遍历列表，并执行列表中对象的方法，这明显是观察者的特征。所以说它更像观察者，如果说观察者是父亲，责任链是母亲，那这个第二种责任链其实更像父亲。

虽然我还是不会用它来实现上面的需求，但是有一点我倒觉得这种用法比较像spring提供的事件机制，只不过在事件机制中是根据参数是否是属于某一类型（指instanceOf方法）来判断事件是否应该发生的，不管怎么说，都是用观察者模式来实现的（貌似我又在谈观察者的重要性了）。

其实上面的这个equals判断是可以用正则表达式来代替，也就是说每一个update方法执行之前可以先用正则表达式匹配一下参数是否符合要求，这样灵活性就更大了，在第3种责任链中，我将会用正则表达式来判断责任的传递。

接下来轮到第3种责任链了（口干舌燥，喝点水吧），
3， 潇洒版责任链
我们来看看所谓的潇洒版的责任链模式，如下图所示：
图2，见附件

很明显，这个图复杂多了，可以说这个责任链和基本版的责任链有本质的区别，他不是一个责任对象引用另外一个责任对象这种形式，通过这种形式形成了一条看不见的链。但是这够oo吗，所谓责任链，其实暗示着我们这里有两个类，一个是责任，一个是链，如果像基本版的责任链就只有一个责任类，通过责任之间的依赖形成了一个链。显然这种方式明显比不上潇洒版责任链，在这种责任链中，责任是一个对象，链也是一个对象。

我们来仔细看一下上面这个图，责任就是ConcreateHandler，链就是ConcreateHandlerChain，HandlerConfig是对责任的配置类，事实上链和责任之间的关系是靠HandlerConfig联系起来的。

首先我们来看一下链对象中的executeHandler()方法，这个方法是整个责任链的核心：

private HandlerConfig [] handlerConfigs; 
private int firstElement = -1;
private String doRegex;
/**
	 * 这个方法是核心方法，它根据正则表达式来决定哪些filter需要被执行，哪些filter不需要被执行
	 */
	public void executeHandler() {
		if (handlerConfigs == null) {
			// 调用业务方法
			return;
		}
		
		++firstElement;
		if (firstElement < handlerConfigs.length) {
			if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) {
				handlerConfigs[firstElement].getHandler().executeHandler(this);
			} else {
				this.executeHandler();
			}
		}
	}

值得注意的是这个方法中有一个递规操作用，它的作用是当前handler不被执行的话就去判断是否执行下一个handler，我对递规还是有点怕的，大家有其他方法吗
我们再来看看责任对象中的executeHandler方法，这个方法就是每个责任对象的行为：

/**
 * @author 张荣华(ahuaxuan)
 * {@link http://ahuaxuan.iteye.com }
 * @version $Id$
 */
public class AuthTestHandler implements Handler {

	public void executeHandler(HandlerChain handlerChain){
		System.out.println("1----------check the user in this filter!");
		handlerChain.executeHandler();
		System.out.println("2----------check the user in this filter!");
	}
}

就是通过责任对象和链对象之间的重复调用，我们就实现了责任的传递，那为什么还需要一个config呢，这是因为责任链上的责任我认为应该是不带状态的，这个用户在写自己的责任对象的时候不需要考虑它的配置，因为通常它的配置是写在配置文件中的。我们来看一下config类：

/**
 * @author 张荣华(ahuaxuan)
 * {@link http://ahuaxuan.iteye.com }
 * @version $Id$
 */
public class HandlerConfig {
	private Handler handler;
	private String handlerName;
	private String regex;
private Pattern pattern;
//省略getter和setter方法
}

熟悉tomcat的同学大概已经猜出来了，这种责任链事实上就是tomcat中的filter，几乎一样的，那么让我们再看看测试方法：

public static void main(String[] args) {
		
		HandlerConfig [] configs = new HandlerConfig[]{
			new HandlerConfig(), new HandlerConfig(), new HandlerConfig()
		};
		configs[0].setHandler(new AuthTestHandler());
		configs[0].setHandlerName("authFilter");
		configs[0].setRegex("\\d*");
		
		
		configs[1].setHandlerName("charsetFilter");
		configs[1].setHandler(new CharsetTestHandler());
		configs[1].setRegex("^[A-Za-z]+$");
		
		configs[2].setHandlerName("otherFilter");
		configs[2].setHandler(new OtherTestHandler());
		configs[2].setRegex("\\d*");
		
		System.out.println("chain1");
		
		EasyHandlerChain chain = new EasyHandlerChain("21");
		chain.setHandlerConfigs(configs);
		chain.executeHandler();
		
		System.out.println("");
		System.out.println("chain2");
	
		
		EasyHandlerChain chain1 = new EasyHandlerChain("asdf");
		chain1.setHandlerConfigs(configs);
		chain1.executeHandler();
	}

上面一些config对象的创建可以放到框架中，每个线程都创建一个EasyHandlerChain就行了，当然我们也可以把config对象创建所需要的配置放到annotation中去，但在这个例子中没有必要这样做。在测试方法中，每个config都设置了匹配表达式，每个chain对象都设置了匹配的值，简直和tomcat的filter配置一摸一样是吗。

附件是上面3种责任链的源代码， 尤其是第3种，只看上面贴出来的代码不太容易理解，看看源代码，运行一下就明白了。

总结一下吧：我们可以看到，在责任链的实现中我们使用到3种模式，这也是我的疑惑，责任链是一种设计模式吗，我认为它不应该属于某一种模式，责任链是一种思想，这种思想凌驾于模式之上，我们可以用模式来实现这种思想。这就是我想说的，如果你觉的这种理解是不正确的，请务必说明理由。

评论

28 楼 taowen 2008-06-30  

用第一种方式实现的职责链可以在runtime选择下一个handler是谁,但是用第二种就不能,用第三种就需要把这个放在配置里.灵活性,还是第一种最好.

27 楼 jbon 2008-05-20  

我认为这更像一种框架，我认为

模式，是一种思想，是不能以具体的编码代替各种具体情况的，不能简单的移植代码使用的
框架，是一种产品，是可以以具体的编码代替各种具体情况的，是可以将代码移植并使用的

比如，楼主的第三种方式，代码是可以直接拿到别的地方使用的，只需具体实现Handler就可以了。

26 楼 jbon 2008-05-20  

任何递归都是可以改写成循环

25 楼 cljspn 2008-04-25  

挺好呀，真的受益了，我现在也正在研究设计模式呀，想与楼主交个朋友，不知可不可以，我的Msn为[e-mail]如果可以就加我。不想就算了哈哈

24 楼 dykl001 2007-08-09  

模式本来就是一种思想，我觉得，不仅为解决某类问题的一种方案，更是一种思想的体现。面向oo的编程方式是在接触了模式之后，当然了只是我个人感受

23 楼 ahuaxuan 2007-07-30  

qinysong 写道

所以上面的重构代码，只需把firstElement 放到上面即可，如下所示，已通过测试，和你的效果一样

    firstElement += 1;
    for (; firstElement < handlerConfigs.length ; firstElement++) {
      if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) {
        handlerConfigs[firstElement].getHandler().executeHandler(this);
        return;
      }
    }

这个改法不错，之前有个哥们说到了，我之前没有认真得去想他的话，他说：

solospider 写道

嗯，思想不错。
不过就是有点不明白executeHandler() 为什么要用递归，一个循环遍历不就行了？

递规是我自然而然的去想到的，想到之后我就进了套子，认为这里只有递规了，也没有多想了，呵呵，谢谢，还是这个遍历比较好，其实俺也比较讨厌递规，出了问题不好找。

qinysong 写道

单向依赖法则是我从无环依赖原则(ADP)推演的，ADP表达包和包之间不能存在相互依赖，包是一种实体，而类也是一种实体，只不过小于包实体，所以类之间虽然在特殊的情况下不能避免循环依赖，但只要可能最好还是避免，这样得到的设计会更简单、更清晰和容易理解

首先，您能从ADP中推演单向依赖法则证明您对它的理解非常深入，这让我钦佩，但是我却不能同意包是一种实体的说法（抑或我对这个实体的定义的理解有偏差），我倒是觉得类之间的循环依赖并没有什么不妥。之所以这样说是因为到处都有这种情况，比说tomcat，webwork，等

netpcc 写道

我还特意去翻了一下GOF的原著，里面2个模式的典型情况在结构上确实是相同的。
只不过职责连的变种比较多罢了。

就是因为责任链的变种多，就让我觉得他不应该是一种模式，呵呵（有点偏执了），查了一下headfirstdesignpattern，这本书里貌似也没有责任链这个模式的描述。

22 楼 shallon 2007-07-29  

1、实现的代码一样不能说明什么问题，如果说实现的类似，代理模式与装饰模式更加类似。
例如：aBorderDecorator.component->aScrollDecorator.componnent->aTextView
这是装饰模式的对象结构.
aClient.subject->aProxy.subject->aRealSubject
这是代理模式的对象结构.
aClient.aHandler->aConcreteHandler.successor->aConcreteHandler.successor
这是责任链模式的对象结构

描述模式的除了实现的代码样例之外，还有动机、限制、使用场合的东西。这些代表了思考和抽象外部世界的模式。责任链的动机是动态构造一条对象链，并将请求沿着对象链传递，重点在怎么构造这样一条对象链条。装饰的动机是动态的为一个对象添加一些额外的职责。从动机上说，代理和装饰更加接近，按照宝典的说法，装饰为对象添加新的业务功能，而代理则控制对对象的访问（例如，屏蔽远程对象的访问差异、延迟加载对象等）。

2、如果不能把发送者和接收者解耦的话，就不可能很容易的添加修饰。这个我不赞同，解耦与增加装饰不一定相关，不管对象的接口如何都是可以添加装饰的，其意图是不需要生成子类的情形下即可给对象添加职责，从而避免了静态实现所有功能组合，导致子类急剧增加。

21 楼 netpcc 2007-07-28  

通常弱化发送者和接收者之间的耦合关系和增加修饰这两个要求是同时存在的。或者说是互相依存的。

如果不能把发送者和接收者解耦的话，就不可能很容易的添加修饰。

而且从具体的实现来看，把Decorator的实现结构看作职责连没有任何问题。

我还特意去翻了一下GOF的原著，里面2个模式的典型情况在结构上确实是相同的。
只不过职责连的变种比较多罢了。

模式中几乎都是你中有我，我中有你。将他们完全割裂开来没有什么意义。

20 楼 qinysong 2007-07-27  

ahuaxuan 写道

qinysong 写道

另，是不是可以作下面重构，不知有没有影响代码的意图。将

        ++firstElement;   
        if (firstElement < handlerConfigs.length) {   
            if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) {   
                handlerConfigs[firstElement].getHandler().executeHandler(this);   
            } else {   
                this.executeHandler();   
            }   
        }

  
改写成

	for (firstElement = 0; firstElement < handlerConfigs.length; firstElement++) { 
		if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) { 
			handlerConfigs[firstElement].getHandler().executeHandler(this);
			return;
		}   
	}

如果这样重构，导致的结果就是只要链上一某个不符合，那调用就结束（所有的方法依次出栈），这并不是我的目标，我是想如果有一个责任不符合，那么就继续执行链上的下一个责任，直到链尾为止，到达链尾后所有的方法依次出栈。

不好意思，上面的代码我没有实际的编译一下，其实你想要的效果就是HandlerChain的executeHandler方法，会调用一个符合条件的Handler对象进行处理，如果下标firstElement处的Handler不符合规则，就探索下一个，直至遍历到一个符合的为止（如果存在的话）。
所以上面的重构代码，只需把firstElement 放到上面即可，如下所示，已通过测试，和你的效果一样

    firstElement += 1;
    for (; firstElement < handlerConfigs.length ; firstElement++) {
      if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) {
        handlerConfigs[firstElement].getHandler().executeHandler(this);
        return;
      }
    }

单向依赖法则是我从无环依赖原则(ADP)推演的，ADP表达包和包之间不能存在相互依赖，包是一种实体，而类也是一种实体，只不过小于包实体，所以类之间虽然在特殊的情况下不能避免循环依赖，但只要可能最好还是避免，这样得到的设计会更简单、更清晰和容易理解

netpcc 写道

Decorator模式是结构模式,体现的是结构特点。

职责链是，行为模式的一种，是从他的行为上来分析。

职责链和Decorator模式通常是同一事物的两方面。

将模式分类为结构型模式 或行为型模式，并不是对于同一事物，主观上从不同的角度去观察得到的，而是看这个模式客观上主要解决哪方面的问题，结构型模式解决类和对象之间组合问题，行为型模式解决行为分配的问题，当然这也含有一个侧重的问题，比如结构型中也有行为分配的成分，行为型中也有类或对象组合的成分。

职责链和Decorator模式决不是同一事物的两个方面。
职责链的意图通过一条候选对象链隐式的向一个对象发送请求，从而弱化请求的发送者和接收者之间的耦合关系；Decorator的意图是动态的给对象添加额外的职责，比如jdk中的输入输出流类，在最基本的字节流基础上，具有各种装饰器，通过这些装饰器，为最基本的流增加各种额外功能或修饰，比如增加内存缓冲和数据类型等，这样就应该很好理解和职责链的区别

19 楼 netpcc 2007-07-27  

对了，问一下怎么才能获得积分

18 楼 netpcc 2007-07-27  

Decorator模式是结构模式,体现的是结构特点。

职责链是，行为模式的一种，是从他的行为上来分析。

职责链和Decorator模式通常是同一事物的两方面。

qinysong的改法很不好。
首先这种改法破坏了Observer的一旦有事件发生，所有监听者都应该收到通知的原则。因此已经不能算Observer模式了。

作为职责链模式来说，他又丧失了各个组建间的协作性。
比如说对于URL的解码来说，可以由类A来完成域名部分的IDN解码，由类B来完成路径部分的16进制的解码。16进制解码可以按照各种不同的编码方式来选择。

至于交叉引用的问题，只需要将事件本身和事件到处理器的映射分成2个类就可以了。

17 楼 ahuaxuan 2007-07-27  

qinysong 写道

说一下我的想法
您的第一种职责链，即所称的 基本版责任链，我觉得更是装饰器Decorator模式的一种应用。在你的代码示例中，每一种Filter在调用后面的Filter前后都做了一下额外的操作，虽然只是System.out；而职责链的目标是分离请求的调用者和接收者，虽然请求可以沿着链传递，但是逻辑上应该只有一个接收者对其处理。

您的第二种职责链，即所称的 混血版责任链，和netpcc等的观点一致，就是一个实现功能操作的改版的观察者实例

您说得不错，这两种方式其实都是用其他模式来实现所谓得责任链，这也是我认定观察者不是设计模式的原因。

qinysong 写道

您的第三种职责链，与原本的职责链相比，其实是将原来的一个类（包括处理和传递下一个的功能），分成了三个类——处理类、链类和配置类，这样修改后可能在极端的环境下有其好处，但在一般的情况下确明显的增加了程序设计的复杂度，而且你的Chain和handler的处理方法内的互相调用，即ConcreateHandlerChain中的
       

if (firstElement < handlerConfigs.length) {   
            if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) {   
                [b]handlerConfigs[firstElement].getHandler().executeHandler(this);   [/b]
            } else {   
                this.executeHandler();   
            }   
        }  

和ConcreateHandler中的

    public void executeHandler(HandlerChain handlerChain){   
        System.out.println("1----------check the user in this filter!");   
        [b]handlerChain.executeHandler();   [/b]
        System.out.println("2----------check the user in this filter!");   
    } 

互相交叉，有违单向依赖法则

单向依赖法则是指什么呢，好像面向对象设计的原则里好像没有关于单向依赖的描述呀。

qinysong 写道

另，是不是可以作下面重构，不知有没有影响代码的意图。将

        ++firstElement;   
        if (firstElement < handlerConfigs.length) {   
            if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) {   
                handlerConfigs[firstElement].getHandler().executeHandler(this);   
            } else {   
                this.executeHandler();   
            }   
        }

  
改写成

	for (firstElement = 0; firstElement < handlerConfigs.length; firstElement++) { 
		if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) { 
			handlerConfigs[firstElement].getHandler().executeHandler(this);
			return;
		}   
	}

如果这样重构，导致的结果就是只要链上一某个不符合，那调用就结束（所有的方法依次出栈），这并不是我的目标，我是想如果有一个责任不符合，那么就继续执行链上的下一个责任，直到链尾为止，到达链尾后所有的方法依次出栈。

16 楼 power1128 2007-07-27  

ahuaxuan 写道

阎宏那本书里是这样描述的：
在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成的一条链。请求在这个链上传递，知道链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。

我觉得不是很准确

阎宏的书的确不准确，还是要看Gof

15 楼 power1128 2007-07-27  

设计模式应该是以Gof为基础的，如果楼主要讨论责任链是否属于设计模式，那本书里写的都是设计模式。

14 楼 qinysong 2007-07-27  

说一下我的想法
您的第一种职责链，即所称的 基本版责任链，我觉得更是装饰器Decorator模式的一种应用。在你的代码示例中，每一种Filter在调用后面的Filter前后都做了一下额外的操作，虽然只是System.out；而职责链的目标是分离请求的调用者和接收者，虽然请求可以沿着链传递，但是逻辑上应该只有一个接收者对其处理。

您的第二种职责链，即所称的 混血版责任链，和netpcc等的观点一致，就是一个实现功能操作的改版的观察者实例

您的第三种职责链，与原本的职责链相比，其实是将原来的一个类（包括处理和传递下一个的功能），分成了三个类——处理类、链类和配置类，这样修改后可能在极端的环境下有其好处，但在一般的情况下确明显的增加了程序设计的复杂度，而且你的Chain和handler的处理方法内的互相调用，即ConcreateHandlerChain中的
       

if (firstElement < handlerConfigs.length) {   
            if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) {   
                [b]handlerConfigs[firstElement].getHandler().executeHandler(this);   [/b]
            } else {   
                this.executeHandler();   
            }   
        }  

和ConcreateHandler中的

    public void executeHandler(HandlerChain handlerChain){   
        System.out.println("1----------check the user in this filter!");   
        [b]handlerChain.executeHandler();   [/b]
        System.out.println("2----------check the user in this filter!");   
    } 

互相交叉，有违单向依赖法则

另，是不是可以作下面重构，不知有没有影响代码的意图。将

        ++firstElement;   
        if (firstElement < handlerConfigs.length) {   
            if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) {   
                handlerConfigs[firstElement].getHandler().executeHandler(this);   
            } else {   
                this.executeHandler();   
            }   
        }

  
改写成

	for (firstElement = 0; firstElement < handlerConfigs.length; firstElement++) { 
		if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) { 
			handlerConfigs[firstElement].getHandler().executeHandler(this);
			return;
		}   
	}

13 楼 yananay 2007-07-27  

因为struts1.x没有拦截器啊，但是我记得有一个额外的框架可以作补充，让struts拥有拦截器。


那你应该说责任链模式应用于 structs1.x 的拦截器方式。

12 楼 ahuaxuan 2007-07-27  

netpcc 写道

我觉得不用那么强调概念上的东西，能灵活运用就行了。

这一点我非常同意，所以我其实是在有意模糊责任链这个概念，为的就是想说明责任链可以被灵活的实现。

yananay 写道

首先不太明白搂主为什么总是拿structs 1.0 做例子呢？
有时候业务层一些解决方式和 structs 1.0 有直接的关系吗？

其次，责任链是否是一个模式很重要吗？

因为struts1.x没有拦截器啊，但是我记得有一个额外的框架可以作补充，让struts拥有拦截器。

yananay 写道

其次，责任链是否是一个模式很重要吗？

责任链是否是一个模式不重要，但是否理解它就比较重要了

11 楼 yananay 2007-07-27  

首先不太明白搂主为什么总是拿structs 1.0 做例子呢？
有时候业务层一些解决方式和 structs 1.0 有直接的关系吗？

其次，责任链是否是一个模式很重要吗？

10 楼 netpcc 2007-07-27  

ahuaxuan 写道

虚函数和MFC是c++的东西吧，包括这个名词（虚函数）我都不知道应该怎么理解（c++我早还给老师了）。

虚函数就是可以体现多态的函数。简单地说，JAVA中的所有方法都是虚函数。

ahuaxuan 写道

很显然阎宏的书是用java语言的，你看他对责任链的描述和gof的描述是一样的吗？

我觉得不用那么强调概念上的东西，能灵活运用就行了。
每个模式都说明了解耦和通过结构来保证约束的思想。
能明白这点就OK了。

9 楼 netpcc 2007-07-27  

前面source没看仔细，向楼主道歉。

第三种方法里有个小的职责链模式。
即handlerConfigs里的handler不符合时，调用默认实现。

但是在handlerConfigs里的各个handler之间并没有形成职责链。

所以说实际的程序中通常会把各个模式组合在一起。