請求的鏈式處理——職責鏈模式（四）

16.4 純與不純的職責鏈模式

      職責鏈模式可分為純的職責鏈模式和不純的職責鏈模式兩種：

       (1) 純的職責鏈模式

      一個純的職責鏈模式要求一個具體處理者物件只能在兩個行為中選擇一個：要麼承擔全部責任，要麼將責任推給下家，不允許出現某一個具體處理者物件在承擔了一部分或全部責任後又將責任向下傳遞的情況。而且在純的職責鏈模式中，要求一個請求必須被某一個處理者物件所接收，不能出現某個請求未被任何一個處理者物件處理的情況。在前面的採購單審批例項中應用的是純的職責鏈模式。

       (2)不純的職責鏈模式

      在一個不純的職責鏈模式中允許某個請求被一個具體處理者部分處理後再向下傳遞，或者一個具體處理者處理完某請求後其後繼處理者可以繼續處理該請求，而且一個請求可以最終不被任何處理者物件所接收。Java AWT 1.0中的事件處理模型應用的是不純的職責鏈模式，其基本原理如下：由於視窗元件（如按鈕、文字框等）一般都位於容器元件中，因此當事件發生在某一個元件上時，先通過元件物件的handleEvent()方法將事件傳遞給相應的事件處理方法，該事件處理方法將處理此事件，然後決定是否將該事件向上一級容器元件傳播；上級容器元件在接到事件之後可以繼續處理此事件並決定是否繼續向上級容器元件傳播，如此反覆，直到事件到達頂層容器元件為止；如果一直傳到最頂層容器仍沒有處理方法，則該事件不予處理。每一級元件在接收到事件時，都可以處理此事件，而不論此事件是否在上一級已得到處理，還存在事件未被處理的情況。顯然，這就是不純的職責鏈模式，早期的Java AWT事件模型(JDK 1.0及更早)中的這種事件處理機制又叫事件浮升(Event Bubbling)機制。從Java.1.1以後，JDK使用觀察者模式代替職責鏈模式來處理事件。目前，在JavaScript中仍然可以使用這種事件浮升機制來進行事件處理。

16.5 職責鏈模式總結

      職責鏈模式通過建立一條鏈來組織請求的處理者，請求將沿著鏈進行傳遞，請求傳送者無須知道請求在何時、何處以及如何被處理，實現了請求傳送者與處理者的解耦。在軟體開發中，如果遇到有多個物件可以處理同一請求時可以應用職責鏈模式，例如在Web應用開發中建立一個過濾器(Filter)鏈來對請求資料進行過濾，在工作流系統中實現公文的分級審批等等，使用職責鏈模式可以較好地解決此類問題。

       1.主要優點

      職責鏈模式的主要優點如下：

       (1) 職責鏈模式使得一個物件無須知道是其他哪一個物件處理其請求，物件僅需知道該請求會被處理即可，接收者和傳送者都沒有對方的明確資訊，且鏈中的物件不需要知道鏈的結構，由客戶端負責鏈的建立，降低了系統的耦合度。

       (2) 請求處理物件僅需維持一個指向其後繼者的引用，而不需要維持它對所有的候選處理者的引用，可簡化物件的相互連線。

       (3) 在給物件分派職責時，職責鏈可以給我們更多的靈活性，可以通過在執行時對該鏈進行動態的增加或修改來增加或改變處理一個請求的職責。

       (4) 在系統中增加一個新的具體請求處理者時無須修改原有系統的程式碼，只需要在客戶端重新建鏈即可，從這一點來看是符合“開閉原則”的。

       2.主要缺點

      職責鏈模式的主要缺點如下：

       (1) 由於一個請求沒有明確的接收者，那麼就不能保證它一定會被處理，該請求可能一直到鏈的末端都得不到處理；一個請求也可能因職責鏈沒有被正確配置而得不到處理。

       (2) 對於比較長的職責鏈，請求的處理可能涉及到多個處理物件，系統效能將受到一定影響，而且在進行程式碼除錯時不太方便。

       (3) 如果建鏈不當，可能會造成迴圈呼叫，將導致系統陷入死迴圈。

       3.適用場景

      在以下情況下可以考慮使用職責鏈模式：

       (1) 有多個物件可以處理同一個請求，具體哪個物件處理該請求待執行時刻再確定，客戶端只需將請求提交到鏈上，而無須關心請求的處理物件是誰以及它是如何處理的。

       (2) 在不明確指定接收者的情況下，向多個物件中的一個提交一個請求。

        (3) 可動態指定一組物件處理請求，客戶端可以動態建立職責鏈來處理請求，還可以改變鏈中處理者之間的先後次序。 

【作者：劉偉 http://blog.csdn.net/lovelion】