使用場景：
（1）如果有多個物件可以處理同乙個請求，但是具體由哪個物件來處理該請求，是執行時刻動態確定的。這種情況可以使用職責鏈模式，把處理請求的物件實現成為職責物件，然後把它們構成乙個職責鏈，當請求在這個鏈中傳遞的時候，具體由哪個職責物件來處理，會在執行時動態判斷。
（2）如果你想在不明確指定接收者的情況下，向多個物件中的其中乙個提交請求的話，可以使用職責鏈模式。職責鏈模式實現了請求者和接收者之間的解耦，請求者不需要知道究竟是哪乙個接收者物件來處理了請求。
（3）如果想要動態指定處理乙個請求的物件集合，可以使用職責鏈模式。職責鏈模式能動態地構建職責鏈，也就是動態地來決定到底哪些職責物件來參與到處理請求中來，相當於是動態地指定了處理乙個請求的職責物件集合。
3 相關模式
（1）職貴鏈模式和組合模式
這兩個模式可以組合使用。可以把職責物件通過組合模式來組合，這樣可以通過組合物件自動遞迴地向上呼叫，由父元件作為子元件的後繼，從而形成鏈。這也就是前面提到過的使用外部已有的鏈結，這種情況在客戶端使用的時候，就不用再構造鏈了，雖然不構造鏈，但是需要構造組合物件樹，是一樣的。
（2）職責鏈模式和裝飾模式
這兩個模式相似，從某個角度講，可以相互模擬實現對方的功能裝飾模式能夠動態地給被裝飾物件新增功能，要求裝飾器物件和被裝飾的物件實現相同的介面。而職貴鏈模式可以實現動態的職責組合，標準的功能是有個物件處理就結束，但是如果處理完本職貴不急於結東，而是繼線向下傳遞請求，那麼其功能就和裝飾模式的功能差不多了，每個職責物件就類似於裝飾器，可以實現某種功能。而且兩個模式的本質也相似，都需要在執行期間動態組合，裝飾模式是動態組合裝飾器，而職貴鏈是動態組合處理請求的職責物件的鏈但是從標準的設計模式上來講，這兩個模式還是有較大區別的，這點要注意。首先是目的不同，裝飾模式是要實現透明的為物件新增功能，而職貴鏈模式是要實現傳送者和接收者解耦;另外乙個，裝飾模式是無限遞迴呼叫的，可以有任意多個物件來裝飾功能，但是職貴鏈模式是有乙個處理就結束。
（3）職責鏈模式和策略模式
這兩個模式可以組合使用。這兩個模式有相似之處，如果把職貴鏈簡化到直接就能選擇到相應的處理物件那就跟策略模式的選擇差不多，因此可以用職責鏈來模擬策略模式的功能。只是如果把職責鏈簡化到這個地步，也就不存在鏈了，也就稱不上是職責鏈了。兩個模式可以組合使用，可以在職責鏈模式的某個職責實現的時候，使用策略模式來選擇具體的實現，同樣也可以在策略模式的某個策略實現中，使用職貴鏈模式來實現功能處理。同理職責鏈模式也可以和狀態模式組合使用。
0
責任鏈模式（行為型）
思考問題 模擬班遊集體請假 學校規定 對於班遊，學生提交的申請表，必須經過輔導員 系主任 院長 校長簽名確認才能出遊，現在由你來設計該業務模型模擬該需求，應該如何設計？解答 很直觀的一種想法 我直接設計乙個學生類 乙個申請單類requestnote 乙個輔導員類 乙個系主任類 乙個院長類 乙個校長類...
設計模式 行為型 責任鏈模式
從擊鼓傳花談起 擊鼓傳花是一種熱鬧而又緊張的飲酒遊戲。在酒宴上賓客依次坐定位置，由一人擊鼓，擊鼓的地方與傳花的地方是分開的，以示公正。開始擊鼓時，花束就開始依次傳遞，鼓聲一落，假如花束在某人手中，則該人就得飲酒。擊鼓傳花的類圖結構如下 如果用乙個物件系統描述賈府，那麼賈母 賈赦 賈政 賈寶玉和賈環等...
設計模式 行為型 責任鏈模式
責任鏈 chain of responsibility 模式為請求建立了乙個接收者物件的鏈。這種模式給予請求的型別，對請求的傳送者和接收者進行解耦。這種型別的設計模式屬於行為型模式。使用場景 乙個請求物件需要多種任務的處理，通過鏈式傳播物件的場景。優點1.職責鏈對於客戶請求是透明的 2.鏈 將請求的...