點擊上方"java全棧技術"關注，每天學習一個java知識點
“一對二”，“過”，“過”……這聲音熟悉嗎？你會想到什麼？對！紙牌。在類似“鬥地主”這樣的紙牌遊戲中，某人出牌給他的下家，下家看看手中的牌，如果要不起上家的牌則將出牌請求再轉發給他的下家，其下家再進行判斷。一個循環下來，如果其他人都要不起該牌，則最初的出牌者可以打出新的牌。在這個過程中，牌作為一個請求沿著一條鏈在傳遞，每一位紙牌的玩家都可以處理該請求。在設計模式中，我們也有一種專門用於處理這種請求鏈式傳遞的模式，它就是本章將要介紹的職責鏈模式。
1 採購單的分級審批
Sunny軟件公司承接了某企業SCM(Supply Chain Management，供應鏈管理)系統的開發任務，其中包含一個採購審批子系統。該企業的採購審批是分級進行的，即根據採購金額的不同由不同層次的主管人員來審批，主任可以審批5萬元以下（不包括5萬元）的採購單，副董事長可以審批5萬元至10萬元（不包括10萬元）的採購單，董事長可以審批10萬元至50萬元（不包括50萬元）的採購單，50萬元及以上的採購單就需要開董事會討論決定。如圖1所示：
圖1 採購單分級審批示意圖
如何在軟件中實現採購單的分級審批？Sunny軟件公司開發人員提出了一個初始解決方案，在系統中提供一個採購單處理類PurchaseRequestHandler用於統一處理採購單，其框架代碼如下所示：
問題貌似很簡單，但仔細分析，發現上述方案存在如下幾個問題：
(1)PurchaseRequestHandler類較為龐大，各個級別的審批方法都集中在一個類中，違反了“單一職責原則”，測試和維護難度大。
(2)如果需要增加一個新的審批級別或調整任何一級的審批金額和審批細節（例如將董事長的審批額度改為60萬元）時都必須修改源代碼並進行嚴格測試，此外，如果需要移除某一級別（例如金額為10萬元及以上的採購單直接由董事長審批，不再設副董事長一職）時也必須對源代碼進行修改，違反了“開閉原則”。
(3)審批流程的設置缺乏靈活性，現在的審批流程是“主任-->副董事長-->董事長-->董事會”，如果需要改為“主任-->董事長-->董事會”，在此方案中只能通過修改源代碼來實現，客戶端無法定製審批流程。
如何針對上述問題對系統進行改進？Sunny公司開發人員迫切需要一種新的設計方案，還好有職責鏈模式，通過使用職責鏈模式我們可以最大程度地解決這些問題，下面讓我們正式進入職責鏈模式的學習。
2 職責鏈模式概述
很多情況下，在一個軟件系統中可以處理某個請求的對象不止一個，例如SCM系統中的採購單審批，主任、副董事長、董事長和董事會都可以處理採購單，他們可以構成一條處理採購單的鏈式結構，採購單沿著這條鏈進行傳遞，這條鏈就稱為職責鏈。職責鏈可以是一條直線、一個環或者一個樹形結構，最常見的職責鏈是直線型，即沿著一條單向的鏈來傳遞請求。鏈上的每一個對象都是請求處理者，職責鏈模式可以將請求的處理者組織成一條鏈，並讓請求沿著鏈傳遞，由鏈上的處理者對請求進行相應的處理，客戶端無須關心請求的處理細節以及請求的傳遞，只需將請求發送到鏈上即可，實現請求發送者和請求處理者解耦。
職責鏈模式定義如下：
職責鏈模式(Chain of Responsibility Pattern)：避免請求發送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，並且沿著這條鏈傳遞請求，直到有對象處理它為止。職責鏈模式是一種對象行為型模式。
職責鏈模式結構的核心在於引入了一個抽象處理者。職責鏈模式結構如圖16-2所示：
在職責鏈模式結構圖中包含如下幾個角色：
● Handler（抽象處理者）：它定義了一個處理請求的接口，一般設計為抽象類，由於不同的具體處理者處理請求的方式不同，因此在其中定義了抽象請求處理方法。因為每一個處理者的下家還是一個處理者，因此在抽象處理者中定義了一個抽象處理者類型的對象（如結構圖中的successor），作為其對下家的引用。通過該引用，處理者可以連成一條鏈。
● ConcreteHandler（具體處理者）：它是抽象處理者的子類，可以處理用戶請求，在具體處理者類中實現了抽象處理者中定義的抽象請求處理方法，在處理請求之前需要進行判斷，看是否有相應的處理權限，如果可以處理請求就處理它，否則將請求轉發給後繼者；在具體處理者中可以訪問鏈中下一個對象，以便請求的轉發。
在職責鏈模式裡，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪一個對象最終處理這個請求，這使得
系統可以在不影響客戶端的情況下動態地重新組織鏈和分配責任。職責鏈模式的核心在於抽象處理者類的設計，抽象處理者的典型代碼如下所示：
上述代碼中，抽象處理者類定義了對下家的引用對象，以便將請求轉發給下家，該對象的訪問符可設為protected，在其子類中可以使用。在抽象處理者類中聲明瞭抽象的請求處理方法，具體實現交由子類完成。
具體處理者是抽象處理者的子類，它具有兩大作用：第一是處理請求，不同的具體處理者以不同的形式實現抽象請求處理方法handleRequest()；第二是轉發請求，如果該請求超出了當前處理者類的權限，可以將該請求轉發給下家。具體處理者類的典型代碼如下：
在具體處理類中通過對請求進行判斷可以做出相應的處理。
需要注意的是，職責鏈模式並不創建職責鏈，職責鏈的創建工作必須由系統的其他部分來完成，一般是在使用該職責鏈的客戶端中創建職責鏈。職責鏈模式降低了請求的發送端和接收端之間的耦合，使多個對象都有機會處理這個請求。
3 完整解決方案
為了讓採購單的審批流程更加靈活，並實現採購單的鏈式傳遞和處理，Sunny公司開發人員使用職責鏈模式來實現採購單的分級審批，其基本結構如圖16-3所示：
在圖16-3中，抽象類Approver充當抽象處理者（抽象傳遞者），Director、VicePresident、President和Congress充當具體處理者（具體傳遞者），PurchaseRequest充當請求類。完整代碼如下所示：
編寫如下客戶端測試代碼：
編譯並運行程序，輸出結果如下：
如果需要在系統增加一個新的具體處理者，如增加一個經理(Manager)角色可以審批5萬元至8萬元（不包括8萬元）的採購單，需要編寫一個新的具體處理者類Manager，作為抽象處理者類Approver的子類，實現在Approver類中定義的抽象處理方法，如果採購金額大於等於8萬元，則將請求轉發給下家，代碼如下所示：
由於鏈的創建過程由客戶端負責，因此增加新的具體處理者類對原有類庫無任何影響，無須修改已有類的源代碼，符合“開閉原則”。
在客戶端代碼中，如果要將新的具體請求處理者應用在系統中，需要創建新的具體處理者對象，然後將該對象加入職責鏈中。如在客戶端測試代碼中增加如下代碼：
將建鏈代碼改為：
重新編譯並運行程序，輸出結果如下：
4 純與不純的職責鏈模式
職責鏈模式可分為純的職責鏈模式和不純的職責鏈模式兩種：
(1) 純的職責鏈模式
一個純的職責鏈模式要求一個具體處理者對象只能在兩個行為中選擇一個：要麼承擔全部責任，要麼將責任推給下家，不允許出現某一個具體處理者對象在承擔了一部分或全部責任後又將責任向下傳遞的情況。而且在純的職責鏈模式中，要求一個請求必須被某一個處理者對象所接收，不能出現某個請求未被任何一個處理者對象處理的情況。在前面的採購單審批實例中應用的是純的職責鏈模式。
(2)不純的職責鏈模式
在一個不純的職責鏈模式中允許某個請求被一個具體處理者部分處理後再向下傳遞，或者一個具體處理者處理完某請求後其後繼處理者可以繼續處理該請求，而且一個請求可以最終不被任何處理者對象所接收 。Java AWT 1.0中的事件處理模型應用的是不純的職責鏈模式，其基本原理如下：由於窗口組件（如按鈕、文本框等）一般都位於容器組件中，因此當事件發生在某一個組件上時，先通過組件對象的handleEvent()方法將事件傳遞給相應的事件處理方法，該事件處理方法將處理此事件，然後決定是否將該事件向上一級容器組件傳播；上級容器組件在接到事件之後可以繼續處理此事件並決定是否繼續向上級容器組件傳播，如此反覆，直到事件到達頂層容器組件為止；如果一直傳到最頂層容器仍沒有處理方法，則該事件不予處理。每一級組件在接收到事件時，都可以處理此事件，而不論此事件是否在上一級已得到處理，還存在事件未被處理的情況。顯然，這就是不純的職責鏈模式，早期的Java AWT事件模型(JDK 1.0及更早)中的這種事件處理機制又叫事件浮升(Event Bubbling)機制。從Java.1.1以後，JDK使用觀察者模式代替職責鏈模式來處理事件。目前，在JavaScript中仍然可以使用這種事件浮升機制來進行事件處理。
5 職責鏈模式總結
職責鏈模式通過建立一條鏈來組織請求的處理者，請求將沿著鏈進行傳遞，請求發送者無須知道請求在何時、何處以及如何被處理，實現了請求發送者與處理者的解耦。在軟件開發中，如果遇到有多個對象可以處理同一請求時可以應用職責鏈模式，例如在Web應用開發中創建一個
過濾器(Filter)鏈來對請求數據進行過濾，在工作流系統中實現公文的分級審批等等，使用職責鏈模式可以較好地解決此類問題。1.主要優點
職責鏈模式的主要優點如下：
(1) 職責鏈模式使得一個對象無須知道是其他哪一個對象處理其請求，對象僅需知道該請求會被處理即可，接收者和發送者都沒有對方的明確信息，且鏈中的對象不需要知道鏈的結構，由客戶端負責鏈的創建，降低了系統的耦合度。
(2) 請求處理對象僅需維持一個指向其後繼者的引用，而不需要維持它對所有的候選處理者的引用，可簡化對象的相互連接。
(3) 在給對象分派職責時，職責鏈可以給我們更多的靈活性，可以通過在運行時對該鏈進行動態的增加或修改來增加或改變處理一個請求的職責。
(4) 在系統中增加一個新的具體請求處理者時無須修改原有系統的代碼，只需要在客戶端重新建鏈即可，從這一點來看是符合“開閉原則”的。
2.主要缺點
職責鏈模式的主要缺點如下：
(1) 由於一個請求沒有明確的接收者，那麼就不能保證它一定會被處理，該請求可能一直到鏈的末端都得不到處理；一個請求也可能因職責鏈沒有被正確配置而得不到處理。
(2) 對於比較長的職責鏈，請求的處理可能涉及到多個處理對象，系統性能將受到一定影響，而且在進行代碼調試時不太方便。
(3) 如果建鏈不當，可能會造成循環調用，將導致系統陷入死循環。
3.適用場景
在以下情況下可以考慮使用職責鏈模式：
(1) 有多個對象可以處理同一個請求，具體哪個對象處理該請求待運行時刻再確定，客戶端只需將請求提交到鏈上，而無須關心請求的處理對象是誰以及它是如何處理的。
(2) 在不明確指定接收者的情況下，向多個對象中的一個提交一個請求。
(3) 可動態指定一組對象處理請求，客戶端可以動態創建職責鏈來處理請求，還可以改變鏈中處理者之間的先後次序。
原文：http://blog.csdn.net/lovelion
閱讀更多 java全棧技術 的文章
關鍵字: 採購 編程語言 JavaScript
