文章目录

• 案例：企业信息处理
• 职责链模式
• 总结
• 完整代码与文档

---

案例：企业信息处理

对于一个企业来说，每天难免的要收到大量的信息，有求职者发送过来的简历、其他公司的商务合作信息、又或者是和一些企业或客户的法律纠纷信息、又或者是一些广告、推销信息。面对这大量的信息，处理起来十分的麻烦。

于是企业准备开发一套信息管理系统，初步的设计如下

我们设计了一个信息的管理员，他会判断信息的种类，并将信息转发到对应的部门中，让这些部门来处理它们对应的任务。

但是，这样的设计存在着严重的问题。

随着我们公司的规模不断扩张，各个部门的职责也更加细化，对于这些信息，我们又新增了几个新部门进行处理，同时我们可能又会对业务细化，将一个部门拆分成多个部门。甚至我们又会对信息进行分级，例如普通信息管理者，机密信息管理者等等

在这种情况下，管理者存在着大量的职责，违反了单一职责原则。同时，我们每一次增加、修改部门时，都需要去修改管理者的内部实现，这同时又违反了开放-封闭原则，这样的代码不仅维护性差，类与类之间也存在着强耦合的关系，是个不好的设计方案。

为了解决这个问题，就引入了职责链模式

---

职责链模式

职责链模式使得多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，知道有一个对象处理它为止

职责链模式由两部分组成

• 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

总结

以上是生活随笔为你收集整理的趣谈设计模式 | 职责链模式(ChainOfResposibility)：请求的转发处理的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。