# 請求的鏈式處理——職責鏈模式（四） 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) 可動態指定一組對象處理請求，客戶端可以動態創建職責鏈來處理請求，還可以改變鏈中處理者之間的先后次序。 練習 > Sunny軟件公司的OA系統需要提供一個假條審批模塊：如果員工請假天數小于3天，主任可以審批該假條；如果員工請假天數大于等于3天，小于10天，經理可以審批；如果員工請假天數大于等于10天，小于30天，總經理可以審批；如果超過30天，總經理也不能審批，提示相應的拒絕信息。試用職責鏈模式設計該假條審批模塊。