摘要:咦這一層一層上報就涉及到這次的責任鏈模式。責任鏈模式和觀察者模式存在一個共同點,就是傳遞責任鏈模式是一級一級的傳遞,形成一條鏈,鏈節(jié)點處理者之間是存在傳遞關系的。這是責任鏈模式和觀察者模式的區(qū)別,也是責任鏈模式的核心。
今天來說說程序員小猿和產(chǎn)品就關于需求發(fā)生的故事。前不久,小猿收到了產(chǎn)品的需求。
產(chǎn)品經(jīng)理:小猿,為了迎合大眾屌絲用戶的口味,我們要放一張圖,要露點的。
小猿:......露點?你大爺?shù)?,讓身為正義與純潔化身的我做這種需求,還露點。
產(chǎn)品經(jīng)理:誤會誤會,是放一張暴露一點點的,尺寸不大。
小猿:尼瑪~能說清楚些嗎,需求模棱兩可的。不干,我要上報boss。
產(chǎn)品經(jīng)理也一陣無語,這豆丁的事還上報boss。話說這上報也得走程序是吧,技術經(jīng)理就不干了,“憑什么要跳過我,得經(jīng)過我才能到boss”。咦~這一層一層上報就涉及到這次的責任鏈模式。
一、責任鏈模式 定義??創(chuàng)建多個對象,使這些對象形成一條鏈,并沿著這條鏈傳遞請求,直到鏈上的某一個對象決定處理此請求。
特點1)接收請求的對象連接成一條鏈,對象之間存在層級關系。
2)這些對象可處理請求,也可傳遞請求,直到有對象處理該請求。
UML責任鏈模式涉及到的角色如下所示:
??- 抽象處理者角色:定義了處理請求的接口或者抽象類,提供了處理請求的的方法和設置下一個處理者的方法。
??- 具體處理者角色:實現(xiàn)或者繼承抽象這角色,具體邏輯根據(jù)實際的架構來定,后面會提到。
二、實戰(zhàn)先來看抽象處理者角色代碼:
public abstract class Handler { private Handler nextHandler; private int level; public Handler(int level) { this.level = level; } // 處理請求傳遞,注意final,子類不可重寫 public final void handleMessage(Demand demand) { if (level == demand.demandLevel()) { this.report(demand); } else { if (this.nextHandler != null) { System.out.println("事情太嚴重,需報告上一級"); this.nextHandler.handleMessage(demand); } else { System.out.println("我就是boss,沒有上頭"); } } } public void setNextHandler(Handler handler) { this.nextHandler = handler; } // 抽象方法,子類實現(xiàn) public abstract void report(Demand demand); }
在抽象處理者角色定義了處理請求的抽象方法,以及下一級傳遞的對象方法,重點在handleMessage處理請求傳遞的方法,下面會解釋為什么要這樣寫,繼續(xù)往下看。
下面是具體處理者角色,繼承抽象處理者角色,在我們情景中有兩個具體處理者,分別是技術經(jīng)理和boss。
// 技術經(jīng)理 public class TechnicalManager extends Handler { public TechnicalManager() { super(1); } @Override public void report(Demand demand) { System.out.println("需求:" + demand.detail()); System.out.println(getClass().getSimpleName() + ":小猿我挺你,這個需求不干"); } } // boss public class Boss extends Handler { public Boss() { super(2); } @Override public void report(Demand demand) { System.out.println("需求:" + demand.detail()); System.out.println(getClass().getSimpleName() + ":你們打一架吧,打贏的做決定"); } }
可以看到具體處理者的代碼很簡潔,重寫了report方法,實現(xiàn)各自的業(yè)務邏輯,這都歸功于父類中handleMessage這個方法。
兩個角色都定義好了,來看客戶端如何實現(xiàn):
public class Client { public static void main(String[] args) { Demand demandA = new DemandA(); // 請求等級低 Demand demandB = new DemandB(); // 請求等級高 Boss boss = new Boss(); TechnicalManager technicalManager = new TechnicalManager(); technicalManager.setNextHandler(boss); // 設置下一級 technicalManager.handleMessage(demandA); System.out.println("============================"); technicalManager.handleMessage(demandB); } }
可以看到在客戶端中的重點是設置下一級的處理者,這樣多個處理者對象就會形成一條鏈。運行客戶端,結果如下:
需求:加一張露一點點的圖
TechnicalManager:小猿我挺你,這個需求不干============================
需求:加一張露一點點的圖
TechnicalManager:事情太嚴重,需報告上一級
Boss:你們打一架吧,打贏的做決定
從結果可以看到,級別低的請求技術經(jīng)理自己處理,級別高的傳遞給了下一級的Boss,這樣就形成一條鏈,而這也是責任鏈的核心所在。注意,在請求的傳遞過程中,請求是不會發(fā)生變化的。需求不會從“加一張露一點點的圖”變成了“加一張露點的圖”,這等著boss請到辦公室喝茶吧。
三、擴展 責任鏈+模板方法回頭看看上面的代碼,抽象類中定義了幾個方法,一個是final修飾的handleMessage,一個是抽象方法report,還有一個是setNextHandler。這剛好是模板方法模式中的三個基本方法,分別是具體方法(抽象類聲明并實現(xiàn),子類不實現(xiàn))、抽象方法(抽象類聲明,子類必須實現(xiàn))、鉤子方法(抽象類聲明并實現(xiàn),子類可擴展)。handleMessage方法加了final修飾,子類不可重寫,而handleMessage正是把傳遞請求工作交給父類Handler,子類不需要處理傳遞的工作。而report則是抽象方法,子類必須重寫該方法,子類處理請求的業(yè)務邏輯。setNextHandler是鉤子方法,在這里我們并沒有實現(xiàn)。
這樣結合模板方法模式的好處在哪?首先加了handleMessage方法,把請求的傳遞判斷從子類中剝離出來,讓子類在report方法中專心處理請求的業(yè)務邏輯,做到了單一職責原則。再者是子類的實現(xiàn)變得簡單了,不需要進行傳遞的判斷,非常有利于快速擴展。
責任鏈模式VS觀察者模式觀察者模式我在之前有些過,不了解的可以先看看。責任鏈模式和觀察者模式存在一個共同點,就是傳遞責任鏈模式是一級一級的傳遞,形成一條鏈,鏈節(jié)點(處理者)之間是存在傳遞關系的。而觀察者模式的被觀察者向觀察者們的傳遞,并不是具體觀察者之間的傳遞,觀察者之間是不存在關聯(lián)的。拿小猿的經(jīng)歷來說,在責任鏈模式中是請求從技術經(jīng)理到boss,有層級關系,而對于觀察者模式是從被觀察者小猿發(fā)出,作為觀察者的技術經(jīng)理和boss都會收到小猿的通知,是擴散式的,技術經(jīng)理和boss并沒有層級關系。這是責任鏈模式和觀察者模式的區(qū)別,也是責任鏈模式的核心。
四、責任鏈模式的優(yōu)缺點 優(yōu)點1)降低耦合度:客戶端不需要知道請求由哪個處理者處理,而處理者也不需要知道處理者之間的傳遞關系,由系統(tǒng)靈活的組織和分配。
2)良好的擴展性:增加處理者的實現(xiàn)很簡單,只需重寫處理請求業(yè)務邏輯的方法。
缺點1)請求會從鏈頭發(fā)出,直到有處理者響應,在責任鏈比較長的時候會影響系統(tǒng)性能。
2)請求遞歸,調(diào)試排錯比較麻煩。
總結責任鏈模式在實際項目中可以用到的地方還是比較多的,比如會員等級系統(tǒng),會員等級之間構成一條鏈,用戶發(fā)起一個請求,系統(tǒng)只要把請求分發(fā)到責任鏈模式的入口,直到傳遞到與用戶會員匹配的等級,這樣各個會員等級的業(yè)務邏輯就會變成很清晰。這篇折騰了很久,主要是想把責任鏈的核心闡述清楚,讓大家能夠容易理解,也讓我重新思考了責任鏈模式的核心。下一篇是“還沒想好”,您的點贊和關注是我的動力哦,再會!
設計模式Java源碼GitHub下載:https://github.com/jetLee92/DesignPattern
文章版權歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/68037.html
摘要:責任鏈模式涉及到的角色如下所示抽象處理者角色定義一個處理請求的抽象類。如果一個類承擔了一部分責任,還將請求踢給下一個皮球,則被稱為不純的責任鏈模式。一般來說,日常開發(fā)中不純的責任鏈模式用的比較多一點。參考責任鏈模式更多文章 在閻宏博士的《JAVA與模式》一書中開頭是這樣描述責任鏈(Chain of Responsibility)模式的: 責任鏈模式是一種對象的行為模式。在責任鏈模式里,...
摘要:責任鏈模式的具體運用以及原理請參見筆者責任鏈模式改進方式引入適配器模式關于接口適配器模式原理以及使用場景請參見筆者適配器模式。 1 責任鏈模式現(xiàn)存缺點 由于責任鏈大多數(shù)都是不純的情況,本案例中,只要校驗失敗就直接返回,不繼續(xù)處理接下去責任鏈中的其他校驗邏輯了,故而出現(xiàn)如果某個部分邏輯是要由多個校驗器組成一個整理的校驗邏輯的話,則此責任鏈模式則顯現(xiàn)出了它的不足之處了。(責任鏈模式的具體運...
摘要:流程展示類圖設計為了實現(xiàn)上述場景,我們可以采用責任鏈設計模式。天,運行輸出審批拒絕總結責任鏈主要重在責任分離處理,讓各個節(jié)點各司其職。責任鏈比較長,調(diào)試時可能會比較麻煩。 責任鏈模式 概念描述 責任鏈,顧名思義,就是用來處理相關事務責任的一條執(zhí)行鏈,執(zhí)行鏈上有多個節(jié)點,每個節(jié)點都有機會(條件匹配)處理請求事務,如果某個節(jié)點處理完了就可以根據(jù)實際業(yè)務需求傳遞給下一個節(jié)點繼續(xù)處理或者返回處...
閱讀 1608·2021-09-23 11:21
閱讀 2367·2021-09-07 10:13
閱讀 850·2021-09-02 10:19
閱讀 1144·2019-08-30 15:44
閱讀 1738·2019-08-30 13:18
閱讀 1923·2019-08-30 11:15
閱讀 1121·2019-08-29 17:17
閱讀 2027·2019-08-29 15:31