一、定義
當你想讓一個以上的對象有機會能夠處理某個請求的時候，就使用責任鏈模式。
二、分析
我們在實際開發過程中，往往會遇到在執行某些操作時需要進行很多條件的驗證。
比如說在用戶在訂購一個商品時，我們就需要進行用戶認證、庫存校驗、賬戶校驗等等操作，只有經過這些處理後才能正常執行操作。
如果我們在訂購的代碼里加上這些校驗，就會變成下面的這樣：
如果我們後續，需要添加更多的校驗或者取消某些校驗，這樣會導致代碼變得越來越多， 也越來越混亂。
當出現此類的邏輯，設計模式建議我們使用責任鏈模式。把處理邏輯連成一個鏈，鏈上的每個節點都可以跳轉到下一個節點上。當需要處理的對象經過每個節點時，節點只需處理自己的邏輯，處理完成後調用下一個節點，直到走完所有的節點。
三、模式類圖
四、優缺點
- 將請求者和接收者解耦；
- 簡化類結構，類不需要知道全部細節；
- 可以更改處理的順序，動態的添加和刪除校驗邏輯；
- 並不能保證請求被處理；
- 請求鏈過長會導致性能降低；
- 不易於觀察運行時特徵，有礙於除錯，我能可能找不到是哪一個類處理了它。
五、實例
在員工請假流程中，公司規定：
請假天數3天內，部門經理審批即可，
請假天數大於3天的需要再通過老闆審批後才能請假。
根據實例說明，我們可以定義部門經理的處理類和老闆處理類，當請假天數3天內，部門經理就進行審覈；
審覈完成後流向老闆處理類，老闆處理類判斷，發現天數在3天以內就繼續往下放行，大於3天就進行審覈。