相信大家都玩過類似於「鬥地主」的紙牌遊戲，某人出牌給他的下家，下家看看手中的牌，如果要不起，則將出牌請求**給他的下家，其下家再進行判斷。乙個迴圈下來，如果其他人都要不起該牌，則最初的出牌者可以打出新牌。在這個過程中，紙牌作為乙個請求沿著一條鏈在傳遞，每一位紙牌的玩家都可以處理該請求。在設計模式中，也有一種專門用於處理這種請求鏈式的模式，它就是職責鏈模式。
職責鏈（chain of responsibility）模式：避免將請求傳送者與接受者耦合在一起，讓多個物件都有機會接受請求，將這些物件連成一條鏈，並且沿著這條鏈傳遞請求，直到有物件處理它為止。職責鏈模式是一種物件行為型模式。
需求背景：m公司承接了某企業scm（supply chain management,**鏈管理）系統的開發任務，其中包含乙個採購審批子系統。該企業的採購審批是分級進行的，即根據採購金額的不同由不同層次的主管人員來審批：主任可以審批5萬元以下（不包括5萬）的採購單，副董事長可以審批5萬~10萬（不包括10萬）的採購單，50萬元以及以上的採購單就需要開董事會討論決定，如下圖所示：抽象執行者類
class
virtual
void processrequest(crequestx *) = 0
;protected
:
string
m_strname;
};
//主管類class cdirector : public
~cdirector(){}
void processrequest(crequestx *prequest)
else
}
};
//副總裁類
class cvicepresident : public
~cvicepresident(){}
void processrequest(crequestx *prequest)
else
}
};
//總裁類class cpresident : public
~cpresident(){}
void processrequest(crequestx *prequest)
else
}
};
//董事會類
class ccongress : public
~ccongress(){}
void processrequest(crequestx *prequest)
};
#include "（1）使得乙個物件無需知道是其他哪乙個物件處理其請求，物件僅需知道該請求會被處理即可，且鏈式結構由客戶端建立 =>降低了系統的耦合度（2）在系統中增加乙個新的具體處理者無須修改原有系統源**，只需要在客戶端重新建立鏈式結構即可 =>符合開閉原則stdio.h
"#include
"responsibility.h
"void
main()
（1）由於乙個請求沒有乙個明確地接受者 => 無法保證它一定會被處理
（2）對於較長的職責鏈 => 系統效能有一定影響且不利於除錯
（3）如果建立鏈不當，可能會造成迴圈呼叫 => 導致系統進入死迴圈
（1）有多個物件處理同乙個請求且無需關心請求的處理物件時誰以及它是如何處理的 => 比如各種審批流程
（2）可以動態地指定一組物件處理請求，客戶端可以動態建立職責鏈來處理請求，還可以改變鏈中處理者之間的先後次序 => 比如各種流程定製
設計模式之職責鏈模式
如果我們現在有乙個需求,乙個人他生了病,這個病要在 醫院才能看,但是這個病人並不清楚,就先去了一級醫院,一級醫院的醫生告訴他你的病要去二級醫院看,二級醫院也告訴他 你的病我這裡看不了,你要去 醫院才能看,最後他去 醫院把病看好了.這個過程直接寫成 class patient this.patient...
設計模式之職責鏈模式
職責鏈模式 使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。適用場景 1 有多個的物件可以處理乙個請求，哪個物件處理該請求執行時刻自動確定 2 在不明確指定接收者的情況下，向多個物件中的乙個提交乙個請求 ...
設計模式之職責鏈模式
職責鏈模式 chain of responsibility 使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將多個物件連成一條鏈，沿著這條鏈傳遞請求直到有物件處理它為止。可以定義乙個抽象類來表示處理事件的物件，這個類首先有個處理事件的抽象方法，然後提供乙個方法設定下一級處理者...