案例：企业信息处理
对于一个企业来说，每天难免的要收到大量的信息，有求职者发送过来的简历、其他公司的商务合作信息、又或者是和一些企业或客户的法律纠纷信息、又或者是一些广告、推销信息。面对这大量的信息，处理起来十分的麻烦。
于是企业准备开发一套信息管理系统，初步的设计如下
我们设计了一个信息的管理员，他会判断信息的种类，并将信息转发到对应的部门中，让这些部门来处理它们对应的任务。
但是，这样的设计存在着严重的问题。
随着我们公司的规模不断扩张，各个部门的职责也更加细化，对于这些信息，我们又新增了几个新部门进行处理，同时我们可能又会对业务细化，将一个部门拆分成多个部门。甚至我们又会对信息进行分级，例如普通信息管理者，机密信息管理者等等
在这种情况下，管理者存在着大量的职责，违反了单一职责原则。同时，我们每一次增加、修改部门时，都需要去修改管理者的内部实现，这同时又违反了开放-封闭原则，这样的代码不仅维护性差，类与类之间也存在着强耦合的关系，是个不好的设计方案。
为了解决这个问题，就引入了职责链模式
职责链模式
职责链模式使得多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，知道有一个对象处理它为止
职责链模式由两部分组成
- Handler(处理者接口)：提供了处理请求的接口，所有的具体处理者都会实现它
- ConcreteHandle(具体处理者)：具体处理者，处理它所负责的请求，可访问它的后继者，如果可以处理则处理，处理不了则将任务转发给它的后继者
类图如下
根据职责链模式，此时我们的关系是这样的，我们让部门之间以链表的形式连接起来。
当客户向我们发送信息后，每个部门都会处理自己分内的信息，如果处理不了，则将其转发给职责链中的下一个部门，让其继续处理。
例如客户发送来一个XXX的求职简历，此时的处理流程是这样的
下面就以代码的形式实现一下这个功能
首先实现一个请求的结构，以及处理者的抽象类，其中为了实现链式结构，处理者中保留了一个指向职责链下一个处理者的指针
//请求结构体，包含请求类型和正文
struct Request
{
std::string _type;
std::string _text;
};
//处理者抽象类，所有的具体处理者都会继承并实现该类
class Handler
{
public:
Handler()
: _sussessor(nullptr)
{
}
virtual ~Handler() = default;
void setSussessor(Handler* sussessor)
{
_sussessor = sussessor;
}
virtual void HandlerRequest(const Request& req) = 0;
protected:
Handler* _sussessor; //继任者
};
接着实现具体的处理者
#include"Handler.hpp"
#include<iostream>
//法务部门
class LegalHandler : public Handler
{
public:
void HandlerRequest(const Request& req) override
{
if(req._type == "法务信息")
{
std::cout << "法务部门处理法务信息: " << req._text << std::endl;
}
else
{
if(_sussessor != nullptr)
{
_sussessor->HandlerRequest(req);
}
}
}
};
//商务部门
class BusinessHandler : public Handler
{
public:
void HandlerRequest(const Request& req) override
{
if(req._type == "商务信息")
{
std::cout << "商务部门处理商务信息: " << req._text << std::endl;
}
else
{
if(_sussessor != nullptr)
{
_sussessor->HandlerRequest(req);
}
}
}
};
//人事部门
class PersonnelHandler : public Handler
{
public:
void HandlerRequest(const Request& req) override
{
if(req._type == "人事信息")
{
std::cout << "人事部门处理人事信息: " << req._text << std::endl;
}
else
{
if(_sussessor != nullptr)
{
_sussessor->HandlerRequest(req);
}
}
}
};
//杂务部门，也相当于是收尾人，负责处理剩余的请求
class MiscellaneousHandler : public Handler
{
public:
void HandlerRequest(const Request& req) override
{
std::cout << "杂务部门处理剩余信息: " << req._text << std::endl;
}
};
测试代码
int main()
{
Handler* legal = new LegalHandler;
Handler* business = new BusinessHandler;
Handler* personnel = new PersonnelHandler;
Handler* miscellaneous = new MiscellaneousHandler;
legal->setSussessor(business);
business->setSussessor(personnel);
personnel->setSussessor(miscellaneous);
legal->HandlerRequest({
"法务信息", "XXX法院传票"});
legal->HandlerRequest({
"商务信息", "XXX商业合作"});
legal->HandlerRequest({
"人事信息", "XXX投递简历"});
legal->HandlerRequest({
"杂务信息", "XXX无关信息"});
delete legal, business, personnel, miscellaneous;
}
在当前的设计中，客户只需要将所有的信息发送给职责链的首部即可，如果他能够处理则直接完成请求，如果无法完成就会将请求转发给职责链的下一个处理者继续执行
总结
要点
- 职责链模式将请求的发送者和接收者解耦
- 可以简化对象的相互连接，因为它不需要知道链的结构
- 通过改变链内的成员或者调动他们的次序，允许我们动态地增加或者修改处理一个请求的结构，增强了给对象指派职责的灵活性
- 并不保证请求一定会被执行，如果没有任何对象处理它，可能回落到链尾端之外，因此最好需要设立一个收尾者，来解决所有未被处理的请求
- 由于处理是链式传递的，因此不容易观察运行时的特征，有碍于除错
应用场景
- 有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定
- 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求
- 可动态指定一组对象处理请求
- 通常用于实现拦截器、过滤器、窗口事件处理等
完整代码与文档
如果有需要完整代码或者markdown文档的同学可以点击下面的github链接
github