就如星爺多年前說的那樣“你看那代碼，好像一條鏈哎”。什么？他沒說過嗎，或許我記錯了。你應該已經猜到了，這篇文章，我們來討論一下責任鏈設計模式。這個模式并不流行，至少在 Gang of Four定義的模式中是這樣。但現代依賴注入框架讓我們可以用巧妙的新奇的方式去實現這個模式，我們來看看。

介紹

聲明：這種模式并沒有新東西。我的一個同事剛剛前幾天使用過，我也曾用過很多次。這篇文章的靈感來源于我最近遇到的問題，我們下面來說說，我之前也沒有意識到這個問題可以用這種模式來解決。

傳統模式

責任鏈模式是一種行為設計模式，它***在Gang of Four寫的Design Patterns這本書中提及。模式的目的是：

避免請求的發送者與接收者耦合,為多個對象提供處理請求的機會.將接收對象串聯成鏈,請求在鏈上傳遞,直到被一個對象處理.

類的關系圖如下所示:

通過定義一個可以用來響應客戶端請求的標準接口，來實現松耦合。在上面的圖中，表現為Handler抽象類型。可以通過創建鏈式的類，繼承上面的接口來實現多個類響應請求的能力。每一個類在鏈中擁有下一個節點的實例。successor屬性滿足作用域。

當調用時，每一個handler確定自己是否有能力處理請求。如果有，它執行請求的操作，在這，我們可以根據請求的轉發規則實現許多不同的處理方式。一旦一個ConcreteHandler聲明可以處理這個請求，我們可以實現規則用于停止請求在鏈中傳遞。這種情況下，handleRequest方法的實現方式如下所示：

if (/* The request can be successfully handled */) {
    // Handle the request
} else {
    successor.handleRequest(request);
}

另一方面，我們可以將請求轉發到鏈中的下一個handler，無論當前的handler是否能處理。

if (/* The request can be successfully handled */) {
    // Handle the request
}
successor.handleRequest(request);

構建鏈的操作應該和下面差不多。

Handler chain = new ConcreteHandler1(new ConcreteHandler2(new ConcreteHandler3()));
chain.handleRequest(request);

在JDK內部實現中，至少有兩個地方用到了這種模式：

• logging機制的實現:java.util.logging.Logger#log()
• http請求過濾器機制和Servlet響應規范的實現:javax.servlet.Filter#doFilter()

依賴注入的出現

正如許多其他的情況一樣，依賴注入模式的出現改變了一切。讓我們看看依賴注入特性如何使責任鏈模式現代化。

首先，我們需要一個所有依賴注入庫都實現的特性：multibindings。基本上，它可以提供一個類型的所有子類型的實例，僅僅通過注入這個類型的集合。

比如下面這個類型系統：

interface Shop {}
class PetShop implements Shop {}
class Grocery implements Shop {}
class Drugstore implements Shop {}
// And so on...

現在，我們定義一個新類型ShoppingCenter，它擁有Shop每個子類型的實例。使用依賴注入，我們可以通過在ShoppingCenter注入一個Shop集合來實現這一目標。

class ShoppingCenter {
    private final Set<Shop> shops;
    @Inject
    public void ShoppingCenter(Set<Shop> shops) {
        this.shops = shops;
    }
    // Class body using shops
}

真TM簡單！顯然，每一個依賴注入庫都有自己的配置來解決這種情況。在Spring中，使用auto-discovery特性，你只需要一點小小的配置。在Guice，稍稍復雜，但最終結果一樣。

責任鏈模式的現代化實現

簡單總結一下：我們已經看到了責任鏈模式的典型形式；我們看到了依賴注入庫提供的multibinding特性；***，我們看到了如何把這兩個概念搭配使用。

首先，我們需要一個與原始的責任鏈設計模式稍有不同的實現。讓我們引入一個新的類型ChainHandler。這個類型的職責就是擁有整個鏈，并暴露出一個接口，用于訪問鏈提供給客戶端的操作函數。

class ChainHandler {
    private final Set<Handler> handlers;
    @Inject
    public void ChainHandler(Set<Handler> handlers) {
        this.handlers = handlers;
    }
    // Pass the request to each handler of the chain
    public void handle(final Request request) {
        handlers.forEach(h -> h.handle(request));
    }
}

利用依賴注入的優勢，在不改變已有代碼的基礎上增加一個Handler的實現。這意味著實際上我們不需要執行回歸測試。另一方面，將Handler的執行放入鏈中有一點困難(但并不是不能)

警告

正如很多其他的模式一樣，專注于構造模式的每個類的角色是什么很重要。你會給每個具體的Handler什么功能？你會把應用的業務邏輯直接放在Handler里面嗎？

首先，我們很多人都會提供上面的解決方案，這并不完全錯誤。然而，這種設計限制了代碼的復用并違反了單一職責原則(Single Responsibility Principle)。

舉個例子，我們需要實現一個系統，用來在金融業務中補全信息，補全操作使用責任鏈模式。一個可能要插入的補全信息就是根據IBAN(國際銀行賬號)或BIC碼(銀行代碼)導出的收款人國家。然后我們來定義一個CountryPayeeEnricher。

首先看一下，我們可以在CountryPayeeEnricher中直接編寫代碼用來補全國家信息。但如果我們需要在我們應用的其他位置(或其他應用)復用這個功能呢？遵循組合原則是一個更好地解決方案，將代碼放進一個專有的類中，比如PayeeService：

class PayeeService {
    public Country deriveCountryFromPayee(String payee) {
        // Code that extract the country information from the
        // input payess
    }
    // Omissis...
}
class CountryPayeeEnricher implements Enrichment {
    private PayeeService payeeService;
    @Inject
    public void CountryPayeeEnricher(PayeeService payeeService) {
        this.payeeService = payeeService;
    }
    public void handle(Transaction tx) {
        Country country = payeeService.deriveCountryFromPayee(tx.getPayee());
        tx.setCountry(country);
        // ...or something like this
    }
}

通過這種方式，我們最終有了兩個擁有不同職責的類型：PayeeService類型，提供可復用的直接聯系收款人信息的服務。CountryPayeeEnricher類型，代替之前類型提供服務的標準入口。

Scala方式

為了***，我也想討論一下用Scala語言實現責任鏈模式。正如很多其他設計模式一樣，這門語言內部已經實現了責任鏈模式：偏函數(partial functions)。在理論層面，偏函數是定義了域里的一部分值的函數。在Scala中，這種函數有一個特別的類型——PartialFunction[T, V]

在Scala中使用模式匹配(pattern matching)聲明來定義偏函數，在下面這個例子中，fraction的默認值是0。

val fraction: PartialFunction[Int, Int] = {
  case d: Int if d != 0 =>  42 / d
}

如果有多個定義集合，你可以有多個case子句。如果你為了應用函數，把每個case子句作為滿足的情況(責任鏈里的handler,記得嗎?)，你就再次用到了責任鏈：

case class Request(val value: String) { /* ... */ }
val someStupidFunction: PartialFunction[Request, String] = {
  case Request(42) => "The final answer"
  case Request(0) => "You know nothing, John Snow"
  case Request(666) => "Something strange is going on in here"
  //. ..
}

緊接著，一個偏函數可以當做好多handler構成的鏈。顯然，通過這種方式使用責任鏈模式，你必須遵守一些額外的約束。事實上：

• 你不能在每個handler中儲存元數據
• 你不能從鏈中移除handler
• 你不能顯示檢查handler或美觀的打印它

如果你確實不需要做上面這些事情，模式匹配偏函數(pattern-matching PartialFunctions)用起來相當棒。