一、引言
初看責任鏈模式，心裡不禁想起了乙個以前聽過的相聲：看牙。說的是乙個病人看牙的時候，醫生不小心把拔下的乙個牙掉進了病人嗓子裡。病人因此樓上樓下的跑了好多科室，最後無果而終。
責任鏈模式就是這種「推卸」責任的模式，你的問題在我這裡能解決我就解決，不行就把你推給另乙個物件。至於到底誰解決了這個問題了呢？我管呢！
二、定義與結構
從名字上大概也能猜出這個模式的大概模樣——系統中將會存在多個有類似處理能力的物件。當乙個請求觸發後，請求將在這些物件組成的鏈條中傳遞，直到找到最合適的「責任」物件，並進行處理。
《設計模式》中給它的定義如下：使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。
呵呵，從定義上可以看出，責任鏈模式的提出是為了「解耦」，以應變系統需求的變更和不明確性。
下面是《設計模式》中給出的適用範圍：
1) 有多個的物件可以處理乙個請求，哪個物件處理該請求執行時刻自動確定。
2) 你想在不明確指定接收者的情況下，向多個物件中的乙個提交乙個請求。
3) 可處理乙個請求的物件集合應被動態指定。
責任鏈模式真的能給傳送者和接收者之間解耦（這好像很神奇）嗎？先來看下它的組成角色。這個問題我會在下面提及。
責任鏈模式由兩個角色組成：
1) 抽象處理者角色（handler）：它定義了乙個處理請求的介面。當然對於鍊子的不同實現，也可以在這個角色中實現後繼鏈。
2) 具體處理者角色（concrete handler）：實現抽象角色中定義的介面，並處理它所負責的請求。如果不能處理則訪問它的後繼者。
至於類圖不放也罷。畢竟就是乙個繼承或者實現。
三、純與不純
責任鏈模式的純與不純的區別，就像黑貓、白貓的區別一樣。不要刻意的去使自己的**來符合乙個模式的公式。只要能夠使**降低耦合、提高重用，滿足系統需求並能很好的適應變化就好了。正所謂：管它黑貓白貓，抓住老鼠就是好貓！
純的責任鏈模式，規定乙個具體處理者角色只能對請求作出兩種動作：自己處理；傳給下家。不能出現處理了一部分，把剩下的傳給了下家的情況。而且請求在責任鏈中必須被處理，而不能出現無果而終的結局。
反之，則就是不純的責任鏈模式。
下面的例子就是採用了上面提到的「不純的責任鏈模式」。
四、舉例
這個例子**於專案中我剛剛完成的乙個小功能點——「代號自動生成器」。在專案中存在很多地方，比如：員工工號、檔案代號，要求客戶在使用時輸入。而這些代號對於乙個特定的企業或者類別，往往有一定的規則。因此可以讓使用者在系統引數中維護一定的規則，然後通過「代號自動生成器」來給使用者生成代號。
根據初期需求，使用者代號中往往存在以下幾種變動元素：年份、月份、日期、流水號。由於需求比較簡單，因此考慮到使用者可能存在其他變動元素，所以我打算在「被第一顆子彈擊中」後重構一下現有的結構。下面就是我在頭腦中演繹過的使用責任鏈模式的重構。
這裡只用來說明下責任鏈模式的結構和使用，因此不體現功能細節。
//這是抽象處理者角色
public inte***ce codeautoparse
//這個為處理日期使用的具體處理者
public class dateautoparse implements codeautoparse
/**實現的處理請求的介面
*這個介面首先判斷使用者定義的格式是否有流水號,有則解析,沒有則跳過
*下傳到下乙個處理者
*/public string generatecode(string modulecode, int number, string rule, string target)
throws baseexception
其它具體處理者也是如此的結構，每乙個裡面都設定有乙個用來存放下乙個處理者的引用，不管你有沒有下乙個處理者。
其實責任鏈模式本身的結構和使用都沒有什麼，就是乙個繼承或者實現。在處理請求的時候，按照規定去呼叫下乙個處理者。但是怎麼來維護這樣一條鍊子呢？
《設計模式》一書中僅僅說必須自己引入它，可以參考使用list或者map來進行註冊。而在上面我使用spring來管理具體處理者角色的引入。當有了新的處理者需要新增的時候，僅僅需要修改下配置檔案。
五、其他
責任鏈模式優點，上面已經體現出來了。無非就是降低了耦合、提高了靈活性。但是責任鏈模式可能會帶來一些額外的效能損耗，因為它要從鍊子開頭開始遍歷。
六、總結
完成了責任鏈模式的學習，希望大家一起**，指正。
深入淺出責任鏈模式
一 引言初看責任鏈模式，心裡不禁想起了乙個以前聽過的相聲 看牙。說的是乙個病人看牙的時候，醫生不小心把拔下的乙個牙掉進了病人嗓子裡。病人因此樓上樓下的跑了好多科室，最後無果而終。責任鏈模式就是這種 推卸 責任的模式，你的問題在我這裡能解決我就解決，不行就把你推給另乙個物件。至於到底誰解決了這個問題了...
深入淺出設計模式 模板模式
設計模式是程式設計師必須掌握的技能，熟練應用各種設計模式，不僅可以提公升我們的編碼能力，也可以使得我們的編碼更美觀。在這裡我們來講解一下模板模式。模板模式 template pattern 中，乙個抽象類公開定義了執行它的方法的方式 模板。它的子類可以按需要重寫方法實現，但呼叫將以抽象類中定義的方式...
深入淺出設計模式 工廠模式
披薩店新推出了點單系統，披薩需要通過不同的製作，相同的烘焙，裁剪等工序才能完成。披薩的種類實在太多了，在構造披薩例項時，光是if else 語句就長的可怕，修改與維護更令人頭疼。披薩子類繼承實現相同的基類，通過基類呼叫不同的子類，使得 具有一定的彈性，將構造子類放入業務 導致了子類與業務 的耦合，令...