我们在餐馆吃饭的时候，一般都是在拿到菜单后，选择喜欢的菜，然后通知服务员。服务员会将我们的定单交给大厨，大厨可能会亲自去做这道菜，也可能安排给小厨来做，总之，我们不用担心他们没有人做菜，即使有时候等的时间长点。
下面我们来分析一下。首先，对于我们这些点菜的人来说，我们一般不了解这些厨师，我们没法找到某个具体的厨师让他去做，所以只好把请求交给服务员；然后，对于餐馆的服务员、大厨、小厨来说，他们都可以接受并处理这个请求，但很明显，他们有分工，不会一人去做所有的菜。
简单地说，顾客发送请求（点菜），餐馆的人接受请求（拿到定单），有多个人可以处理该请求（做菜），或者说履行职责，但最后只有一人处理该请求。如下图所示：
这当中就包含了职责链模式（Chain Of Responsibility，简称CoR）。
我们来看看Gof中CoR的描述：
意图
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。
从第一个对象开始，链中收到请求的对象要么亲自处理它，要么转发给链中的下一个候选者，请求发送者不确定到底哪个对象会处理它，——我们称该请求有一个隐式的接受者（implicit receiver）。
在餐馆的例子中，顾客是请求的发送者，接受者则是服务员、大厨、小厨，他们构成了一条职责链，他们当中会一个人来处理请求。
好了，菜终于上来了，先把它吃掉吧...
现在走出餐馆，我们来看看在一般场景下，CoR的类图是：
参与者
Handler（如Employee）
——定义一个处理请求的接口；
ConcreteHandler（如Server和Chef）
——处理它负责的请求；
——可访问它的后继者（Successor）；
——如果可处理该请求，处理之；否则转发给后继者；
Client
——向职责链提交请求。
适用性
1、有多个的对象可以处理一个请求，而具体的处理者在运行时自动确定；
2、希望在对接受者不了解的情况下，向多个对象的一个提交请求；
3、处理请求的对象集合需要动态指定。
示例代码：
using System;
namespace ChainOfPatterns
{
class Program
{
static void Main(string[] args)
{
// 餐馆工作人员
Server server = new Server("anders");
Chef chef = new Chef("dudu");
AssistantChef ac = new AssistantChef("bill");
server.SetSuccessor(chef);
chef.SetSuccessor(ac);
Customer customer = new Customer();
// 点第一道菜
customer.OrderName = "酸辣土豆丝";
server.HandleRequest(customer);
// 点第二道菜
customer.OrderName = "农家小炒肉";
server.HandleRequest(customer);
Console.ReadLine();
}
}
public class Customer
{
private string orderName;
public string OrderName
{
get { return orderName; }
set { orderName = value; }
}
}
public abstract class Employee
{
protected string name;
protected Employee successor;
public Employee(string name)
{
this.name = name;
}
public void SetSuccessor(Employee successor)
{
this.successor = successor;
}
public virtual void HandleRequest(Customer customer)
{
if (successor != null)
{
successor.HandleRequest(customer);
}
}
}
/// <summary>
/// 服务员不用炒菜，所以直接转发给后继者。
/// </summary>
public class Server : Employee
{
public Server(string name) : base(name)
{
}
}
public class Chef : Employee
{
public Chef(string name) : base(name)
{
}
public override void HandleRequest(Customer customer)
{
if (customer.OrderName == "农家小炒肉")
{
Console.WriteLine("{0}做的{1}", name, customer.OrderName);
}
else
{
base.HandleRequest(customer);
}
}
}
public class AssistantChef : Employee
{
public AssistantChef(string name) : base(name)
{
}
public override void HandleRequest(Customer customer)
{
if (customer.OrderName == "酸辣土豆丝")
{
Console.WriteLine("{0}做的{1}", name, customer.OrderName);
}
else
{
base.HandleRequest(customer);
}
}
}
}
注意：
如果我们运气很差，点了一个没有存货的菜，那么不管是服务员还是大厨、小厨都没法处理了。也就是说，对于一个请求，可能没有任何接受者会处理它。
问题：
我还想到一个问题，如果一道菜很复杂，需要大厨和小厨一起做，该怎么办呢？望各路高手指点迷津 :)
其它的例子：
浏览器事件模型
假设我们的HTML页面上有一个<div />，它又包含了一个<input />按钮，对于按钮的click事件来说，在IE中它的触发顺序为从最特定的事件目标（button）道最不特定的事件目标（document对象）。input，div，body到document，它们也构成了一条职责链。
击鼓传花
击鼓传花是一种热闹而又紧张的饮酒游戏。在酒宴上宾客依次坐定位置，由一人击鼓，击鼓的地方与传花的地方是分开的，以示公正。开始击鼓时，花束就开始依次传递，鼓声一落，如果花束在某人手中，则该人就得饮酒。
看起来，酒宴上的宾客构成了一条链。但我认为这是CoR的一个反面例子。对于每一轮具体的游戏来说，这些宾客唯一能做的事情就是将花束传递（转发给后继者），没有谁能够主动停下来，而能够处理请求的人（击鼓者）到底是谁的后继者呢？这个并不确定，职责链如何构建呢？
另外，建议看一看下面两篇文章中高手的论述：职责链模式在开发中的应用，手拉手就是职责链吗？
参考：
《设计模式－可复用面向对象软件的基础》 Gof
《UML基础、案例与应用》Joseph Schmuller