职责链模式

行为型模式

• 行为型模式(Behavioral Pattern)是对在不同的对象之间划分责任和算法的抽象化。
• 行为型模式不仅仅关注类和对象的结构，而且重点关注它们之间的相互作用。
• 通过行为型模式，可以更加清晰地划分类与对象的职责，并研究系统在运行时实例对象之间的交互。在系统运行时，对象并不是孤立的，它们可以通过相互通信与协作完成某些复杂功能，一个对象在运行时也将影响到其他对象的运行。

行为型模式分为类行为型模式和对象行为型模式两种：

• 类行为型模式：类的行为型模式使用继承关系在几个类之间分配行为，类行为型模式主要通过多态等方式来分配父类与子类的职责。
• 对象行为型模式：对象的行为型模式则使用对象的聚合关联关系来分配两个或多个类的职责。根据“合成复用原则”，系统中要尽量使用关联关系来取代继承关系，因此大部分行为型设计模式都属于对象行为型设计模式。

包含模式

• 职责链模式(Chain of Responsibility) 重要程度：3
• 命令模式(Command) 重要程度：4
• 解释器模式(Interpreter) 重要程度：1
• 迭代器模式(Iterator) 重要程度：5
• 中介者模式(Mediator) 重要程度：2
• 备忘录模式(Memento) 重要程度：2
• 观察者模式(Observer) 重要程度：5
• 状态模式(State) 重要程度：3
• 策略模式(Strategy) 重要程度：4
• 模板方法模式(Template Method) 重要程度：3
• 访问者模式(Visitor) 重要程度：1

1.动机

• 如果想请几天假去丽江玩玩，就向项目经理提交了休假申请，我的项目经理向项目主管提交了我的休假申请，项目主管向部门经理提交了我的休假申请；最后，部门经理同意了我的休假申请。是的，一个简单的休假申请，需要这么复杂的流程，这也是一个公司保证它正常运行的必要。如果部门经理休假了，那么我的休假申请由谁审批呢？这个时候由项目主管代替部门经理进行审批。一个休假申请的审批制度有着严格的要求，而在处理这个请假审批时，各个人员就好比在一条链上的节点，我不知道我的请求由谁审批，但是，我的请求最终会有人来处理的。

2.定义

• 职责链模式 (Chain of Responsibility)：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，直到有一个对象处理它为止。

• 对于每个角色，他们都有他们的职责；当我提交了休假申请时，项目经理需要判断，看看自己能否处理，如果休假超过了2个小时，那么项目经理就不能处理了；项目经理将这个请求提交到项目主管，项目主管判断部门经理在不在，如果部门经理在，项目主管就不能处理了；最后，我的休假申请就到了部门经理那里了，由他亲自审批。可以很明显的看到，项目经理、项目主管和部门经理都有可能处理我的休假申请，我的请求沿着这条链一直走下去，直到有人处理了我的请求。

3.结构

• Handler：定义了一个处理请求的接口；其它类如果需要处理相同的请求，可以实现该接口就好了；
• ConcreteHandler：处理它所负责的请求，如果可处理该请求，就处理掉这个请求；否则将该请求转发给它的下一个可以处理该请求的对象，所以它必须能访问它的下一个可以处理同样请求的对象；
• Client：向处理对象提出具体的请求。

当客户提交一个请求时，请求沿着一条链传递，直至有一个ConcreteHandler对象负责处理它。

4.代码实现

#include <iostream>
using namespace std;

#define SAFE_DELETE(p) if (p) { delete p; p = nullptr; }

class HolidayRequest
{
public:
    HolidayRequest(int hour) : m_iHour(hour){}
    int GetHour() { return m_iHour; }
private:
    int m_iHour;
};

// 定义接口
class Manager
{
public:
    virtual bool HandleRequest(HolidayRequest *pRequest) = 0;
};



// 项目经理
class PM : public Manager
{
public:
    PM(Manager *handler) : m_pHandler(handler){}
    bool HandleRequest(HolidayRequest *pRequest)
    {
        if (pRequest->GetHour() <= 2 || m_pHandler == nullptr)
        {
            cout << "PM said:OK." << endl;
            return true;
        }
        return m_pHandler->HandleRequest(pRequest);
    }
private:
    Manager *m_pHandler;
};

// 部门经理
class DM : public Manager
{
public:
    DM(Manager *handler) : m_pHandler(handler){}
    bool HandleRequest(HolidayRequest *pRequest)
    {
        cout << "DM said:OK." << endl;
        return true;
    }

    // The department manager is in?
    bool IsIn()
    {
        return true;
    }
private:
    Manager *m_pHandler;
};

// 项目主管
class PS : public Manager
{
public:
    PS(Manager *handler) : m_pHandler(handler){}
    bool HandleRequest(HolidayRequest *pRequest)
    {
        //将静态类型由base类转换到derived类，因此适用dynamic_cast
        DM *pDM = dynamic_cast<DM *>(m_pHandler);
        //如果部门经理在，则转交部门经理处理
        if (pDM != nullptr)
        {
            if (pDM->IsIn())
            {
                return pDM->HandleRequest(pRequest);
            }
        }
        //部门经理不在，自己处理
        cout << "PS said:OK." << endl;
        return true;
    }
private:
    Manager *m_pHandler;
};




int main()
{
    DM *pDM = new DM(nullptr);
    PS *pPS = new PS(pDM);
    //PS *pPS = new PS(null),部门经理不在，则由项目主管处理即可
    PM *pPM = new PM(pPS);
    HolidayRequest *pHolidayRequest = new HolidayRequest(10);
    pPM->HandleRequest(pHolidayRequest);
    SAFE_DELETE(pHolidayRequest);

    pHolidayRequest = new HolidayRequest(2);
    pPM->HandleRequest(pHolidayRequest);

    //SAFE_DELETE(pDM);
    SAFE_DELETE(pPS);
    SAFE_DELETE(pPM);
    SAFE_DELETE(pHolidayRequest);

    system("pause");
    return 0;
}

5.优点

• 降低耦合度，职责链模式使得一个对象不用知道是哪一个对象处理它的请求。对象仅需要知道该请求会被正确的处理。接收者和发送者都没有对方的明确的信息，且链中的对象不需要知道链的结构。
• 增强了给对象指派职责的灵活性；当在对象中分派职责时，职责链给你更多的灵活性。你可以通过在运行时对该链进行动态的增加或修改来增加或改变处理一个请求的那些职责。

6.缺点

• 不保证被接受，既然一个请求没有明确的接收者，那么就不能保证它一定会被处理；该请求可能一直到链的末端都得不到处理。一个请求也可能因该链没有被正确配置而得不到处理。
• 系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。
• 可能不容易观察运行时的特征，有碍于除错。

7.适用场景

• 有多个的对象可以处理一个请求，由哪个对象处理该请求是在运行时刻自动确定的；
• 如果想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求；
• 可以处理一个请求的对象集合应被动态指定。

8.总结

• 职责链模式在实现时，需要处理好它的后继者的问题，就是说，如果我不处理这个请求，那么我将把这个请求发给谁去处理呢？
• 职责链模式在实现时，它的链的形状并不是由职责链本身建立和维护的，而是由客户进行创建的，由客户指定每一个处理者的后继者是谁。这就大大的提高了职责链的灵活性。在实际中，我们也可以将职责链模式与组合模式相结合，一个构件的父构件可以作为它的后继者。