今天跟大家分享下設計模式中的職責鏈模式。
不知道大家在學習職責鏈模式的時候是否感覺困難。我剛開始學的時候就被整暈了。呵呵，進入正題。
職責鏈模式是物件行為型模式中比較有特點的設計模式了，的確有意思，它可以像資料結構中煉表一樣傳遞。其實生活中好多的行為方式都體現了職責鏈模式，我們初期學習者可以把職責鏈模式理解為我們所玩的鬥地主紙牌遊戲，在鬥地主的遊戲中，三者是迴圈出牌，下一家仍然是玩家。
其實職責鏈模式在開發中用的頻率不是很高，正是它模式結構的特點引來了很多學習者的興趣（也包括我，嘿嘿）。
職責鏈模式中包含兩個角色：（1）handler 抽象處理者 （2）具體處理者
抽象處理者用來抽象出具體處理者的共同特點：處理方式和處理者。
具體處理者針對不同的情況進行處理，在處理之前需要對許可權進行判斷，如果符合條件就交給本身處理，否則就交給此處理者的下乙個處理者來做處理。
我們舉乙個例子：在oa系統中，假設有乙個請假條例：員工請假天數根據不同情況分別交給主任，部門經理，總經理來處理。
在這個例子中，主任，部門經理，總經理就是具體的處理者，而員工請假天數就是所要處理的請求，根據不同的天數，即不同的許可權來判斷由誰來處理。
下面是我寫的**例項：
（1）員工請假天數請求類
(2)抽象處理者類
(3)具體處理者類
主任類
經理類
總經理類
客戶端類
類圖
此例明顯的體現了職責鏈模式的應用。從職責鏈模式可以看出其特點：
（1）職責鏈模式使得乙個物件無須知道是其他哪個物件來處理該請求，僅需知道該請求會被處理即可。鏈中的物件不需要知道鏈的形成結構，完全由客戶端來對鏈的順序進行建立，降低了系統的耦合度
（2）簡化了物件之間的相互連線，僅需在客戶端維持乙個鏈的（即指向後繼者的引用）
（3）可以對鏈進行動態的增加和刪除，而不會影響其他鏈的行為。
（4）在系統中增加乙個新的具體處理者時，只需要增加乙個具體類作為抽象處理類的子類，不需要修改源**，符合開閉原則。
同樣，因為在職責鏈模式中，請求沒有明確的接收者，有時候就不能保證請求一定會被處理。並且對於較長的職責鏈，如果每次都要到最後乙個處理者來處理，那麼前邊的處理者相當於占用了絕對的資源和使程式執行效率降低。使用不當還會造成死迴圈鏈。所以使用時應該對此考慮，充分利用其優點來發揮職責鏈的優勢，ok，今天就說到這了，這是我第一篇關於設計模式的部落格，之前自己一直不敢寫，總感覺自己的思路需要整理，以後還會不斷努力更新哦~
設計模式 職責鏈模式
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...
設計模式 職責鏈模式
職責鏈模式，參考這篇文章寫的很好。外觀模式，參考這篇文章寫的也很好。職責鏈，chain of responsibility。1.意圖 使多個物件都有機會處理請求，從而避免請求的傳送者和接受者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。3.適用性 在以下條件...