設計模式：如何優雅地使用責任鏈模式

James_Shangguan發表於2020-07-25
設計模式

責任鏈模式（Chain of Responsibility Pattern）在《Head First設計模式》一書中被稱為“剩下的模式”，其實使用也是蠻多的。最近在學習Netty的過程中用到了責任鏈模式，在此反過頭來重溫一下責任鏈模式。

當你想要讓一個以上的物件有機會能夠處理某個請求的時候，就使用責任鏈模式。

一、場景

借用《Head First設計模式》書中的典型場景：需要處理四種型別的電子郵件，第一種型別是粉絲寄來的信，表示他們喜歡新推出的遊戲；第二種型別是父母寄來的信，他們抱怨孩子總是沉迷遊戲而忘記做作業；第三種型別是店家希望在其他地方也擺放糖果機；第四種型別是垃圾郵件。現在已經可以根據郵件內容確定收到的郵件屬於哪種型別，需要設計一個程式來處理這些郵件。

Talk is cheap. Show me the code.直接用程式碼來說話吧。

用列舉來定義四種型別的郵件：

public enum EmailEnum {
    SPAM_EMAIL(1, "Spam_Email"),
    FAN_EMAIL(2, "Fan_Email"),
    COMPLAINT_EMAIL(3, "Complaint_Email"),
    NEW_LOC_EMAIL(4, "New_Loc_Email");

    private Integer code;
    private String desc;

    EmailEnum(Integer code, String desc) {
        this.code = code;
        this.desc = desc;
    }

    public Integer getCode() {
        return code;
    }

    public String getDesc() {
        return desc;
    }
}

假設郵件有兩個屬性：郵件型別和郵件內容，定義郵件：

public class Email {
    int type;
    String content;

    public Email(int type, String content) {
        this.type = type;
        this.content = content;
    }

    public int getType() {
        return type;
    }

    public String getContent() {
        return content;
    }
}

二、不使用責任鏈模式

如果不採用責任鏈模式？使用EmailHandler這個類來統一處理上述四種郵件，程式是這樣子的：

public class EmailHandler {

    public void handleEmai(Email email) {
        if (EmailEnum.SPAM_EMAIL.getCode().equals(email.getType())) {
            // 處理垃圾郵件
            handleSpamEmail(email);
        } else if (EmailEnum.FAN_EMAIL.getCode().equals(email.getType())) {
            // 處理粉絲郵件
            handleFanEmail(email);
        } else if (EmailEnum.COMPLAINT_EMAIL.getCode().equals(email.getType())) {
            // 處理抱怨郵件
            handleComplaintEmail(email);
        } else {
            // 處理新增郵件
            handleNewLocEmail(email);
        }
    }

    private void handleNewLocEmail(Email email) {
        System.out.println("handleNewLocEmail...");
        // 處理程式碼省略
    }

    private void handleComplaintEmail(Email email) {
        System.out.println("handleComplaintEmail...");
        // 處理程式碼省略
    }

    private void handleFanEmail(Email email) {
        System.out.println("handleFanEmail...");
        // 處理程式碼省略
    }

    public void handleSpamEmail(Email email) {
        System.out.println("handleSpamEmail...");
        // 處理程式碼省略
    }
}

這個類雖然強大，但是是不夠優雅的：

(1)EmailHandler類較為龐大，各種型別郵件的處理都集中在一個類中，違反了“單一職責原則”。

(2)如果之後增加新的郵件型別、刪除某一種郵件型別，或者有其他新功能的擴充，都必須修改原始碼並進行嚴格測試，違反了“開閉原則”。

開放-關閉原則：類應該對擴充套件開放，對修改關閉。

三、使用責任鏈模式

如何進行改進呢？那就是使用責任鏈模式，為某個請求建立一個物件鏈。每個物件按照順序檢查這個請求，並對其處理，或者將它傳遞給鏈中的下一個物件。在本例中，當收到電子郵件的時候，先進入第一個處理器SpamHandler，如果SpamHandler無法處理，就將它傳給FanHandler，以此類推...

本例使用責任鏈模式的結構圖如圖所示：
UML 類圖

Handler是一個抽象的處理器，是一個抽象類。抽象類中定義了一個抽象處理器的物件successor，通過該引用，可以形成一條責任鏈。抽象類中還定義了抽象處理請求的的方法handleRequest()。程式碼如下：

public abstract class Handler {
    protected Handler successor;

    public void setSuccessor(Handler successor) {
        this.successor = successor;
    }

    public abstract void handleRequest(Email email);
}

SpamHandler、FanHandler、ComplaintHandler和NewLocHandler是具體的處理器，繼承抽象類Handler，用來處理具體的郵件請求。處理細節：處理之前要進行型別的判斷，看是否能夠處理該請求，如果可以處理就處理，否則就轉發給後繼的處理器去處理。程式碼如下：

SpamHandler

public class SpamHandler extends Handler{
    @Override
    public void handleRequest(Email email) {
        if (EmailEnum.SPAM_EMAIL.getCode().equals(email.getType())) {
            //處理請求
            System.out.println("SpamHandler handleRequest...");
        }
        else {
            this.successor.handleRequest(email);  //轉發請求
        }
    }
}

FanHandler

public class FanHandler extends Handler{
    @Override
    public void handleRequest(Email email) {
        if (EmailEnum.FAN_EMAIL.getCode().equals(email.getType())) {
            //處理請求
            System.out.println("FanHandler handleRequest...");
        }
        else {
            this.successor.handleRequest(email);  //轉發請求
        }
    }
}

ComplaintHandler

public class ComplaintHandler extends Handler{
    @Override
    public void handleRequest(Email email) {
        if (EmailEnum.COMPLAINT_EMAIL.getCode().equals(email.getType())) {
            //處理請求
            System.out.println("ComplaintHandler handleRequest...");
        }
        else {
            this.successor.handleRequest(email);  //轉發請求
        }
    }
}

NewLocHandler

public class NewLocHandler extends Handler{
    @Override
    public void handleRequest(Email email) {
        if (EmailEnum.NEW_LOC_EMAIL.getCode().equals(email.getType())) {
            //處理請求
            System.out.println("NewLocHandler handleRequest...");
        }
        else {
            this.successor.handleRequest(email);  //轉發請求
        }
    }
}

需要注意的是，責任鏈模式並不建立責任鏈，責任鏈的建立工作必須由系統的其他部分來完成，一般是在使用該責任鏈的客戶端中建立責任鏈。責任鏈模式降低了請求的傳送端和接收端之間的耦合，使多個物件都有機會處理這個請求。下面編寫測試類進行測試：

public class Test {
    public static void main(String[] args) {
        // 建立郵件處理請求
        Email email1 = new Email(1,"aaa");
        Email email2 = new Email(2,"bbb");
        Email email3 = new Email(3,"ccc");
        Email email4 = new Email(4,"ddd");
        // 建立Handler
        SpamHandler handler1 = new SpamHandler();
        FanHandler handler2 = new FanHandler();
        ComplaintHandler handler3 = new ComplaintHandler();
        NewLocHandler handler4 = new NewLocHandler();
        // 建立責任鏈
        handler1.setSuccessor(handler2);
        handler2.setSuccessor(handler3);
        handler3.setSuccessor(handler4);
        // 處理請求
        handler1.handleRequest(email1);
        handler1.handleRequest(email2);
        handler1.handleRequest(email3);
        handler1.handleRequest(email4);
    }
}

在程式碼中建立四種型別的郵件用於處理，建立了四種不同的處理器（SpamHandler、FanHandler、ComplaintHandler、NewLocHandler），形成“handler1 -> handler2 -> handler3 -> handler4”的責任鏈，使用這條責任鏈處理四種型別的郵件。執行結構如下：

這樣處理之後，明顯使得請求傳送者和接受者解耦；每個實現類都有自己明確且獨一無二的職責；如果增加一個型別，只需要再增加一個具體類去繼承Handler，書寫自己的處理邏輯，在責任鏈中進行新增；如果刪除某種型別的，只需要在構建責任鏈的時候，把它刪除就可以了，實現動態增加或者刪除責任，符合設計模式的原則。

四、總結

責任鏈模式通過建立一條鏈來組織請求的處理者，請求將沿著鏈進行傳遞，請求傳送者無須知道請求在何時、何處以及如何被處理，實現了請求傳送者與處理者的解耦。在軟體開發中，如果遇到有多個物件可以處理同一請求時可以應用責任鏈模式，例如在Web應用開發中建立一個過濾器鏈來對請求資料進行過濾，在工作流系統中實現公文的分級審批等等，使用責任鏈模式可以較好地解決此類問題。

相關文章