避免請求發送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，并且沿著這條鏈傳遞請求，直到有對象處理它為止。

類型

行為型

簡介

在職責鏈模式里，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態地重新組織鏈和分配責任。

參與者

• Handler（抽象處理者）：它定義了一個處理請求的接口，一般設計為抽象類，由于不同的具體處理者處理請求的方式不同，因此在其中定義了抽象請求處理方法。因為每一個處理者的下家還是一個處理者，因此在抽象處理者中定義了一個抽象處理者類型的對象（如結構圖中的successor），作為其對下家的引用。通過該引用，處理者可以連成一條鏈。
• ConcreteHandler（具體處理者）：它是抽象處理者的子類，可以處理用戶請求，在具體處理者類中實現了抽象處理者中定義的抽象請求處理方法，在處理請求之前需要進行判斷，看是否有相應的處理權限，如果可以處理請求就處理它，否則將請求轉發給后繼者；在具體處理者中可以訪問鏈中下一個對象，以便請求的轉發。

用法

職責鏈模式并不創建職責鏈，職責鏈的創建工作必須由系統的其他部分來完成，一般是在使用該職責鏈的客戶端中創建職責鏈。

代碼助記

• 抽象處理者中提供set下家的方法
• 具體處理者中提供請求條件判斷，如不處理，轉發給下家

總結

在軟件開發中，如果遇到有多個對象可以處理同一請求時可以應用職責鏈模式，例如在Web應用開發中創建一個過濾器(Filter)鏈來對請求數據進行過濾，在工作流系統中實現公文的分級審批等等，使用職責鏈模式可以較好地解決此類問題。

優點

• 職責鏈模式使得一個對象無須知道是其他哪一個對象處理其請求，對象僅需知道該請求會被處理即可，接收者和發送者都沒有對方的明確信息，且鏈中的對象不需要知道鏈的結構，由客戶端負責鏈的創建，降低了系統的耦合度。
• 請求處理對象僅需維持一個指向其后繼者的引用，而不需要維持它對所有的候選處理者的引用，可簡化對象的相互連接。
• 在給對象分派職責時，職責鏈可以給我們更多的靈活性，可以通過在運行時對該鏈進行動態的增加或修改來增加或改變處理一個請求的職責。
• 在系統中增加一個新的具體請求處理者時無須修改原有系統的代碼，只需要在客戶端重新建鏈即可，從這一點來看是符合“開閉原則”的。

缺點

• 由于一個請求沒有明確的接收者，那么就不能保證它一定會被處理，該請求可能一直到鏈的末端都得不到處理；一個請求也可能因職責鏈沒有被正確配置而得不到處理。
• 對于比較長的職責鏈，請求的處理可能涉及到多個處理對象，系統性能將受到一定影響，而且在進行代碼調試時不太方便。
• 如果建鏈不當，可能會造成循環調用，將導致系統陷入死循環。