本文深入浅出的讲述了设计模式中的职责链模式 , 并给出了简单的示例 , 例子浅显易懂 , 并附带源代码。 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

      职责链 模式属于行为模式。他的意图是使得多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。要沿着链转发请求，并保证接受者为隐式的，每个链上的对象都有一致的处理请求和访问链上后继者的接口。

适用性：

l         有多个对象处理请求，那个对象处理该请求在运行时可自动确定。

l         你想在不指名接受者的情况下，向多个对象中的一个提交请求。

l         可处理一个请求的对象集合应被动态指定。

参与者：

      Handler(Approver): 定义一个处理请求的接口，和一个后继连接 ( 可选 )

ConcreteHandler(President): 处理它所负责的请求，可以访问后继者，如果可以处理请求则处理，否则将该请求转给他的后继者。

Client: 向一个链上的具体处理者对象提交请求。

指责链模式有以下的优缺点：

1.       降低耦合度 职责链可以简化相互之间的连接，他们仅需要保持一个指向其后继者的引用，而不需保持它所有候选接受者的引用。使得一个对象无需知道是其它哪一个对象处理其请求，对象仅需知道该请求会被正确的处理，接收者和发送者都没有对方的明确的信息，且链中的对象不需要知道链的结构。

2.       增强了给对象指派职责的灵活性， 党在对象中分配职责时，职责链给你更多的灵活性，你可以通过在运行时可对该链进行动态的增加或者修改来增加或者改变处理请求的那些职责，你可以将这种机制与静态的特例化处理对象的继承机制结合起来使用。

3.       不保证被接收，既然一个请求没有明确的接收者，那么就不能保证他一定会被处理，该请求可能一直到链接的末端都得不到处理，一个请求也可能因为该链没有被正确配置而得不到处理。

在本例子中：有一个处理订单（ order ）的请求， President,vice president,director 分别处理不类型的消息，当客户提交消息时，他并不知道是谁能处理这个消息，这个请求便沿着职责链走下去，直到有一个职位的人能处理这个消息，处理消息的请求便完成了。

在职责链模式中需要考虑以下的实现问题

1.       实现后继者，有两种方法可以实现后继者， a ）定义新的连接， b ）使用已经存在的链接，

2.       连接后继者，适用指责链需要引用链。

3.       表示请求 可以有不同的方法表示请求，最简单的形式是直接调用职责链，另外的一种方式是使用一个处理函数，根据请求码的不同把调用不同的职责链。