使多個物件都有機會處理請求，從而避免了請求的傳送者和接受者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有物件處理它為止。
責任鏈模式的重點是在」鏈」上，由一條鏈去處理相似的請求在鏈中決定誰來處理這個請求。
責任鏈模式非常顯著的優點是將請求和處理分開。請求者可以不用知道是誰處理的，處理者可以不用知道請求全貌(例如在j2ee專案開發中，可以剝離出無狀態bean由責任鏈處理)，兩者解耦，提高系統的靈活性。
責任鏈有兩個非常顯著的缺點:
一是效能問題，每個請求都是從鏈頭遍歷到鏈尾，特別是在鏈比較長的時候，效能是乙個非常大的問題。
二是除錯不很方便，特別是鏈條比較長，環節比較多的時候，由於採用了類似遞迴的方式，除錯的時候邏輯可能比較複雜。
鏈中節點數量需要控制，避免出現超長鏈的情況，一般的做法是在handler中設定乙個最大節點數量，在setnext方法中判斷是否已經是超過其閥值，超過則不允許該鏈建立，避免無意識破壞系統效能。
責任鏈模式遮蔽了請求的處理過程，你發起乙個請求到底是誰處理的，這個你不用關心，只要你把請求拋給責任鏈的第乙個處理者，最終會返回乙個處理結果(當然也可以不做任何處理)，作為請求者可以不用知道到底是需要誰來處理的，這是責任鏈模式的核心，同時責任鏈模式也可以作為一種補救模式來用。
舉個簡單例子:
如專案開發的時候，需求確認是這樣的:乙個請求，乙個處理者，但是隨著業務的發展，處理者的數量和型別有所增加，你這時候就可以在第乙個處理者後面建立乙個鏈，也就是責任鏈來處理請求，如果是人民幣，好，還是第乙個業務邏輯來處理;如果是美元，好，傳遞到第二個業務邏輯來處理;日元、歐元…這些都不用在對原有的業務邏輯產生很大改變，通過擴充套件實現類就可以很好地解決這些需求變更時間。
**例子:
設計模式之 責任鏈模式
在一些情況下，對乙個訊息 含事件 的響應和處理需要很多物件來參與，這些物件對訊息的處理有前後順序，形成乙個處理鏈條，但物件是否真正處理訊息有賴於在它之前的物件的處理策略，前乙個物件處理後，後乙個物件則不需參與處理，這就是責任鏈模式。現實中有很多類似的場景，比如上訪，上訪一般是從最基層的信訪部門接受信...
設計模式之（責任鏈模式）
chain of responsibleity 責任鏈模式 在責任鏈模式 中，很多物件由每乙個物件對其下家的引用而接。起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某乙個物件決定處理此請求。客戶並不知道鏈上的哪乙個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者...
設計模式之責任鏈模式
假設現在乙個公司的請假流程如下 一天及以下由小組組長審批，一天以上三天以下由經理審批，三天以上七天以下由老闆審批，七天以上直接勸退。如果每次請假時都很長的if else 來判斷該去找誰請假，很不容易擴充套件，我們使用責任鏈模式來實現。首先，是乙個抽象的父類 public abstract class...