java实现责任链模式_我的Java设计模式-责任链模式
今天來(lái)說(shuō)說(shuō)程序員小猿和產(chǎn)品就關(guān)于需求發(fā)生的故事。前不久，小猿收到了產(chǎn)品的需求。
產(chǎn)品經(jīng)理：小猿，為了迎合大眾屌絲用戶(hù)的口味，我們要放一張圖，要露點(diǎn)的。
小猿：......露點(diǎn)？你大爺?shù)?#xff0c;讓身為正義與純潔化身的我做這種需求，還露點(diǎn)。
產(chǎn)品經(jīng)理：誤會(huì)誤會(huì)，是放一張暴露一點(diǎn)點(diǎn)的，尺寸不大。
小猿：尼瑪~能說(shuō)清楚些嗎，需求模棱兩可的。不干，我要上報(bào)boss。
產(chǎn)品經(jīng)理也一陣無(wú)語(yǔ)，這豆丁的事還上報(bào)boss。話(huà)說(shuō)這上報(bào)也得走程序是吧，技術(shù)經(jīng)理就不干了，“憑什么要跳過(guò)我，得經(jīng)過(guò)我才能到boss”。咦~這一層一層上報(bào)就涉及到這次的責(zé)任鏈模式。
一、責(zé)任鏈模式
定義
創(chuàng)建多個(gè)對(duì)象，使這些對(duì)象形成一條鏈，并沿著這條鏈傳遞請(qǐng)求，直到鏈上的某一個(gè)對(duì)象決定處理此請(qǐng)求。
特點(diǎn)
1)接收請(qǐng)求的對(duì)象連接成一條鏈，對(duì)象之間存在層級(jí)關(guān)系。
2)這些對(duì)象可處理請(qǐng)求，也可傳遞請(qǐng)求，直到有對(duì)象處理該請(qǐng)求。
UML
責(zé)任鏈模式涉及到的角色如下所示：
- 抽象處理者角色：定義了處理請(qǐng)求的接口或者抽象類(lèi)，提供了處理請(qǐng)求的的方法和設(shè)置下一個(gè)處理者的方法。
- 具體處理者角色：實(shí)現(xiàn)或者繼承抽象這角色，具體邏輯根據(jù)實(shí)際的架構(gòu)來(lái)定，后面會(huì)提到。
二、實(shí)戰(zhàn)
先來(lái)看抽象處理者角色代碼：
public abstract class Handler {
private Handler nextHandler;
private int level;
public Handler(int level) {
this.level = level;
}
// 處理請(qǐng)求傳遞，注意final，子類(lèi)不可重寫(xiě)
public final void handleMessage(Demand demand) {
if (level == demand.demandLevel()) {
this.report(demand);
} else {
if (this.nextHandler != null) {
System.out.println("事情太嚴(yán)重，需報(bào)告上一級(jí)");
this.nextHandler.handleMessage(demand);
} else {
System.out.println("我就是boss，沒(méi)有上頭");
}
}
}
public void setNextHandler(Handler handler) {
this.nextHandler = handler;
}
// 抽象方法，子類(lèi)實(shí)現(xiàn)
public abstract void report(Demand demand);
}
在抽象處理者角色定義了處理請(qǐng)求的抽象方法，以及下一級(jí)傳遞的對(duì)象方法，重點(diǎn)在handleMessage處理請(qǐng)求傳遞的方法，下面會(huì)解釋為什么要這樣寫(xiě)，繼續(xù)往下看。
下面是具體處理者角色，繼承抽象處理者角色，在我們情景中有兩個(gè)具體處理者，分別是技術(shù)經(jīng)理和boss。
// 技術(shù)經(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() + "：小猿我挺你，這個(gè)需求不干");
}
}
// 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() + "：你們打一架吧，打贏的做決定");
}
}
可以看到具體處理者的代碼很簡(jiǎn)潔，重寫(xiě)了report方法，實(shí)現(xiàn)各自的業(yè)務(wù)邏輯，這都?xì)w功于父類(lèi)中handleMessage這個(gè)方法。
兩個(gè)角色都定義好了，來(lái)看客戶(hù)端如何實(shí)現(xiàn)：
public class Client {
public static void main(String[] args) {
Demand demandA = new DemandA(); // 請(qǐng)求等級(jí)低
Demand demandB = new DemandB(); // 請(qǐng)求等級(jí)高
Boss boss = new Boss();
TechnicalManager technicalManager = new TechnicalManager();
technicalManager.setNextHandler(boss); // 設(shè)置下一級(jí)
technicalManager.handleMessage(demandA);
System.out.println("============================");
technicalManager.handleMessage(demandB);
}
}
可以看到在客戶(hù)端中的重點(diǎn)是設(shè)置下一級(jí)的處理者，這樣多個(gè)處理者對(duì)象就會(huì)形成一條鏈。運(yùn)行客戶(hù)端，結(jié)果如下：
需求：加一張露一點(diǎn)點(diǎn)的圖
TechnicalManager：小猿我挺你，這個(gè)需求不干
============================
需求：加一張露一點(diǎn)點(diǎn)的圖
TechnicalManager：事情太嚴(yán)重，需報(bào)告上一級(jí)
Boss：你們打一架吧，打贏的做決定
從結(jié)果可以看到，級(jí)別低的請(qǐng)求技術(shù)經(jīng)理自己處理，級(jí)別高的傳遞給了下一級(jí)的Boss，這樣就形成一條鏈，而這也是責(zé)任鏈的核心所在。注意，在請(qǐng)求的傳遞過(guò)程中，請(qǐng)求是不會(huì)發(fā)生變化的。需求不會(huì)從“加一張露一點(diǎn)點(diǎn)的圖”變成了“加一張露點(diǎn)的圖”，這等著boss請(qǐng)到辦公室喝茶吧。
三、擴(kuò)展
責(zé)任鏈+模板方法
回頭看看上面的代碼，抽象類(lèi)中定義了幾個(gè)方法，一個(gè)是final修飾的handleMessage，一個(gè)是抽象方法report，還有一個(gè)是setNextHandler。這剛好是模板方法模式中的三個(gè)基本方法，分別是具體方法(抽象類(lèi)聲明并實(shí)現(xiàn)，子類(lèi)不實(shí)現(xiàn))、抽象方法(抽象類(lèi)聲明，子類(lèi)必須實(shí)現(xiàn))、鉤子方法(抽象類(lèi)聲明并實(shí)現(xiàn)，子類(lèi)可擴(kuò)展)。handleMessage方法加了final修飾，子類(lèi)不可重寫(xiě)，而handleMessage正是把傳遞請(qǐng)求工作交給父類(lèi)Handler，子類(lèi)不需要處理傳遞的工作。而report則是抽象方法，子類(lèi)必須重寫(xiě)該方法，子類(lèi)處理請(qǐng)求的業(yè)務(wù)邏輯。setNextHandler是鉤子方法，在這里我們并沒(méi)有實(shí)現(xiàn)。
這樣結(jié)合模板方法模式的好處在哪？首先加了handleMessage方法，把請(qǐng)求的傳遞判斷從子類(lèi)中剝離出來(lái)，讓子類(lèi)在report方法中專(zhuān)心處理請(qǐng)求的業(yè)務(wù)邏輯，做到了單一職責(zé)原則。再者是子類(lèi)的實(shí)現(xiàn)變得簡(jiǎn)單了，不需要進(jìn)行傳遞的判斷，非常有利于快速擴(kuò)展。
責(zé)任鏈模式VS觀察者模式
觀察者模式我在之前有些過(guò)，不了解的可以先看看。責(zé)任鏈模式和觀察者模式存在一個(gè)共同點(diǎn)，就是傳遞責(zé)任鏈模式是一級(jí)一級(jí)的傳遞，形成一條鏈，鏈節(jié)點(diǎn)(處理者)之間是存在傳遞關(guān)系的。而觀察者模式的被觀察者向觀察者們的傳遞，并不是具體觀察者之間的傳遞，觀察者之間是不存在關(guān)聯(lián)的。拿小猿的經(jīng)歷來(lái)說(shuō)，在責(zé)任鏈模式中是請(qǐng)求從技術(shù)經(jīng)理到boss，有層級(jí)關(guān)系，而對(duì)于觀察者模式是從被觀察者小猿發(fā)出，作為觀察者的技術(shù)經(jīng)理和boss都會(huì)收到小猿的通知，是擴(kuò)散式的，技術(shù)經(jīng)理和boss并沒(méi)有層級(jí)關(guān)系。這是責(zé)任鏈模式和觀察者模式的區(qū)別，也是責(zé)任鏈模式的核心。
四、責(zé)任鏈模式的優(yōu)缺點(diǎn)
優(yōu)點(diǎn)
1)降低耦合度：客戶(hù)端不需要知道請(qǐng)求由哪個(gè)處理者處理，而處理者也不需要知道處理者之間的傳遞關(guān)系，由系統(tǒng)靈活的組織和分配。
2)良好的擴(kuò)展性：增加處理者的實(shí)現(xiàn)很簡(jiǎn)單，只需重寫(xiě)處理請(qǐng)求業(yè)務(wù)邏輯的方法。
缺點(diǎn)
1)請(qǐng)求會(huì)從鏈頭發(fā)出，直到有處理者響應(yīng)，在責(zé)任鏈比較長(zhǎng)的時(shí)候會(huì)影響系統(tǒng)性能。
2)請(qǐng)求遞歸，調(diào)試排錯(cuò)比較麻煩。
總結(jié)
責(zé)任鏈模式在實(shí)際項(xiàng)目中可以用到的地方還是比較多的，比如會(huì)員等級(jí)系統(tǒng)，會(huì)員等級(jí)之間構(gòu)成一條鏈，用戶(hù)發(fā)起一個(gè)請(qǐng)求，系統(tǒng)只要把請(qǐng)求分發(fā)到責(zé)任鏈模式的入口，直到傳遞到與用戶(hù)會(huì)員匹配的等級(jí)，這樣各個(gè)會(huì)員等級(jí)的業(yè)務(wù)邏輯就會(huì)變成很清晰。這篇折騰了很久，主要是想把責(zé)任鏈的核心闡述清楚，讓大家能夠容易理解，也讓我重新思考了責(zé)任鏈模式的核心。下一篇是“還沒(méi)想好”，您的點(diǎn)贊和關(guān)注是我的動(dòng)力哦，再會(huì)！
總結(jié)
以上是生活随笔為你收集整理的java实现责任链模式_我的Java设计模式-责任链模式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： java 整数加减_JAVA超大整数的加
- 下一篇： java选中一格_java-选中排序（新