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