實話設計模式之：職責鏈

Chain of Responsibility

(c) 2009 張恂

本文的最新版在《大道至簡：實話設計模式》：http://www.zhangxun.com/entry.aspx?sname=GoFpatterns

別名

處理流水線

簡述

這是一條任務處理的流水線（或鏈條）。首先讓任務請求的處理者（物件）排成一個佇列，然後客戶把處理請求遞給第一名處理者進行處理或加工，處理完畢後再轉交給後繼的下一名處理者進行處理，並照此讓任務請求沿著這條流水線依次傳遞下去，直到最後一名處理者收到、處理完該請求。這條流水線上的每名處理者都可能擔負著不同的處理職責，故名職責鏈。

結構圖

一系列 Worker 排成一條流水線。

圖中看上去像根電車“辮子”的 next 關聯（後繼鏈）可謂是職責鏈模式的關鍵（要害）。如果拿掉這根辮子，我們發現職責鏈模式就蛻變（縮減）成了一個 Strategy 模式。

現實世界中的例子

實在太多了。

1）擊鼓傳花遊戲

2）工廠生產流水線

基本特點

1、實現請求傳送者與接收者（處理者）之間的解耦，請求的傳送者並不知道最終有哪個或哪些接收者對該請求進行了處理。而請求（物件）本身也不需要知道鏈的結構。

2、請求的可能處理者排成一條鏈，請求沿著這條鏈在多個處理者之間進行傳遞。每個鏈上的處理者都具有統一的處理請求以及訪問到它的後繼者的（抽象）介面。

何時採用職責鏈模式

1、一個請求可能有多個候選的處理者，具體由哪個物件進行處理，需要在執行時自動確定。

2、在請求的實際處理者事先不明確的情況下，向一組候選物件中的某一個提交該請求。

3、需要動態指定可處理一個請求的候選物件集合。

典型應用例項

GoF《設計模式》中關於職責鏈，舉的是一個 GUI 中事件傳播、與上下文有關的幫助機制的例子。由兩個 Widget 類 Button 和 Dialog 以及應用程式類 Application 三種物件組成一個 handleHelp 事件處理鏈，當使用者在 button 上按下 help 按鈕時，將呼叫 button->HandleHelp()，此訊息會依次傳遞給後繼的 Dialog 或 Application 物件，從而讓使用者獲得與上下文相關的幫助資訊。

在該案例中，作者沒有展示後繼鏈如何被動態地改變。

職責鏈模式在 GUI 使用者事件處理中很常見，使用者事件（使用者點選滑鼠或按鍵盤）沿著一條職責鏈傳播，直到由實際負責的物件、控制元件對其進行處理或加工。

職責鏈例項：Web 文字中 UBBCode、XTag 標記的簡易處理 (1)

變化點

1、如何實現後繼鏈的建立和使用？

2、如何封裝被處理的請求物件（the Request object）？

相關模式

職責鏈常與 Composite 一起使用，請求可沿著物件的組合結構在父子部件之間進行傳遞。

職責鏈模式是一系列 Strategy 模式（物件）的串聯。

在職責鏈中被處理的請求物件可採用 Command 模式。

下一頁

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13633641/viewspace-557939/，如需轉載，請註明出處，否則將追究法律責任。