上篇文章裡對本模式幾乎沒有說什麼，只是推薦大家讀了怪怪的一篇文章，這幾天一直在思考本模式。現將自己的總
不太好，如果翻譯為 「響應鏈模式」我想更好理解一點。應用本模式應該注意以下幾點。
1: 動態的響應請求,而且是多個都有可能處理該請求,沒有一一對應關係 ,響應者是 不固定的.如果是一一對應的
響應請求(固定響應請求關係)則使用表模式
2: 響應鏈做為乙個整體來響應請求,由這個整體來決定誰是最佳響應者，而不是鏈上單一物件決定響應請求,其他
傳遞請求.鏈上的物件都有可能處理請求是否響應是由物件自己的狀態，而不是類別和傳入資訊或它們的對應關
系決定。
3: 職責鏈中每乙個物件都可能而且可以成為入口,而不是職責鏈頭做為入口.無論從**進入, 都能找出這個入口對
象最符合的響應物件.
4: 職責鏈可能用到組合模式,但和鍊錶可能並沒有太大關係,如果職責鏈模式 用鍊錶來實現 很多時候 其實是誤用.
5:「請求的響應者「如果 是多個的話 則有可能變成狀態模式。
6：客戶並不知道鏈上的哪乙個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態地重新組織鏈和分
配責任即鏈的組織形式與客戶端沒有關係.
7：誤用了怎麼辦？如果誤用了你的**肯定會散發出臭味，重複的臭味或邏輯複雜的臭味。如果你能嗅出來，我
想發揮你的才智應該也能解決問題。
8：其實我們追求的是優雅的設計而不是模式，你說是嗎？那為什麼我們在這兒費力的總結該模式呢？雖說，實際
設計中我們一般都是慢慢地重構到模式，但如果你判斷錯誤的話，可能重構的方向就會出現錯誤。等你發現時
已經浪費了很多精力。
職責鏈模式
1.職責鏈 namespace dutychainpattern 用來處理請求 public abstract void transmitrequest int request 班主任 職責鏈上的乙個節點，在裡面進行判斷，看能否處理請求，不能則將請求轉移 public class classadvi...
職責鏈模式
軟體領域中的設計模式為開發人員提供了一種使用專家設計經驗的有效途徑。設計模式中運用了物件導向程式設計語言的重要特性 封裝 繼承 多型，真正領悟設計模式的精髓是可能乙個漫長的過程，需要大量實踐經驗的積累。最近看設計模式的書，對於每個模式，用c 寫了個小例子，加深一下理解。主要參考 大話設計模式 和 設...
職責鏈模式
劇情簡要 學習此模式，讓筆者聯想到自然界的生物鏈。打個比方 大魚吃小魚，小魚吃蝦公尺。河裡的小蝦公尺問大魚，你要不要吃我啊？大魚說 你太小了，吃了 沒吃，return 懶得吃！然後蝦公尺又問小魚 小螃蟹 小河馬同樣的問題。其實如果小蝦公尺這麼想自我了結的話，根本不用這麼費勁。這就開始了我們職責鏈模式...