不知不覺中來到了設計模式這部分，設計模式之前一直想學的，那時候都沒什麼驅動力，現在有了，一邊學習一邊寫筆記，這種學習方法也是比較好的，畢竟有輸出，寫的過程中考慮都了好些東西，要不然寫不清楚，不說了，進入主題，這次用的語言是c++。
我看著別人說設計模式的時候，都會有引入的，不過也確實是，直接上來就說責任鏈模式，感覺有點奇怪，還是要先引入，通過生活的例子，再到抽象，然後到**的實現，也才是我們程式設計師的必修課。
12.1.1 生活中的例子
我們要去銀行貸款，小於1萬的銀行職員都可以審批，大於1萬的銀行職員就批不了了，需要上報經理，經理收到這個請求就來辦理，但是經理的許可權也是有限的，只能批到十萬，再往上的批不了，需要向更高階的領導請示
像這種方式的，就是比較符合責任鏈模式，總要找到乙個有許可權的人來處理我這件事情。
12.1.2 原來的實現
如果按照我們以前慣有的思想，就是會在類的方法中，搞很多個if else if來判斷哪乙個人是有許可權處理的。這樣導致寫的處理這個方法中，寫了很多死**，以後要新增其他的領導的話，就要直接修改這個方法的**，確實不理想。所有需要抽象一種設計模式來解決這個問題。這個過渡的地方可以參考《大話設計模式》。
不知道引入寫的怎麼樣，我感覺還是不好，不是專業的，並且也懶的寫那種沒有設計模式的**，如果要好好看這種鋪墊可以去看看《大話設計模式》，引入寫的就比較好，看了會有種謊言大悟的感覺。
責任鏈模式：
使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這個物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。
翻譯一下：就是說需要把傳送者的請求，傳送出去，這個請求是在一條鏈上傳輸的，這個鏈上分別有不同的物件去接收，物件接收之後會判斷自己的許可權，如果不夠，就繼續在鏈上傳輸給下乙個物件，直到有物件處理這個請求。
12.2.2 結構圖
剛學了uml圖的結構，現在可以小示一波
第一次畫，不過感覺畫uml圖確實結構比較明確，request類是訊息類，負責傳送訊息，handler類是處理訊息的父類，其他的職員，經理行長都繼承了這個handler類，類中的handle方法就是處理訊息的。setnext這個方法是設定鏈條的。
12.3.1 request類
request是傳送訊息的類，就是這個訊息在鏈條上傳遞，這個類只要有貸款的金額loan，其他的個人的資訊，比如名字，年齡等，不過我們關注的還是loan。
class
resqest
intget_loan()
intget_type_loan()
private
:unsigned
int type_loan =
10000
;//單位為1萬
unsigned
int _loan;
unsigned
short _age;
std::string _name;
};
_age(age) _age是類中的變數，age是外部傳進來的。
12.3.2 handler類
handler是第乙個處理的類，這個類的內容多了一點，只要是這個類作為基類，其他的總監，市行長都是繼承這個類。
class
handler
void
handle
(resqest* resq)
else
if(next_handler !=
nullptr
)else
}void
show()
intset_max_loan
(unsigned
int max_loan)
protected
: handler *next_handler;
private
:unsigned
int max_loan =1;
unsigned
int type_loan =
10000
;//單位是1萬
void
set_next
(handler *handler)
};
set_max_loan()：這個函式是設定每乙個類中的最大貸款值，在判斷的時候是用的到的。
handle()：這個函式就是真正處理的函式，判斷request類傳遞過來的訊息中的貸款金額是否符合當前類的許可權，如果不滿足並且下乙個handler不為空，就執行next_handler->handle(resq);下乙個handler的handle函式，直到handler為空的時候，說明鏈條已經結束，這時候都不滿足，退出。
12.3.3 employee類
這個是職員的類，是比handler許可權高一級的類，要繼承handler類，因為handler類好多方法都已經實現了，繼承過來直接使用即可。跟handler類不同的地方，就是設定貸款金額。這裡用了乙個設定金額的函式設定了不同許可權的金額。
class
employee
:public handler
protected
:unsigned
int max_loan =10;
};
12.3.4 main函式
重點是我們的main函式，怎麼把鏈條構建出來的，main函式就可以直接體現出來了，就是上面說的用set_next()，的方法。
/**
* @brief main函式
* @param
* @retval
*/intmain
(void
)
責任鏈的特點：
責任鏈可簡化物件的相互連線，它們僅需要儲存乙個指向後繼的引用，而不需要儲存所有的候選這的引用。這樣大大的降低了耦合度。
隨時地增加或修改處理乙個請求的結構。增加了給物件指派職責的靈活性。
乙個請求極有可能到了末端都得不到處理，或者因為配置不當而得不到處理，這就需要考慮全面。
參考《大話設計模式》
這一篇內容比較少，也不難，所以寫的有點少。
設計模式（十二）責任鏈模式
今天來看看什麼是責任鏈模式。責任鏈，從字面意思可以看出，不同的責任連起來，成為一條責任鏈，針對不同的情況，在這條鏈上尋找對應的處理辦法。官方定義 使多個物件都有機會處理請求，從而避免了請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有物件處理它為止。責任鏈模式的...
設計模式之十二 責任鏈模式
定義 使多個物件都有機會處理請求，從而避免請求的傳送者和接受者之間的耦合關係，將這個物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理他為止 業務場景 多個不同物件可以處理同乙個請求，具體由哪乙個物件處理，由業務規則動態確定。例如常見的流程審批 框架中的請示過濾等等。動物園來了 喂動物，對食...
設計模式 責任鏈模式（學習筆記）
責任鏈模式原理 示例專案 購買請求決策專案 購買請求決策專案介紹 決策因素 決策級別 組長 部長 副總 總裁 傳統類圖結構 責任鏈模式類圖 責任鏈模式 如果有多個物件都有機會處理請求，責任鏈可使請求的傳送者和接收者解耦，請求沿著責任鏈傳遞，直到有乙個物件處理了它為止。優點 將請求的傳送者和接收者解耦...