前言
最近心情很差，因为生活，因为工作；所以想请几天假去丽江玩玩。就向项目经理提交了休假申请，我的项目经理向项目主管提交了我的休假申请，项目主管向部门经理提交了我的休假申请；最后，部门经理同意了我的休假申请。是的，一个简单的休假申请，需要这么复杂的流程，这也是一个公司保证它正常运行的必要。如果部门经理休假了，那么我的休假申请由谁审批呢？这个时候由项目主管代替部门经理进行审批。一个休假申请的审批制度有着严格的要求。而在处理这个请假审批时，各个人员就好比在一条链上的节点，我不知道我的请求由谁审批，但是，我的请求最终会有人来处理的。而这样的一种行为，就好比我今天需要总结的职责链模式一样。
什么是职责链模式？
在gof的《设计模式:可复用面向对象软件的基础》一书中对职责链模式是这样说的：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，直到有一个对象处理它为止；如下图：
对于每个角色，他们都有他们的职责；当我提交了休假申请时，项目经理需要判断，看看自己能否处理，如果休假超过了2个小时，那么项目经理就不能处理了；项目经理将这个请求提交到项目主管，项目主管判断部门经理在不在，如果部门经理在，项目主管就不能处理了；最后，我的休假申请就到了部门经理那里了，由他亲自审批。可以很明显的看到，项目经理、项目主管和部门经理都有可能处理我的休假申请，我的请求沿着这条链一直走下去，直到有人处理了我的请求。
uml类图
handler：定义了一个处理请求的接口；其它类如果需要处理相同的请求，可以实现该接口就好了；
concretehandler：处理它所负责的请求，如果可处理该请求，就处理掉这个请求；否则将该请求转发给它的下一个可以处理该请求的对象，所以它必须能访问它的下一个可以处理同样请求的对象；
client：向处理对象提出具体的请求。
当客户提交一个请求时，请求沿着一条链传递，直至有一个concretehandler对象负责处理它。
使用场合
- 有多个的对象可以处理一个请求，由哪个对象处理该请求是在运行时刻自动确定的；
- 如果想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求；
- 可以处理一个请求的对象集合应被动态指定。
代码实现
#include
using namespace std;
#define safe_delete(p) if (p) {
delete p; p = null; }
class holidayrequest
{
public:
holidayrequest(int hour) : m_ihour(hour){}
int gethour() {
return m_ihour; }
private:
int m_ihour;
};
// the holiday request handler interface
class manager
{
public:
virtual bool handlerequest(holidayrequest *prequest) = 0;
};
// project manager
class pm : public manager
{
public:
pm(manager *handler) : m_phandler(handler){}
bool handlerequest(holidayrequest *prequest)
{
if (prequest->gethour() <= 2 || m_phandler == null)
{
cout<<"pm said:ok."<handlerequest(prequest);
}
private:
manager *m_phandler;
};
// department manager
class dm : public manager
{
public:
dm(manager *handler) : m_phandler(handler){}
bool handlerequest(holidayrequest *prequest)
{
cout<<"dm said:ok."<(m_phandler);
if (pdm != null)
{
if (pdm->isin())
{
return pdm->handlerequest(prequest);
}
}
cout<<"ps said:ok."<handlerequest(pholidayrequest);
safe_delete(pholidayrequest);
pholidayrequest = new holidayrequest(2);
ppm->handlerequest(pholidayrequest);
safe_delete(pdm);
safe_delete(pps);
safe_delete(ppm);
safe_delete(pholidayrequest);
} 优缺点
- 降低耦合度；职责链模式使得一个对象不用知道是哪一个对象处理它的请求。对象仅需要知道该请求会被正确的处理。接收者和发送者都没有对方的明确的信息，且链中的对象不需要知道链的结构；
- 增强了给对象指派职责的灵活性；当在对象中分派职责时，职责链给你更多的灵活性。你可以通过在运行时对该链进行动态的增加或修改来增加或改变处理一个请求的那些职责；
- 不保证被接受，既然一个请求没有明确的接收者，那么就不能保证它一定会被处理；该请求可能一直到链的末端都得不到处理。一个请求也可能因该链没有被正确配置而得不到处理。
总结
职责链模式在实现时，需要处理好它的后继者的问题，就是说，如果我不处理这个请求，那么我将把这个请求发给谁去处理呢？同时，职责链模式在实现时，它的链的形状并不是由职责链本身建立和维护的，而是由客户进行创建的，由客户指定每一个处理者的后继者是谁。这就大大的提高了职责链的灵活性。在实际中，我们也可以将职责链模式与组合模式相结合，一个构件的父构件可以作为它的后继者。