建站
咨詢
售后
建站咨詢
新聞中心
就如星爺多年前說的那樣“你看那代碼，好像一條鏈哎”。什么？他沒說過嗎，或許我記錯(cuò)了。你應(yīng)該已經(jīng)猜到了，這篇文章，我們來討論一下責(zé)任鏈設(shè)計(jì)模式。這個(gè)模式并不流行，至少在 Gang of Four定義的模式中是這樣。但現(xiàn)代依賴注入框架讓我們可以用巧妙的新奇的方式去實(shí)現(xiàn)這個(gè)模式，我們來看看。
創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供永定網(wǎng)站建設(shè)、永定做網(wǎng)站、永定網(wǎng)站設(shè)計(jì)、永定網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、永定企業(yè)網(wǎng)站模板建站服務(wù)，十多年永定做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
介紹
聲明：這種模式并沒有新東西。我的一個(gè)同事剛剛前幾天使用過，我也曾用過很多次。這篇文章的靈感來源于我最近遇到的問題，我們下面來說說，我之前也沒有意識(shí)到這個(gè)問題可以用這種模式來解決。
傳統(tǒng)模式
責(zé)任鏈模式是一種行為設(shè)計(jì)模式，它***在Gang of Four寫的Design Patterns這本書中提及。模式的目的是：
避免請(qǐng)求的發(fā)送者與接收者耦合,為多個(gè)對(duì)象提供處理請(qǐng)求的機(jī)會(huì).將接收對(duì)象串聯(lián)成鏈,請(qǐng)求在鏈上傳遞,直到被一個(gè)對(duì)象處理.
類的關(guān)系圖如下所示:
通過定義一個(gè)可以用來響應(yīng)客戶端請(qǐng)求的標(biāo)準(zhǔn)接口，來實(shí)現(xiàn)松耦合。在上面的圖中，表現(xiàn)為Handler抽象類型?？梢酝ㄟ^創(chuàng)建鏈?zhǔn)降念?，繼承上面的接口來實(shí)現(xiàn)多個(gè)類響應(yīng)請(qǐng)求的能力。每一個(gè)類在鏈中擁有下一個(gè)節(jié)點(diǎn)的實(shí)例。successor屬性滿足作用域。
當(dāng)調(diào)用時(shí)，每一個(gè)handler確定自己是否有能力處理請(qǐng)求。如果有，它執(zhí)行請(qǐng)求的操作，在這，我們可以根據(jù)請(qǐng)求的轉(zhuǎn)發(fā)規(guī)則實(shí)現(xiàn)許多不同的處理方式。一旦一個(gè)ConcreteHandler聲明可以處理這個(gè)請(qǐng)求，我們可以實(shí)現(xiàn)規(guī)則用于停止請(qǐng)求在鏈中傳遞。這種情況下，handleRequest方法的實(shí)現(xiàn)方式如下所示：
if (/* The request can be successfully handled */) {
// Handle the request
} else {
successor.handleRequest(request);
}另一方面，我們可以將請(qǐng)求轉(zhuǎn)發(fā)到鏈中的下一個(gè)handler，無論當(dāng)前的handler是否能處理。
if (/* The request can be successfully handled */) {
// Handle the request
}
successor.handleRequest(request);構(gòu)建鏈的操作應(yīng)該和下面差不多。
Handler chain = new ConcreteHandler1(new ConcreteHandler2(new ConcreteHandler3())); chain.handleRequest(request);
在JDK內(nèi)部實(shí)現(xiàn)中，至少有兩個(gè)地方用到了這種模式：
- logging機(jī)制的實(shí)現(xiàn):java.util.logging.Logger#log()
- http請(qǐng)求過濾器機(jī)制和Servlet響應(yīng)規(guī)范的實(shí)現(xiàn):javax.servlet.Filter#doFilter()
依賴注入的出現(xiàn)
正如許多其他的情況一樣，依賴注入模式的出現(xiàn)改變了一切。讓我們看看依賴注入特性如何使責(zé)任鏈模式現(xiàn)代化。
首先，我們需要一個(gè)所有依賴注入庫都實(shí)現(xiàn)的特性：multibindings。基本上，它可以提供一個(gè)類型的所有子類型的實(shí)例，僅僅通過注入這個(gè)類型的集合。
比如下面這個(gè)類型系統(tǒng)：
interface Shop {}
class PetShop implements Shop {}
class Grocery implements Shop {}
class Drugstore implements Shop {}
// And so on...現(xiàn)在，我們定義一個(gè)新類型ShoppingCenter，它擁有Shop每個(gè)子類型的實(shí)例。使用依賴注入，我們可以通過在ShoppingCenter注入一個(gè)Shop集合來實(shí)現(xiàn)這一目標(biāo)。
class ShoppingCenter {
private final Set shops;
@Inject
public void ShoppingCenter(Set shops) {
this.shops = shops;
}
// Class body using shops
} 真TM簡(jiǎn)單！顯然，每一個(gè)依賴注入庫都有自己的配置來解決這種情況。在Spring中，使用auto-discovery特性，你只需要一點(diǎn)小小的配置。在Guice，稍稍復(fù)雜，但最終結(jié)果一樣。
責(zé)任鏈模式的現(xiàn)代化實(shí)現(xiàn)
簡(jiǎn)單總結(jié)一下：我們已經(jīng)看到了責(zé)任鏈模式的典型形式；我們看到了依賴注入庫提供的multibinding特性；***，我們看到了如何把這兩個(gè)概念搭配使用。
首先，我們需要一個(gè)與原始的責(zé)任鏈設(shè)計(jì)模式稍有不同的實(shí)現(xiàn)。讓我們引入一個(gè)新的類型ChainHandler。這個(gè)類型的職責(zé)就是擁有整個(gè)鏈，并暴露出一個(gè)接口，用于訪問鏈提供給客戶端的操作函數(shù)。
class ChainHandler {
private final Set handlers;
@Inject
public void ChainHandler(Set 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));
}
} 利用依賴注入的優(yōu)勢(shì)，在不改變已有代碼的基礎(chǔ)上增加一個(gè)Handler的實(shí)現(xiàn)。這意味著實(shí)際上我們不需要執(zhí)行回歸測(cè)試。另一方面，將Handler的執(zhí)行放入鏈中有一點(diǎn)困難(但并不是不能)
警告
正如很多其他的模式一樣，專注于構(gòu)造模式的每個(gè)類的角色是什么很重要。你會(huì)給每個(gè)具體的Handler什么功能？你會(huì)把應(yīng)用的業(yè)務(wù)邏輯直接放在Handler里面嗎？
首先，我們很多人都會(huì)提供上面的解決方案，這并不完全錯(cuò)誤。然而，這種設(shè)計(jì)限制了代碼的復(fù)用并違反了單一職責(zé)原則(Single Responsibility Principle)。
舉個(gè)例子，我們需要實(shí)現(xiàn)一個(gè)系統(tǒng)，用來在金融業(yè)務(wù)中補(bǔ)全信息，補(bǔ)全操作使用責(zé)任鏈模式。一個(gè)可能要插入的補(bǔ)全信息就是根據(jù)IBAN(國際銀行賬號(hào))或BIC碼(銀行代碼)導(dǎo)出的收款人國家。然后我們來定義一個(gè)CountryPayeeEnricher。
首先看一下，我們可以在CountryPayeeEnricher中直接編寫代碼用來補(bǔ)全國家信息。但如果我們需要在我們應(yīng)用的其他位置(或其他應(yīng)用)復(fù)用這個(gè)功能呢？遵循組合原則是一個(gè)更好地解決方案，將代碼放進(jìn)一個(gè)專有的類中，比如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
}
}通過這種方式，我們最終有了兩個(gè)擁有不同職責(zé)的類型：PayeeService類型，提供可復(fù)用的直接聯(lián)系收款人信息的服務(wù)。CountryPayeeEnricher類型，代替之前類型提供服務(wù)的標(biāo)準(zhǔn)入口。
Scala方式
為了***，我也想討論一下用Scala語言實(shí)現(xiàn)責(zé)任鏈模式。正如很多其他設(shè)計(jì)模式一樣，這門語言內(nèi)部已經(jīng)實(shí)現(xiàn)了責(zé)任鏈模式：偏函數(shù)(partial functions)。在理論層面，偏函數(shù)是定義了域里的一部分值的函數(shù)。在Scala中，這種函數(shù)有一個(gè)特別的類型——PartialFunction[T, V]
在Scala中使用模式匹配(pattern matching)聲明來定義偏函數(shù)，在下面這個(gè)例子中，fraction的默認(rèn)值是0。
val fraction: PartialFunction[Int, Int] = {
case d: Int if d != 0 => 42 / d
}如果有多個(gè)定義集合，你可以有多個(gè)case子句。如果你為了應(yīng)用函數(shù)，把每個(gè)case子句作為滿足的情況(責(zé)任鏈里的handler,記得嗎?)，你就再次用到了責(zé)任鏈：
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"
//. ..
}緊接著，一個(gè)偏函數(shù)可以當(dāng)做好多handler構(gòu)成的鏈。顯然，通過這種方式使用責(zé)任鏈模式，你必須遵守一些額外的約束。事實(shí)上：
- 你不能在每個(gè)handler中儲(chǔ)存元數(shù)據(jù)
- 你不能從鏈中移除handler
- 你不能顯示檢查handler或美觀的打印它
如果你確實(shí)不需要做上面這些事情，模式匹配偏函數(shù)(pattern-matching PartialFunctions)用起來相當(dāng)棒。
標(biāo)題名稱：你看那代碼，好像一條鏈哎
標(biāo)題路徑：http://www.dlmjj.cn/article/cdegsjo.html
