一、
引言初看責任鏈模式，心裡不禁想起了乙個以前聽過的相聲：看牙。說的是乙個病人看牙的時候，醫生不小心把拔下的乙個牙掉進了病人嗓子裡。病人因此樓上樓下的跑了好多科室，最後無果而終。
責任鏈模式就是這種「推卸
」責任的模式，你的問題在我這裡能解決我就解決，不行就把你推給另乙個物件。至於到底誰解決了這個問題了呢？我管呢！
二、定義與結構
從名字上大概也能猜出這個模式的大概模樣
——系統中將會存在多個有類似處理能力的物件。當乙個請求觸發後，請求將在這些物件組成的鏈條中傳遞，直到找到最合適的「責任
」物件，並進行處理。
《設計模式》中給它的定義如下：使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。
呵呵，從定義上可以看出，責任鏈模式的提出是為了「解耦
」，以應變系統需求的變更和不明確性。
下面是《設計模式》中給出的適用範圍：
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
來管理具體處理者角色的引入。當有了新的處理者需要新增的時候，僅僅需要修改下配置檔案。
五、其他
責任鏈模式優點，上面已經體現出來了。無非就是降低了耦合、提高了靈活性。但是責任鏈模式可能會帶來一些額外的效能損耗，因為它要從鍊子開頭開始遍歷。
六、總結
完成了責任鏈模式的學習，希望大家一起**，指正。
深入淺出設計模式筆記之十一 責任鏈模式
一 引言 初看責任鏈模式，心裡不禁想起了乙個以前聽過的相聲 看牙。說的是乙個病人看牙的時候，醫生不小心把拔下的乙個牙掉進了病人嗓子裡。病人因此樓上樓下的跑了好多科室，最後無果而終。責任鏈模式就是這種 推卸 責任的模式，你的問題在我這裡能解決我就解決，不行就把你推給另乙個物件。至於到底誰解決了這個問題...
深入淺出模板方法模式
一 引子這是乙個很簡單的模式，卻被非常廣泛的使用。之所以簡單是因為在這個模式中僅僅使用到了繼承關係。繼承關係由於自身的缺陷，被專家們扣上了 罪惡 的帽子。使用委派關係代替繼承關係 盡量使用介面實現而不是抽象類繼承 等等專家警告，讓我們這些菜鳥對繼承 另眼相看 其實，繼承還是有很多自身的優點所在。只是...
深入淺出之工廠模式
首先說說簡單工廠模式，我用現實中的汽車工廠舉例子，首先有個汽車類的介面叫做car,裡面有個開車的方法叫做drive 然後有個吉利車的類叫做jili,實現了car的介面,還有個奇瑞車的類叫做qirui,也實現了car的介面 因為都是車嘛，當然能開了 inte ce carelse if qirui e...