文章目錄

• 案例：企業(yè)信息處理
• 職責鏈模式
• 總結(jié)
• 完整代碼與文檔

---

案例：企業(yè)信息處理

對于一個企業(yè)來說，每天難免的要收到大量的信息，有求職者發(fā)送過來的簡歷、其他公司的商務(wù)合作信息、又或者是和一些企業(yè)或客戶的法律糾紛信息、又或者是一些廣告、推銷信息。面對這大量的信息，處理起來十分的麻煩。

于是企業(yè)準備開發(fā)一套信息管理系統(tǒng)，初步的設(shè)計如下

我們設(shè)計了一個信息的管理員，他會判斷信息的種類，并將信息轉(zhuǎn)發(fā)到對應(yīng)的部門中，讓這些部門來處理它們對應(yīng)的任務(wù)。

但是，這樣的設(shè)計存在著嚴重的問題。

隨著我們公司的規(guī)模不斷擴張，各個部門的職責也更加細化，對于這些信息，我們又新增了幾個新部門進行處理，同時我們可能又會對業(yè)務(wù)細化，將一個部門拆分成多個部門。甚至我們又會對信息進行分級，例如普通信息管理者，機密信息管理者等等

在這種情況下，管理者存在著大量的職責，違反了單一職責原則。同時，我們每一次增加、修改部門時，都需要去修改管理者的內(nèi)部實現(xiàn)，這同時又違反了開放-封閉原則，這樣的代碼不僅維護性差，類與類之間也存在著強耦合的關(guān)系，是個不好的設(shè)計方案。

為了解決這個問題，就引入了職責鏈模式

---

職責鏈模式

職責鏈模式使得多個對象都有機會處理請求，從而避免請求的發(fā)送者和接收者之間的耦合關(guān)系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，知道有一個對象處理它為止

職責鏈模式由兩部分組成

• Handler(處理者接口)：提供了處理請求的接口，所有的具體處理者都會實現(xiàn)它
• ConcreteHandle(具體處理者)：具體處理者，處理它所負責的請求，可訪問它的后繼者，如果可以處理則處理，處理不了則將任務(wù)轉(zhuǎn)發(fā)給它的后繼者

類圖如下

根據(jù)職責鏈模式，此時我們的關(guān)系是這樣的，我們讓部門之間以鏈表的形式連接起來。

當客戶向我們發(fā)送信息后，每個部門都會處理自己分內(nèi)的信息，如果處理不了，則將其轉(zhuǎn)發(fā)給職責鏈中的下一個部門，讓其繼續(xù)處理。

例如客戶發(fā)送來一個XXX的求職簡歷，此時的處理流程是這樣的

下面就以代碼的形式實現(xiàn)一下這個功能

首先實現(xiàn)一個請求的結(jié)構(gòu)，以及處理者的抽象類，其中為了實現(xiàn)鏈式結(jié)構(gòu)，處理者中保留了一個指向職責鏈下一個處理者的指針

//請求結(jié)構(gòu)體，包含請求類型和正文 struct Request {std::string _type;std::string _text; };//處理者抽象類，所有的具體處理者都會繼承并實現(xiàn)該類 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; //繼任者 };

接著實現(xiàn)具體的處理者

#include"Handler.hpp" #include<iostream>//法務(wù)部門 class LegalHandler : public Handler { public:void HandlerRequest(const Request& req) override{if(req._type == "法務(wù)信息"){std::cout << "法務(wù)部門處理法務(wù)信息: " << req._text << std::endl;}else{if(_sussessor != nullptr){_sussessor->HandlerRequest(req);} }} };//商務(wù)部門 class BusinessHandler : public Handler { public:void HandlerRequest(const Request& req) override{if(req._type == "商務(wù)信息"){std::cout << "商務(wù)部門處理商務(wù)信息: " << 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);} }} };//雜務(wù)部門，也相當于是收尾人，負責處理剩余的請求 class MiscellaneousHandler : public Handler { public:void HandlerRequest(const Request& req) override{std::cout << "雜務(wù)部門處理剩余信息: " << 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({"法務(wù)信息", "XXX法院傳票"});legal->HandlerRequest({"商務(wù)信息", "XXX商業(yè)合作"});legal->HandlerRequest({"人事信息", "XXX投遞簡歷"});legal->HandlerRequest({"雜務(wù)信息", "XXX無關(guān)信息"});delete legal, business, personnel, miscellaneous; }

在當前的設(shè)計中，客戶只需要將所有的信息發(fā)送給職責鏈的首部即可，如果他能夠處理則直接完成請求，如果無法完成就會將請求轉(zhuǎn)發(fā)給職責鏈的下一個處理者繼續(xù)執(zhí)行

---

總結(jié)

要點

• 職責鏈模式將請求的發(fā)送者和接收者解耦
• 可以簡化對象的相互連接，因為它不需要知道鏈的結(jié)構(gòu)
• 通過改變鏈內(nèi)的成員或者調(diào)動他們的次序，允許我們動態(tài)地增加或者修改處理一個請求的結(jié)構(gòu)，增強了給對象指派職責的靈活性
• 并不保證請求一定會被執(zhí)行，如果沒有任何對象處理它，可能回落到鏈尾端之外，因此最好需要設(shè)立一個收尾者，來解決所有未被處理的請求
• 由于處理是鏈式傳遞的，因此不容易觀察運行時的特征，有礙于除錯

應(yīng)用場景

• 有多個對象可以處理同一個請求，具體哪個對象處理該請求由運行時刻自動確定
• 在不明確指定接收者的情況下，向多個對象中的一個提交一個請求
• 可動態(tài)指定一組對象處理請求
• 通常用于實現(xiàn)攔截器、過濾器、窗口事件處理等

---

完整代碼與文檔

如果有需要完整代碼或者markdown文檔的同學(xué)可以點擊下面的github鏈接
github

總結(jié)

以上是生活随笔為你收集整理的趣谈设计模式 | 职责链模式(ChainOfResposibility)：请求的转发处理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。