意圖
傳送者的請求沿著鏈狀路徑進行傳播，直至有接收者處理為止。這種情況下接收者根據自身判斷決定是否處理某個請求，從而避免傳送者和接收者之間的耦合。
動機
考慮乙個公司管理軟體，目前正管理著下面的公司：
公司的很多流程都由下級員工發起，例如報告進度、取得個人資訊等。實現這些功能的難點在於：公司的組織結構可能不同，各個部門的職責也會發生變化。例如某些公司2:worker發出的進度報告由1:division處理；另外一些公司可能就需要ceo直接處理。我們需要一種設計可以很方便地應對這種變化。答案就是職責鏈模式。
職責鏈模式的想法是，請求的傳送者只管沿著預定的溝通渠道將請求傳送出去，溝通渠道上的節點根據自己的需求決定是否處理該請求。對於公司管理軟體的例子來說處理流程是這樣的：首先2:worker向上位組織發出請求。如果有必要，1.division會處理這個請求。否則將該請求繼續上傳，直到有節點處理這個請求為止。
比較巧妙的是：公司的組織結構或者流程發生變化時只需要發生變化的部門改變自己的處理邏輯即可。其他部門或者個人不需要任何變動。這就是所謂的解耦合。
雖然組織圖一般是樹狀結構，但請求的傳播是由下而上的，呈現一種鏈式結構。這應該就是職責鏈這個名稱的由來。
設計模式 職責鏈模式
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...
設計模式 職責鏈模式
今天跟大家分享下設計模式中的職責鏈模式。不知道大家在學習職責鏈模式的時候是否感覺困難。我剛開始學的時候就被整暈了。呵呵，進入正題。職責鏈模式是物件行為型模式中比較有特點的設計模式了，的確有意思，它可以像資料結構中煉表一樣傳遞。其實生活中好多的行為方式都體現了職責鏈模式，我們初期學習者可以把職責鏈模式...