设计模式:如何优雅地使用责任链模式

责任链模式(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)若是之后增添新的邮件类型、删除某一种邮件类型,或者有其他新功能的拓展,都必须修改源代码并举行严酷测试,违反了“开闭原则”。

开放-关闭原则:类应该对扩展开放,对修改关闭。

花了一个月的时间在一个oj网站只刷了这些题,从此入门了绝大多数算法

三、使用责任链模式

若何举行改善呢?那就是使用责任链模式,为某个请求确立一个工具链。每个工具根据顺序检查这个请求,并对其处置,或者将它通报给链中的下一个工具。在本例中,当收到电子邮件的时刻,先进入第一个处置器SpamHandler,若是SpamHandler无法处置,就将它传给FanHandler,以此类推…

本例使用责任链模式的结构图如图所示:
设计模式:如何优雅地使用责任链模式

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应用开发中确立一个过滤器链来对请求数据举行过滤,在事情流系统中实现公牍的分级审批等等,使用责任链模式可以较好地解决此类问题。

原创文章,作者:2d28新闻网,如若转载,请注明出处:https://www.2d28.com/archives/25654.html