設計模式使用的例子
避免將請求傳送者與接受者耦合在一起，讓多個物件都有機會接受請求，將這些物件連成一條鏈，並且沿著這條鏈傳遞請求，直到有物件處理它為止。
handler（抽象處理者）：定義了乙個處理請求的介面，一般設計為抽象類，由於不同的具體處理者處理請求的方式不同，因此在其中定義了抽象請求處理方法。
concretehandler（具體處理者）：它是抽象處理者的子類，可以處理使用者請求，它實現了在抽象處理者中定義的抽象請求處理方法。
在處理請求之前需要判斷是否有相應的處理許可權，如果可以則處理，否則則將請求**給後繼者。
使得乙個物件無需知道是其他哪乙個物件處理其請求，物件僅需知道該請求會被處理即可，且鏈式結構由客戶端建立
在系統中增加乙個新的具體處理者無須修改原有系統源**，只需要在客戶端重新建立鏈式結構即可
由於乙個請求沒有乙個明確地接受者，無法保證它一定會被處理
對於較長的職責鏈，系統效能有一定影響且不利於除錯
如果建立鏈不當，可能會造成迴圈呼叫，導致系統進入死迴圈
有多個物件處理同乙個請求且無需關心請求的處理物件時誰以及它是如何處理的
可以動態地指定一組物件處理請求，客戶端可以動態建立職責鏈來處理請求，還可以改變鏈中處理者之間的先後次序
1、這個設計模式的名字很直觀的表現了這個設計模式的特性
當乙個請求過來時，我們使用乙個鏈條來處理這個請求
鏈條上的每乙個處理者只是處理自己能處理的請求，而不處理多餘的請求
處理不了的就會交個下乙個人
2、這個模式的使用非常簡單，在下面的情況下使用效果很好
當相同的請求需要不同的處理方式，或者是不同許可權的請求需要不同的類來處理
處理請求的內部邏輯非常複雜，或者處理的型別分析比較複雜
處理的次序需要進行改變的，需要解耦複雜處理請求的
3、需要注意的是構建責任鏈的時候一定要正確
參考部落格：
設計模式 職責鏈模式
2008年08月17日 星期日 下午 04 28 using system using system.collections.generic using system.text public officer officer o public abstract void deal action a c...
設計模式 職責鏈模式
1 request.h ifndef request h define request h include include using namespace std class request 請求類定義 endif request h 2 manager.h ifndef manager h def...
設計模式 職責鏈模式
今天跟大家分享下設計模式中的職責鏈模式。不知道大家在學習職責鏈模式的時候是否感覺困難。我剛開始學的時候就被整暈了。呵呵，進入正題。職責鏈模式是物件行為型模式中比較有特點的設計模式了，的確有意思，它可以像資料結構中煉表一樣傳遞。其實生活中好多的行為方式都體現了職責鏈模式，我們初期學習者可以把職責鏈模式...