如何理解Java設(shè)計(jì)模式責(zé)任鏈模式

本篇文章給大家分享的是有關(guān)如何理解Java設(shè)計(jì)模式責(zé)任鏈模式，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

一、責(zé)任鏈模式

定義

??創(chuàng)建多個對象，使這些對象形成一條鏈，并沿著這條鏈傳遞請求，直到鏈上的某一個對象決定處理此請求。

特點(diǎn)

1）接收請求的對象連接成一條鏈，對象之間存在層級關(guān)系。

2）這些對象可處理請求，也可傳遞請求，直到有對象處理該請求。

UML

責(zé)任鏈模式涉及到的角色如下所示：

??- 抽象處理者角色：定義了處理請求的接口或者抽象類，提供了處理請求的的方法和設(shè)置下一個處理者的方法。

??- 具體處理者角色：實(shí)現(xiàn)或者繼承抽象這角色，具體邏輯根據(jù)實(shí)際的架構(gòu)來定，后面會提到。

二、實(shí)戰(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("事情太嚴(yán)重，需報告上一級");

                this.nextHandler.handleMessage(demand);

            } else {

                System.out.println("我就是boss，沒有上頭");

            }

        }

    }

    public void setNextHandler(Handler handler) {

        this.nextHandler = handler;

    }

    // 抽象方法，子類實(shí)現(xiàn)

    public abstract void report(Demand demand);

}

在抽象處理者角色定義了處理請求的抽象方法，以及下一級傳遞的對象方法，重點(diǎn)在handleMessage處理請求傳遞的方法，下面會解釋為什么要這樣寫，繼續(xù)往下看。

下面是具體處理者角色，繼承抽象處理者角色，在我們情景中有兩個具體處理者，分別是技術(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() + "：小猿我挺你，這個需求不干");

    }

}

// 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方法，實(shí)現(xiàn)各自的業(yè)務(wù)邏輯，這都?xì)w功于父類中handleMessage這個方法。

兩個角色都定義好了，來看客戶端如何實(shí)現(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); // 設(shè)置下一級

        technicalManager.handleMessage(demandA);
        System.out.println("============================");
        technicalManager.handleMessage(demandB);
    }
}

可以看到在客戶端中的重點(diǎn)是設(shè)置下一級的處理者，這樣多個處理者對象就會形成一條鏈。運(yùn)行客戶端，結(jié)果如下：

需求：加一張露一點(diǎn)點(diǎn)的圖
TechnicalManager：小猿我挺你，這個需求不干

============================
需求：加一張露一點(diǎn)點(diǎn)的圖
TechnicalManager：事情太嚴(yán)重，需報告上一級
Boss：你們打一架吧，打贏的做決定

從結(jié)果可以看到，級別低的請求技術(shù)經(jīng)理自己處理，級別高的傳遞給了下一級的Boss，這樣就形成一條鏈，而這也是責(zé)任鏈的核心所在。注意，在請求的傳遞過程中，請求是不會發(fā)生變化的。需求不會從“加一張露一點(diǎn)點(diǎn)的圖”變成了“加一張露點(diǎn)的圖”，這等著boss請到辦公室喝茶吧。

三、擴(kuò)展

責(zé)任鏈+模板方法

回頭看看上面的代碼，抽象類中定義了幾個方法，一個是final修飾的handleMessage，一個是抽象方法report，還有一個是setNextHandler。這剛好是模板方法模式中的三個基本方法，分別是具體方法（抽象類聲明并實(shí)現(xiàn)，子類不實(shí)現(xiàn)）、抽象方法（抽象類聲明，子類必須實(shí)現(xiàn)）、鉤子方法（抽象類聲明并實(shí)現(xiàn)，子類可擴(kuò)展）。handleMessage方法加了final修飾，子類不可重寫，而handleMessage正是把傳遞請求工作交給父類Handler，子類不需要處理傳遞的工作。而report則是抽象方法，子類必須重寫該方法，子類處理請求的業(yè)務(wù)邏輯。setNextHandler是鉤子方法，在這里我們并沒有實(shí)現(xiàn)。

這樣結(jié)合模板方法模式的好處在哪？首先加了handleMessage方法，把請求的傳遞判斷從子類中剝離出來，讓子類在report方法中專心處理請求的業(yè)務(wù)邏輯，做到了單一職責(zé)原則。再者是子類的實(shí)現(xiàn)變得簡單了，不需要進(jìn)行傳遞的判斷，非常有利于快速擴(kuò)展。

責(zé)任鏈模式VS觀察者模式

觀察者模式我在之前有寫過，不了解的可以先看看。責(zé)任鏈模式和觀察者模式存在一個共同點(diǎn)，就是傳遞責(zé)任鏈模式是一級一級的傳遞，形成一條鏈，鏈節(jié)點(diǎn)（處理者）之間是存在傳遞關(guān)系的。而觀察者模式的被觀察者向觀察者們的傳遞，并不是具體觀察者之間的傳遞，觀察者之間是不存在關(guān)聯(lián)的。拿小猿的經(jīng)歷來說，在責(zé)任鏈模式中是請求從技術(shù)經(jīng)理到boss，有層級關(guān)系，而對于觀察者模式是從被觀察者小猿發(fā)出，作為觀察者的技術(shù)經(jīng)理和boss都會收到小猿的通知，是擴(kuò)散式的，技術(shù)經(jīng)理和boss并沒有層級關(guān)系。這是責(zé)任鏈模式和觀察者模式的區(qū)別，也是責(zé)任鏈模式的核心。

四、責(zé)任鏈模式的優(yōu)缺點(diǎn)

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

1）降低耦合度：客戶端不需要知道請求由哪個處理者處理，而處理者也不需要知道處理者之間的傳遞關(guān)系，由系統(tǒng)靈活的組織和分配。

2）良好的擴(kuò)展性：增加處理者的實(shí)現(xiàn)很簡單，只需重寫處理請求業(yè)務(wù)邏輯的方法。

缺點(diǎn)

1）請求會從鏈頭發(fā)出，直到有處理者響應(yīng)，在責(zé)任鏈比較長的時候會影響系統(tǒng)性能。

2）請求遞歸，調(diào)試排錯比較麻煩。

責(zé)任鏈模式在實(shí)際項(xiàng)目中可以用到的地方還是比較多的，比如會員等級系統(tǒng)，會員等級之間構(gòu)成一條鏈，用戶發(fā)起一個請求，系統(tǒng)只要把請求分發(fā)到責(zé)任鏈模式的入口，直到傳遞到與用戶會員匹配的等級，這樣各個會員等級的業(yè)務(wù)邏輯就會變成很清晰。這篇折騰了很久，主要是想把責(zé)任鏈的核心闡述清楚，讓大家能夠容易理解，也讓我重新思考了責(zé)任鏈模式的核心。下一篇是“還沒想好”，您的點(diǎn)贊和關(guān)注是我的動力哦，再會！

以上就是如何理解Java設(shè)計(jì)模式責(zé)任鏈模式，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。