劇情簡要：
學習此模式，讓筆者聯想到自然界的生物鏈。打個比方：大魚吃小魚，小魚吃蝦公尺。河裡的小蝦公尺問大魚，「你要不要吃我啊？」大魚說「你太小了，吃了
==沒吃，
return
懶得吃！」然後蝦公尺又問小魚、小螃蟹、小河馬同樣的問題。其實如果小蝦公尺這麼想自我了結的話，根本不用這麼費勁。這就開始了我們職責鏈模式的介紹和使用。
主角上場：
所謂職責鏈，其實就是在以小蝦公尺為被食者的生物鏈上，將所有的捕食者進行有序的職責排列。對外提供乙個捕食者的介面。如果先問到大魚，大魚不想吃（不能處理此事件）時，便自動跳轉到詢問職責鏈上下乙個捕食者，直至遇到那個對味的，美美的享受一餐，成全小蝦公尺的夙願。省去了小蝦公尺每次都要找人問（導致問、答兩類間強耦合），問完了得到答案，也不知道是喜是悲。
具體**入下：
abstract class handler //提供乙個抽象處理介面類
public abstract void handlerrequest(int request)
}class concretehandler1:handler //具體處理者（小魚、大魚、小螃蟹）
else if (successor !=null) //如果處理不了，則轉向下乙個物件，直至有物件可以處理此要求。}}
使用職責鏈模式的好處呢，就是當請求發出，不管怎麼傳遞，最終都會有乙個具體處理物件對此請求做出處理。同時也降低了請求發出者和處理者間的耦合度。
觀後感：
總結到這裡吧，對設計模式一書也有了點自己的拙見，跟大家分享。雖然這本書通過生活中大量例項來對每個模式進行剖析，引人入勝，閱讀者也拍手稱讚。但是我們在讀的時候，不僅僅要能理解作者舉的例子，還應該聯絡自己的生活實際，去聯想，看看這個模式對應我們生活的某部分，我們能否舉出來更恰當有意思的例項。所謂站在巨人的肩膀上嘛，通過大腦反覆思考推敲出來的東西，才是自己的，不然總在為作者的天馬行空而激動喝彩，
23個模式看完了，也就忘了差不多了。
個人拙見，僅供參考。
職責鏈模式
1.職責鏈 namespace dutychainpattern 用來處理請求 public abstract void transmitrequest int request 班主任 職責鏈上的乙個節點，在裡面進行判斷，看能否處理請求，不能則將請求轉移 public class classadvi...
職責鏈模式
軟體領域中的設計模式為開發人員提供了一種使用專家設計經驗的有效途徑。設計模式中運用了物件導向程式設計語言的重要特性 封裝 繼承 多型，真正領悟設計模式的精髓是可能乙個漫長的過程，需要大量實踐經驗的積累。最近看設計模式的書，對於每個模式，用c 寫了個小例子，加深一下理解。主要參考 大話設計模式 和 設...
職責鏈模式
職責鏈模式 使多個物件都有機會處理請求，從而避免請求的傳送者和接受者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。using system using system.collections.generic using system.linq using sy...