職責鏈模式（chain of responsibility）：使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這個物件連線成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個（concretehandler）物件處理它為止。
職責鏈模式uml結構圖：
這裡發出的請求，客戶端並不知道這當中的哪乙個物件最終處理這個請求，這樣系統的更改可以在不影響客戶端的情況下動態地重新組織和分配任務。
職責鏈模式使得接收者和傳送者都沒有對方的明確資訊，且鏈中的物件自己也不知道鏈的結構，簡化了物件的相互連線，它們僅需要保持乙個指向其後繼者的引用，而不需要保持它所有的候選接收者的引用，這樣耦合度就大大降低了。（我們可以隨時增加或者修改處理乙個請求的結構，增加了給物件指派職責的靈活性）（但是也需要考慮到請求可能到了鏈的末端都無法得到處理的情況或者因為沒有正確配置而得不到處理，那樣就變得糟糕了）
基本**：
abstract class handler
public abstract void handlerequest(int request);
}class concretehandler1 : handler
處理請求 ",
this.gettype().name, request);
}else if (successor != null)}}
class concretehandler2 : handler
處理請求 ",
this.gettype().name, request);
}else if (successor != null)}}
class concretehandler3 : handler
處理請求 ",
this.gettype().name, request);
}else if (successor != null)}}
class program
;foreach (int request in requests)
console.read();}}
職責鏈模式
1.職責鏈 namespace dutychainpattern 用來處理請求 public abstract void transmitrequest int request 班主任 職責鏈上的乙個節點，在裡面進行判斷，看能否處理請求，不能則將請求轉移 public class classadvi...
職責鏈模式
軟體領域中的設計模式為開發人員提供了一種使用專家設計經驗的有效途徑。設計模式中運用了物件導向程式設計語言的重要特性 封裝 繼承 多型，真正領悟設計模式的精髓是可能乙個漫長的過程，需要大量實踐經驗的積累。最近看設計模式的書，對於每個模式，用c 寫了個小例子，加深一下理解。主要參考 大話設計模式 和 設...
職責鏈模式
劇情簡要 學習此模式，讓筆者聯想到自然界的生物鏈。打個比方 大魚吃小魚，小魚吃蝦公尺。河裡的小蝦公尺問大魚，你要不要吃我啊？大魚說 你太小了，吃了 沒吃，return 懶得吃！然後蝦公尺又問小魚 小螃蟹 小河馬同樣的問題。其實如果小蝦公尺這麼想自我了結的話，根本不用這麼費勁。這就開始了我們職責鏈模式...