初識設計模式 – 職責鏈模式

簡介

職責鏈設計模式(Chain Of Responsibility Design Pattern)的定義是,將請求的發送和接收解耦,讓多個接收對象都有機會處理這個請求。

同時,將這些接收對象串成一條鏈,並沿著這條鏈傳遞這個對象,直至鏈上的某個接收對象能夠處理這個請求為止。

職責鏈可以是一條直線、一個環或一個樹形結構,最常見的職責鏈是直線型,即沿著一條單向的鏈來傳遞請求。

典型實現

首先,定義一個抽象處理者 Handler 類,其程式碼示例如下:

public abstract class Handler {
    // 維持對下一個處理者的引用
    protected Handler successor;

    public void setHandler(Handler successor) {
        this.successor = successor;
    }

    public abstract void handleRequest(String Request);
}

然後,定義一個具體處理者 ConcreteHandler 子類,其程式碼示例如下:

public class ConcreteHandler extends Handler {
    public void handleRequest(String request) {
        // 處理請求或者轉發請求
        this.successor.handleRequest(request);
        // 執行完當前處理方法後,可以執行下一個處理者的處理,完成鏈路循環
    }
}

對於客戶端而言,只需要知道第一個具體處理者是誰即可,無需關心後續的其他處理者。這就像是操作鏈表一樣,知道鏈表的頭結點即可訪問鏈表的所有結點。

分類

根據處理者對象的行為,職責鏈模式可以分為純的職責鏈模式和不純的職責鏈模式。

純的職責鏈模式

一個純的職責鏈模式要求一個具體處理者對象只能在兩種行為中選擇一個:要麼承擔全部責任,要麼將責任推給下家。

同時,純的職責鏈模式要求一個請求必須被某一個具體處理者對象所接受,不能出現某個請求未被處理者對象接收的情形。

不純的職責鏈模式

不純的職責鏈模式是與純的職責鏈模式相對的一種模式。

在一個不純的職責鏈模式中,允許某個請求被具體處理者部分處理後還能向下傳遞,或者一個具體處理者處理完某個請求後其後繼處理者可以繼續處理該對象,而且同一個請求可以最終不被任何處理者對象所接收。

總結

優點

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

  • 將發送者和接收者解耦,客戶端無需知道請求被哪一個對象處理
  • 當工作流程發生變化,可以動態地改變鏈內的成員或調動它們的次序,也可動態的新增或刪除職責
  • 通過鏈式結構串聯處理者,可以根據需要增加新的處理類,符合開閉原則
  • 純的職責鏈模式明確了各類的職責範圍,符合類的單一職責原則

缺點

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

  • 由於請求沒有一個明確的處理者,不能保證請求一定會被處理
  • 對於較長的職責鏈,請求的處理涉及到多個處理對象,系統性能將受到一定影響
  • 職責鏈的建立要靠客戶端來保證,增加了客戶端的複雜性,建鏈不當可能造成循環引用

適用場景

職責鏈模式的適用場景如下:

  • 多個對象可以處理一個請求,但具體由哪一個對象處理在運行時自動確定
  • 需要在不明確指定請求處理者的情況下,向多個處理者中的一個提交請求
  • 動態地指定一組處理者,或者改變鏈中處理者之間的次序

源碼

在 JDK 中 java.util.logging.Logger 記錄日誌有可能有多個不同的 Handler 處理器,如果使用這些 Handler 處理器就是一種職責鏈模式的運用。

如下是源碼部分:

public void log(LogRecord record) {
    if (!isLoggable(record.getLevel())) {
        return;
    }
    Filter theFilter = config.filter;
    if (theFilter != null && !theFilter.isLoggable(record)) {
        return;
    }

    Logger logger = this;
    while (logger != null) {
        final Handler[] loggerHandlers = isSystemLogger
            ? logger.accessCheckedHandlers()
            : logger.getHandlers();

        for (Handler handler : loggerHandlers) {
            handler.publish(record);
        }

        final boolean useParentHdls = isSystemLogger
            ? logger.config.useParentHandlers
            : logger.getUseParentHandlers();

        if (!useParentHdls) {
            break;
        }

        logger = isSystemLogger ? logger.parent : logger.getParent();
    }
}