前言

在現(xiàn)實(shí)生活中，一個事件需要經(jīng)過多個對象處理是很常見的場景。例如，采購審批流程、請假流程等。公司員工請假，可批假的領(lǐng)導(dǎo)有部門負(fù)責(zé)人、副總經(jīng)理、總經(jīng)理等，但每個領(lǐng)導(dǎo)能批準(zhǔn)的天數(shù)不同，員工必須根據(jù)需要請假的天數(shù)去找不同的領(lǐng)導(dǎo)簽名，也就是說員工必須記住每個領(lǐng)導(dǎo)的姓名、電話和地址等信息，這無疑增加了難度。

在計算機(jī)軟硬件中也有相關(guān)例子，如總線網(wǎng)中數(shù)據(jù)報傳送，每臺計算機(jī)根據(jù)目標(biāo)地址是否同自己的地址相同來決定是否接收；還有異常處理中，處理程序根據(jù)異常的類型決定自己是否處理該異常；還有 Struts2的攔截器、JSP和 Servlet 的 Filter 等，所有這些，都可以考慮使用責(zé)任鏈模式來實(shí)現(xiàn)。

介紹

顧名思義，責(zé)任鏈模式（Chain of Responsibility Pattern）為請求創(chuàng)建了一個接收者對象的鏈。這種模式給予請求的類型，對請求的發(fā)送者和接收者進(jìn)行解耦。這種類型的設(shè)計模式屬于行為型模式。在這種模式中，通常每個接收者都包含對另一個接收者的引用。如果一個對象不能處理該請求，那么它會把相同的請求傳給下一個接收者，依此類推。

意圖：避免請求發(fā)送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，并且沿著這條鏈傳遞請求，直到有對象處理它為止。

主要解決：職責(zé)鏈上的處理者負(fù)責(zé)處理請求，客戶只需要將請求發(fā)送到職責(zé)鏈上即可，無須關(guān)心請求的處理細(xì)節(jié)和請求的傳遞，所以職責(zé)鏈將請求的發(fā)送者和請求的處理者解耦了。

關(guān)鍵代碼：Handler 里面聚合它自己，在 HandlerRequest 里判斷是否合適，如果沒達(dá)到條件則向下傳遞，向誰傳遞之前 set 進(jìn)去。

應(yīng)用實(shí)例：?1、紅樓夢中的"擊鼓傳花"。 2、JS 中的事件冒泡。 3、JAVA WEB 中 Apache Tomcat 對 Encoding 的處理，Struts2 的攔截器，jsp servlet 的 Filter。

使用場景：?1、有多個對象可以處理同一個請求，具體哪個對象處理該請求由運(yùn)行時刻自動確定。 2、在不明確指定接收者的情況下，向多個對象中的一個提交一個請求。 3、可動態(tài)指定一組對象處理請求。

注意事項：在 JAVA WEB 中遇到很多應(yīng)用。

優(yōu)點(diǎn)：

降低了對象之間的耦合度。該模式使得一個對象無須知道到底是哪一個對象處理其請求以及鏈的結(jié)構(gòu)，發(fā)送者和接收者也無須擁有對方的明確信息。

增強(qiáng)了系統(tǒng)的可擴(kuò)展性。可以根據(jù)需要增加新的請求處理類，滿足開閉原則。

增強(qiáng)了給對象指派職責(zé)的靈活性。當(dāng)工作流程發(fā)生變化，可以動態(tài)地改變鏈內(nèi)的成員或者調(diào)動它們的次序，也可動態(tài)地新增或者刪除責(zé)任。

責(zé)任鏈簡化了對象之間的連接。每個對象只需保持一個指向其后繼者的引用，不需保持其他所有處理者的引用，這避免了使用眾多的 if 或者 if···else 語句。

責(zé)任分擔(dān)。每個類只需要處理自己該處理的工作，不該處理的傳遞給下一個對象完成，明確各類的責(zé)任范圍，符合類的單一職責(zé)原則。

?主要缺點(diǎn)：

不能保證每個請求一定被處理。由于一個請求沒有明確的接收者，所以不能保證它一定會被處理，該請求可能一直傳到鏈的末端都得不到處理。

對比較長的職責(zé)鏈，請求的處理可能涉及多個處理對象，系統(tǒng)性能將受到一定影響。

職責(zé)鏈建立的合理性要靠客戶端來保證，增加了客戶端的復(fù)雜性，可能會由于職責(zé)鏈的錯誤設(shè)置而導(dǎo)致系統(tǒng)出錯，如可能會造成循環(huán)調(diào)用。

模式的結(jié)構(gòu)與實(shí)現(xiàn)

職責(zé)鏈模式主要包含以下角色。

抽象處理者（Handler）角色：定義一個處理請求的接口，包含抽象處理方法和一個后繼連接。

具體處理者（Concrete Handler）角色：實(shí)現(xiàn)抽象處理者的處理方法，判斷能否處理本次請求，如果可以處理請求則處理，否則將該請求轉(zhuǎn)給它的后繼者。

客戶類（Client）角色：創(chuàng)建處理鏈，并向鏈頭的具體處理者對象提交請求，它不關(guān)心處理細(xì)節(jié)和請求的傳遞過程。

責(zé)任鏈模式的本質(zhì)是解耦請求與處理，讓請求在處理鏈中能進(jìn)行傳遞與被處理；理解責(zé)任鏈模式應(yīng)當(dāng)理解其模式，而不是其具體實(shí)現(xiàn)。責(zé)任鏈模式的獨(dú)到之處是將其節(jié)點(diǎn)處理者組合成了鏈?zhǔn)浇Y(jié)構(gòu)，并允許節(jié)點(diǎn)自身決定是否進(jìn)行請求處理或轉(zhuǎn)發(fā)，相當(dāng)于讓請求流動起來。

?

模式的實(shí)現(xiàn)

職責(zé)鏈模式的實(shí)現(xiàn)代碼如下：

public class ChainOfResponsibilityPattern {public static void main(String[] args) {//組裝責(zé)任鏈Handler handler1 = new ConcreteHandler1();Handler handler2 = new ConcreteHandler2();handler1.setNext(handler2);//提交請求handler1.handleRequest("two");} } //抽象處理者角色 abstract class Handler {private Handler next;public void setNext(Handler next) {this.next = next;}public Handler getNext() {return next;}//處理請求的方法public abstract void handleRequest(String request); } //具體處理者角色1 class ConcreteHandler1 extends Handler {public void handleRequest(String request) {if (request.equals("one")) {System.out.println("具體處理者1負(fù)責(zé)處理該請求！");} else {if (getNext() != null) {getNext().handleRequest(request);} else {System.out.println("沒有人處理該請求！");}}} } //具體處理者角色2 class ConcreteHandler2 extends Handler {public void handleRequest(String request) {if (request.equals("two")) {System.out.println("具體處理者2負(fù)責(zé)處理該請求！");} else {if (getNext() != null) {getNext().handleRequest(request);} else {System.out.println("沒有人處理該請求！");}}} } /* 程序運(yùn)行結(jié)果如下： 具體處理者2負(fù)責(zé)處理該請求！ *//* 在上面代碼中，我們把消息硬編碼為 String 類型，而在真實(shí)業(yè)務(wù)中，消息是具備多樣性的，可以是 int、String 或者自定義類型。因此，在上面代碼的基礎(chǔ)上，可以對消息類型進(jìn)行抽象 Request，增強(qiáng)了消息的兼容性。*/

總結(jié)

我們常用的六個設(shè)計模式就講完了，可能有寫的不好的地方，希望大家多多包涵，也希望能對大家有一定的幫助。

?

總結(jié)

以上是生活随笔為你收集整理的设计模式之责任链模式（职责链模式）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。