簡要描述職責鏈模式：有乙個命令(傳送者)發出，沿著一串物件傳遞，只有符合條件的可以處理它，一般處理完就中止傳遞。
優點:降低耦合度，將請求的傳送者和接收者解耦。
簡化了物件，使得物件不需要知道鏈的結構。
增強給物件指派職責的靈活性，通過改變鏈內的成員或者調整它們的次序來動態改變職責。
增加新的具體處理者很方便，無須修改原有**，只需要在客戶端重新建鏈即可。
缺點：由於沒有明確的接收者，所以無法保證請求一定會被處理（可能直到鏈的末端都得不到處理，也可能因為鏈沒有配置正確而得不到處理。）
對於較長的職責鏈來說，請求可能涉及到多個處理物件，這將會使系統效能受到一定影響，而且不利於**除錯。
如果建鏈不當，可能會造成迴圈呼叫，這將導致系統陷入死迴圈。
適合場景：
有多個物件可以處理同一請求，具體哪個物件處理由執行時刻自動確定。客戶端只負責提交請求，而無須關心請求的處理 物件是誰以及它是如何處理的。
在不明確指定接受者的情況下，向多個物件中的乙個提交乙個請求。
可動態指定一組物件處理請求，客戶端可以動態建立職責鏈來處理請求，還可以改變鏈中處理者之間的先後次序。
案例：建立抽象處理者：抽象處理者除了提供乙個處理請假的介面之外，還有乙個很關鍵的地方就是定義後繼者，這樣便可以構建一條鏈。
職責鏈模式
1.職責鏈 namespace dutychainpattern 用來處理請求 public abstract void transmitrequest int request 班主任 職責鏈上的乙個節點，在裡面進行判斷，看能否處理請求，不能則將請求轉移 public class classadvi...
職責鏈模式
軟體領域中的設計模式為開發人員提供了一種使用專家設計經驗的有效途徑。設計模式中運用了物件導向程式設計語言的重要特性 封裝 繼承 多型，真正領悟設計模式的精髓是可能乙個漫長的過程，需要大量實踐經驗的積累。最近看設計模式的書，對於每個模式，用c 寫了個小例子，加深一下理解。主要參考 大話設計模式 和 設...
職責鏈模式
劇情簡要 學習此模式，讓筆者聯想到自然界的生物鏈。打個比方 大魚吃小魚，小魚吃蝦公尺。河裡的小蝦公尺問大魚，你要不要吃我啊？大魚說 你太小了，吃了 沒吃，return 懶得吃！然後蝦公尺又問小魚 小螃蟹 小河馬同樣的問題。其實如果小蝦公尺這麼想自我了結的話，根本不用這麼費勁。這就開始了我們職責鏈模式...