中文字幕av专区_日韩电影在线播放_精品国产精品久久一区免费式_av在线免费观看网站

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

我的Java設計模式-責任鏈模式

發布時間:2020-06-18 05:03:41 來源:網絡 閱讀:8046 作者:Jet啟思 欄目:移動開發

今天來說說程序員小猿和產品就關于需求發生的故事。前不久,小猿收到了產品的需求。

產品經理:小猿,為了迎合大眾屌絲用戶的口味,我們要放一張圖,要露點的。

小猿:......露點?你大爺的,讓身為正義與純潔化身的我做這種需求,還露點。

產品經理:誤會誤會,是放一張暴露一點點的,尺寸不大。

小猿:尼瑪~能說清楚些嗎,需求模棱兩可的。不干,我要上報boss。

產品經理也一陣無語,這豆丁的事還上報boss。話說這上報也得走程序是吧,技術經理就不干了,“憑什么要跳過我,得經過我才能到boss”。咦~這一層一層上報就涉及到這次的責任鏈模式

一、責任鏈模式

定義

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

特點

1)接收請求的對象連接成一條鏈,對象之間存在層級關系。

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

UML

我的Java設計模式-責任鏈模式

責任鏈模式涉及到的角色如下所示:

??- 抽象處理者角色:定義了處理請求的接口或者抽象類,提供了處理請求的的方法和設置下一個處理者的方法。

??- 具體處理者角色:實現或者繼承抽象這角色,具體邏輯根據實際的架構來定,后面會提到。

二、實戰

先來看抽象處理者角色代碼:

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;
    }

    // 抽象方法,子類實現
    public abstract void report(Demand demand);
}

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

下面是具體處理者角色,繼承抽象處理者角色,在我們情景中有兩個具體處理者,分別是技術經理和boss。

// 技術經理
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方法,實現各自的業務邏輯,這都歸功于父類中handleMessage這個方法。

兩個角色都定義好了,來看客戶端如何實現:

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:你們打一架吧,打贏的做決定

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

三、擴展

責任鏈+模板方法

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

這樣結合模板方法模式的好處在哪?首先加了handleMessage方法,把請求的傳遞判斷從子類中剝離出來,讓子類在report方法中專心處理請求的業務邏輯,做到了單一職責原則。再者是子類的實現變得簡單了,不需要進行傳遞的判斷,非常有利于快速擴展。

責任鏈模式VS觀察者模式

觀察者模式我在之前有些過,不了解的可以先看看。責任鏈模式和觀察者模式存在一個共同點,就是傳遞責任鏈模式是一級一級的傳遞,形成一條鏈,鏈節點(處理者)之間是存在傳遞關系的。而觀察者模式的被觀察者向觀察者們的傳遞,并不是具體觀察者之間的傳遞,觀察者之間是不存在關聯的。拿小猿的經歷來說,在責任鏈模式中是請求從技術經理到boss,有層級關系,而對于觀察者模式是從被觀察者小猿發出,作為觀察者的技術經理和boss都會收到小猿的通知,是擴散式的,技術經理和boss并沒有層級關系。這是責任鏈模式和觀察者模式的區別,也是責任鏈模式的核心。

四、責任鏈模式的優缺點

優點

1)降低耦合度:客戶端不需要知道請求由哪個處理者處理,而處理者也不需要知道處理者之間的傳遞關系,由系統靈活的組織和分配。

2)良好的擴展性:增加處理者的實現很簡單,只需重寫處理請求業務邏輯的方法。

缺點

1)請求會從鏈頭發出,直到有處理者響應,在責任鏈比較長的時候會影響系統性能。

2)請求遞歸,調試排錯比較麻煩。

總結

責任鏈模式在實際項目中可以用到的地方還是比較多的,比如會員等級系統,會員等級之間構成一條鏈,用戶發起一個請求,系統只要把請求分發到責任鏈模式的入口,直到傳遞到與用戶會員匹配的等級,這樣各個會員等級的業務邏輯就會變成很清晰。這篇折騰了很久,主要是想把責任鏈的核心闡述清楚,讓大家能夠容易理解,也讓我重新思考了責任鏈模式的核心。下一篇是“還沒想好”,您的點贊和關注是我的動力哦,再會!

設計模式Java源碼GitHub下載https://github.com/jetLee92/DesignPattern


向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

喀什市| 兴义市| 永登县| 丹东市| 淮滨县| 长海县| 东光县| 温宿县| 黄石市| 扎鲁特旗| 工布江达县| 松滋市| 荃湾区| 常宁市| 黎平县| 临城县| 仙桃市| 固始县| 凤凰县| 乳山市| 诸城市| 南充市| 陕西省| 罗江县| 台山市| 衡山县| 浮山县| 旬阳县| 临湘市| 同江市| 霸州市| 托克逊县| 安西县| 霍邱县| 台北县| 遵义县| 项城市| 巴林左旗| 当涂县| 竹北市| 化州市|