設計模式-行爲型-責任鏈模式（CHAIN OF RESPONSIBILITY）

接下來咱們繼續探尋行爲型模式。對於這類模式，筆者的理解是。它更多關注在如何抽象出一個或多個實體來把本來可能很複雜的控制流轉移成多個職責分明的實體之間的交流上來。這樣寫出來的代碼更容易被理解，同時也更容易被維護。在結構上，這類設計模式多采用組合的方式來實現，固然也有經過類繼承的方式來實現，好比模板方法（TEMPLATE METHOD）。

接下來咱們來討論責任鏈模式。責任鏈模式的結構圖以下所示

 

gof對於責任鏈模式是這樣定義，「使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關係。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它爲止。」

從它的定義來看，責任鏈的最終目的是構建出這樣一個責任鏈。請求做爲一個對象，附帶了這個請求處理相關的信息，組成責任鏈的節點會解讀這個請求，決定是處理該請求或是把請求發給下一個節點。筆者認爲這個責任鏈的節點能夠是連續存儲的也能夠是隨機位置存儲的，具體怎麼作取決於你的實現。

那麼責任鏈的優勢在哪兒了呢？ 第一點，它下降了客戶與處理者的耦合度，客戶只須要知道第一個處理者與它的請求會被「恰當」的處理掉，怎麼處理被誰處理它不用關心。第二點，在開始處理以前，你能夠針對你當時的需求配置責任鏈。這種靈活性是體如今責任鏈的結構上的，本質上說你拿到的責任鏈就是一個線性表，因此配置責任鏈本質上就是配置一個線性表。

同時注意到責任鏈模式並無保證客戶的請求必定會被處理，設計者在設計這條責任鏈的時候就必須瞭解這個特性，並提供給客戶一個他的請求會被「恰當」處理的保證。這個「恰當」處理多是被正確的處理掉（好比處理結果多是觸發了一個事件，寫了一段內存，寫了一句數據等等）也多是返回一個錯誤消息（往標準錯誤輸出錯誤信息等等）。注意到返回一個錯誤消息確定是這個責任鏈中的最後一個處理節點，正如前面討論到的那樣，責任鏈本質是一個單鏈表。