職責鏈模式（Chain of Responsibility）

設計模式使用的例子https://github.com/LinkinStars/DesignPatternsAllExample

一、定義

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

二、結構

Handler（抽象處理者）：定義了一個處理請求的接口，一般設計為抽象類，由於不同的具體處理者處理請求的方式不同，因此在其中定義了抽象請求處理方法。

ConcreteHandler（具體處理者）：它是抽象處理者的子類，可以處理用戶請求，它實現了在抽象處理者中定義的抽象請求處理方法。

在處理請求之前需要判斷是否有相應的處理權限，如果可以則處理，否則則將請求轉發給後繼者。

三、優點

使得一個對象無需知道是其他哪一個對象處理其請求，對象僅需知道該請求會被處理即可，且鏈式結構由客戶端創建

在系統中增加一個新的具體處理者無須修改原有系統源代碼，只需要在客戶端重新建立鏈式結構即可

四、缺點

由於一個請求沒有一個明確地接受者，無法保證它一定會被處理

對於較長的職責鏈，系統性能有一定影響且不利於調試

如果建立鏈不當，可能會造成循環調用，導致系統進入死循環

五、應用場景

有多個對象處理同一個請求且無需關心請求的處理對象時誰以及它是如何處理的

可以動態地指定一組對象處理請求，客戶端可以動態創建職責鏈來處理請求，還可以改變鏈中處理者之間的先後次序

六、個人總結

1、這個設計模式的名字很直觀的表現了這個設計模式的特性

當一個請求過來時，我們使用一個鏈條來處理這個請求

鏈條上的每一個處理者只是處理自己能處理的請求，而不處理多余的請求

處理不了的就會交個下一個人

2、這個模式的使用非常簡單，在下面的情況下使用效果很好

當相同的請求需要不同的處理方式，或者是不同權限的請求需要不同的類來處理

處理請求的內部邏輯非常復雜，或者處理的類型分析比較復雜

處理的次序需要進行改變的，需要解耦復雜處理請求的

3、需要註意的是構建責任鏈的時候一定要正確

參考博客：http://www.cnblogs.com/edisonchou/p/7215547.html

大戰設計模式【18】—— 職責鏈模式