責任鏈模式，屬於行為型設計模式，為請求建立了乙個接收者物件的鏈，主要是對請求的傳送者和接收者進行解耦。
定義：責任鏈是一條由很多物件組成的鏈，鏈中的每個物件，除了最後乙個物件外，都持有對下乙個物件的引用，請求會在這個鏈上傳遞，直到鏈上的某個物件決定處理此請求為止。
問題描述：通常做法，每乙個請求的傳送者和接收者都會一一對應的耦合在一起，使得系統不夠靈活。
解決方案：讓多個接收者都有可能接收到請求，連線成一條鏈，請求沿著這條鏈傳遞，直到有物件來處理它為止，這就是責任鏈設計模式。
結構圖：
舉個栗子：講乙個評分審核的故事。。。
現在，我們公司有乙個自評規則：當自評分數小於60分時，由系統審核；60～70分，由組長審核；70～80分由主管審核；80～90分，由總監審核；90～100分，由經理審核。這條自評規則中，每個角色都是乙個處理者，我們可以將這些處理者放在一條責任鏈上，傳送乙個帶有分數引數的請求，在這條鏈上進行傳遞，直到某乙個角色決定處理為止。具體實現方式如下：
2. 分別新建具體處理者類，均繼承上面的抽象介面chainhandler。**如下：
3. 在使用者類中定義責任鏈的傳遞路徑，並傳入分數進行處理。**如下：
4. 執行後的效果，如圖所示：
以上，我們就將請求和處理進行了解耦，請求者不需要知道是誰來處理的，處理者也不需要知道是誰傳送的請求，只要符合自己的規則就進行相應的處理，並且這個責任鏈可以動態地新增或刪除，也可以改變乙個請求的處理過程，提高了系統的靈活性。
我們發現使用者中，我們要去挨個兒建立責任鏈上的每乙個物件，然後又逐個設定乙個物件對下乙個物件的引用，如果責任鏈相同的話，多個使用者就要多次編寫同樣的**，那麼我們可以使用**模式來解決這個問題，將這個物件的建立和責任鏈的形成放在**類中進行，具體實現方式如下：
5. 新建乙個**類chainproxyhandler，同樣繼承抽象介面chainhandler，並持有責任鏈上第乙個物件的引用。**如下：
6. 在使用者類中使用**類來實現同樣的功能。**如下：
7. 執行後的效果，如圖所示：
以上，我們就可以重用這個**類，只要傳入相應的引數即可，具體處理操作，由具體處理者來進行。如果需要改變責任鏈中物件的順序，可以在**類中進行修改，也可以增加新的方法。
優點：
1. 將請求者和接收者解耦，請求者不知道是被哪個接收者處理的，而接收者也不知道是誰傳送的請求；
2. 增強了系統的靈活性，可以動態地新增或刪除責任鏈，可以改變乙個請求的處理過程。
缺點：
1. 請求不一定被處理；
2. 使用不當可能會造成死迴圈；
3. 如果責任鏈比較長，可能會影響到系統效能。
適用場景：
1. 有多個物件可以處理同一請求，而具體哪個物件處理由執行時決定，而被處理的物件不需要關心誰處理。
2. 可以動態地指定一組請求處理類，並且可以動態的管理這些類。
設計模式之 責任鏈模式
在一些情況下，對乙個訊息 含事件 的響應和處理需要很多物件來參與，這些物件對訊息的處理有前後順序，形成乙個處理鏈條，但物件是否真正處理訊息有賴於在它之前的物件的處理策略，前乙個物件處理後，後乙個物件則不需參與處理，這就是責任鏈模式。現實中有很多類似的場景，比如上訪，上訪一般是從最基層的信訪部門接受信...
設計模式之（責任鏈模式）
chain of responsibleity 責任鏈模式 在責任鏈模式 中，很多物件由每乙個物件對其下家的引用而接。起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某乙個物件決定處理此請求。客戶並不知道鏈上的哪乙個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者...
設計模式之責任鏈模式
假設現在乙個公司的請假流程如下 一天及以下由小組組長審批，一天以上三天以下由經理審批，三天以上七天以下由老闆審批，七天以上直接勸退。如果每次請假時都很長的if else 來判斷該去找誰請假，很不容易擴充套件，我們使用責任鏈模式來實現。首先，是乙個抽象的父類 public abstract class...