設計模式(行為型)之職責鏈模式(Chain of Responsibility Pattern)，食物鏈food.chain

設計模式(行為型)之職責鏈模式(Chain of Responsibility Pattern)，食物鏈food.chain

PS一句：最終還是選擇CSDN來整理髮表這幾年的知識點，該文章平行遷移到CSDN。因為CSDN也支援MarkDown文法了，牛逼啊！

【工匠若水 http://blog.csdn.net/yanbober】 閱讀前一篇《設計模式(行為型)之狀態模式(State Pattern)》http://blog.csdn.net/yanbober/article/details/45502665

概述

職責鏈可以是一條直線、一個環或者一個樹形結構，最常見的職責鏈是直線型，即沿著一條單向的鏈來傳遞請求。鏈上的每一個對象都是請求處理者，職責鏈模式可以將請求的處理者組織成一條鏈，並讓請求沿著鏈傳遞，由鏈上的處理者對請求進行相應的處理，用戶端無須關心請求的處理細節以及請求的傳遞，只需將請求發送到鏈上即可，實現請求寄件者和請求處理者解耦。

核心

概念： 避免請求寄件者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象串連成一條鏈，並且沿著這條鏈傳遞請求，直到有對象處理它為止。職責鏈模式是一種對象行為型模式。

責任鏈模式結構重要核心模組：

Handler（抽象處理者）

定義一個處理請求的介面，一般設計為抽象類別，由於不同的具體處理者處理請求的方式不同，因此在其中定義了抽象請求處理方法。因為每一個處理者的下家還是一個處理者，因此在抽象處理者中定義了一個抽象處理者類型的對象作為其對下家的引用。通過該引用，處理者可以連成一條鏈。（是不是有點像C語言的鏈表結構呢？）

ConcreteHandler（具體處理者）

抽象處理者的子類，可以處理使用者請求，在具體處理者類中實現了抽象處理者中定義的抽象請求處理方法，在處理請求之前需要進行判斷，看是否有相應的處理許可權，如果可以處理請求就處理它，否則將請求轉寄給後繼者；在具體處理者中可以訪問鏈中下一個對象，以便請求的轉寄。

責任鏈模式分類：

純的職責鏈模式

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

不純的職責鏈模式

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

使用情境

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

在不明確指定接收者的情況下，向多個對象中的一個提交一個請求。

可動態指定一組對象處理請求，用戶端可以動態建立職責鏈來處理請求，還可以改變鏈中處理者之間的先後次序。

程式猿執行個體

這裡展示一個責任鏈模式的例子（類比Android App開發過程，程式猿寫好代碼需要找UI設計師審核UI效果、找Leader review代碼、找測試工程師測試App，然後找產品經理確認App後發布App），嚴格遵守責任鏈模式幾大核心模板，不多解釋：

package yanbober.github.io;//常量interface Type {    int UI_EFFECT = 0;    int CODE_FORMAT = 1;    int TEST_PROJECT = 2;    int PUBLISH_APP = 3;}//Handler（抽象處理者）abstract class Handler {    private Handler mHandler;    public Handler getmHandler() {        return mHandler;    }    public void setmHandler(Handler mHandler) {        this.mHandler = mHandler;    }    abstract String handleRequest(int type, String user);}//ConcreteHandler（具體處理者）class ConcreteHandlerGUI extends Handler {    @Override    String handleRequest(int type, String user) {        String ret = "";        if (Type.UI_EFFECT == type) {            ret = user + "’s App UI is Ok!";        }        else {            if (getmHandler() != null) {                System.out.println("*********** ConcreteHandlerGUI **************");                ret = getmHandler().handleRequest(type, user);            }        }        return ret;    }}class ConcreteHandlerTeamLeader extends Handler {    @Override    String handleRequest(int type, String user) {        String ret = "";        if (Type.CODE_FORMAT == type) {            ret = user + "’s App code format is Ok!";        }        else {            if (getmHandler() != null) {                System.out.println("*********** ConcreteHandlerTeamLeader **************");                ret = getmHandler().handleRequest(type, user);            }        }        return ret;    }}class ConcreteHandlerPM extends Handler {    @Override    String handleRequest(int type, String user) {        String ret = "";        if (Type.PUBLISH_APP == type) {            ret = user + "’s App can be publish!";        }        else {            if (getmHandler() != null) {                System.out.println("*********** ConcreteHandlerPM **************");                ret = getmHandler().handleRequest(type, user);            }        }        return ret;    }}class ConcreteHandlerTestEngineer extends Handler {    @Override    String handleRequest(int type, String user) {        String ret = "";        if (Type.TEST_PROJECT == type) {            ret = user + "’s App test is Ok!";        }        else {            if (getmHandler() != null) {                System.out.println("*********** ConcreteHandlerTestEngineer **************");                ret = getmHandler().handleRequest(type, user);            }        }        return ret;    }}//用戶端public class Main {    public static void main(String[] args) {        Handler code = new ConcreteHandlerTeamLeader();        Handler ui = new ConcreteHandlerGUI();        Handler test = new ConcreteHandlerTestEngineer();        Handler publish = new ConcreteHandlerPM();        code.setmHandler(ui);        ui.setmHandler(test);        test.setmHandler(publish);        //yanbo找team leader review代碼        System.out.println(code.handleRequest(Type.CODE_FORMAT, "YanBo"));        //yanbo找team leader測試代碼        System.out.println(code.handleRequest(Type.TEST_PROJECT, "YanBo"));    }}

總結一把

職責鏈模式優點：

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

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

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

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

職責鏈模式缺點：

因為一個請求沒有明確的接收者，所以不能保證它一定會被處理，該請求可能一直到鏈的末端都得不到處理；一個請求也可能因職責鏈沒有被正確配置而得不到處理。

對於比較長的職責鏈，請求的處理可能涉及到多個處理對象，系統效能將受到一定影響，而且在進行代碼調試時不太方便。

如果建鏈不當，可能會造成迴圈調用，將導致系統陷入死迴圈。

【工匠若水 http://blog.csdn.net/yanbober】 繼續閱讀《設計模式(行為型)之中介者模式(Mediator Pattern)》 http://blog.csdn.net/yanbober/article/details/45533335