了解23种设计模式之职责链模式

    技术2022-07-10  89

    了解23种设计模式之职责链模式

    什么是职责链模式职责链模式结构职责链模式实现模式的应用场景模式的扩展

    什么是职责链模式

    在现实生活中,常常会出现这样的事例: 一个请求多个对象可以处理,但每个对象的处理条件和权限不同。例如,公司员工请假,可批假的领导只有部分负责人,经理,总经理等,但每个领导能批准的天数不同,员工必须根据自己要请假的天数去找不同的领导签名,也就是说员工必须记住每个领导的姓名、电话和地址等信息,这增加了难度。这样的例子还有很多。

    在计算机软硬件中也有相关例子,如总线网中数据报传送,每台计算机根据目标地址是否同自己的地址相同来决定是否接收;还有异常处理中,处理程序根据异常的类型决定自己是否处理该异常;还有 Struts2 的拦截器、JSP和 Servlet的 Filter等,所有这些,如果用责任链模式都能很好解决

    责任链模式(Chain of Responsibility):为了避免请求发送者与多个请求处理者耦合在一起,将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链;当有请求发生时,可将请求沿着这条链传递,直到有对象处理它为止。

    注意:责任链模式也叫职责链模式。

    在责任链模式(Chain of Responsibility)中,客户只需要将请求发送到责任链上即可,无须关心请求的处理细节和请求的传递过程,所以责任链将请求的发送者和请求的处理者解耦了。

    责任链模式是一种对象行为型模式,其主要优点如下。 1,降低了对象之间的耦合度。该模式使得一个对象无须知道到底是哪一个对象处理其请求以及链的结构,发送者和接收者也无须拥有对方的明确信息。 2,增强了系统的可扩展性。可以根据需要增加新的请求处理类,满足开闭原则。 3,增强了给对象指派职责的灵活性。当工作流程发生变化,可以动态地改变链内的成员或者调动它们的次序,也可动态地新增或者删除责任。 4,责任链简化了对象之间的连接。每个对象只需保持一个指向其后继者的引用,不需保持其他所有处理者的引用,这避免了使用众多的 if 或者 if···else 语句。,5,责任分担。每个类只需要处理自己该处理的工作,不该处理的传递给下一个对象完成,明确各类的责任范围,符合类的单一职责原则。

    其主要缺点如下。 1,不能保证每个请求一定被处理。由于一个请求没有明确的接收者,所以不能保证它一定会被处理,该请求可能一直传到链的末端都得不到处理。 2,对比较长的职责链,请求的处理可能涉及多个处理对象,系统性能将受到一定影响。 3,职责链建立的合理性要靠客户端来保证,增加了客户端的复杂性,可能会由于职责链的错误设置而导致系统出错,如可能会造成循环调用。

    职责链模式结构

    职责链模式主要包含以下角色。 1,抽象处理者(Handler)角色:定义一个处理请求的接口,包含抽象处理方法和一个后继连接。 2,具体处理者(Concrete Handler)角色:实现抽象处理者的处理方法,判断能否处理本次请求,如果可以处理请求则处理,否则将该请求转给它的后继者。 3,客户类(Client)角色:创建处理链,并向链头的具体处理者对象提交请求,它不关心处理细节和请求的传递过程。

    结构图如下:

    职责链模式实现

    为了更好的理解模式的意义。我们先看一个例子: 我们申请请假加薪的流程,不用职责链模式实现。

    /** * @ClassName Request * @Description 申请 * @Version 1.0 **/ public class Request { //申请类别 private String requestTyep; //申请内容 private String RequestContext; //申请数量 private int number; public Request(String requestTyep, String requestContext, int number) { this.requestTyep = requestTyep; RequestContext = requestContext; this.number = number; } public String getRequestTyep() { return requestTyep; } public void setRequestTyep(String requestTyep) { this.requestTyep = requestTyep; } public String getRequestContext() { return RequestContext; } public void setRequestContext(String requestContext) { RequestContext = requestContext; } public int getNumber() { return number; } public void setNumber(int number) { this.number = number; } } /** * @ClassName Manager * @Description TODO * @Version 1.0 **/ public class Manager { protected String name; public Manager(String name) { this.name = name; } /** * @Description: 得到结果 * @param: [managerLevel, request] * @return: void * @Author: wuchao * @Date: 2020/6/30 21:29 **/ public void getResult(String managerLevel, Request request) { //判断职位 if(managerLevel.equals("经理")){ //判断事件类型:请假 ,请假天数。 if (request.getRequestTyep().equals("请假") && request.getNumber()<=2){ System.out.println("事由:【"+request.getRequestTyep()+"】"+"事由内容:【"+request.getRequestContext()+"】" + "天数:【"+request.getNumber()+"】"); System.out.println(name+managerLevel+"说被批准"); }else { System.out.println("事由:【"+request.getRequestTyep()+"】"+"事由内容:【"+request.getRequestContext()+"】" + "天数:【"+request.getNumber()+"】"); System.out.println(name+managerLevel+"说我无权批准"); } }else if(managerLevel.equals("总监")){ //判断事件类型:请假 ,请假天数。 if (request.getRequestTyep().equals("请假") && request.getNumber()<=5){ System.out.println("事由:【"+request.getRequestTyep()+"】"+"事由内容:【"+request.getRequestContext()+"】" + "天数:【"+request.getNumber()+"】"); System.out.println(name+managerLevel+"说被批准"); }else { System.out.println("事由:【"+request.getRequestTyep()+"】"+"事由内容:【"+request.getRequestContext()+"】" + "天数:【"+request.getNumber()+"】"); System.out.println(name+managerLevel+"说我无权批准"); } }else if(managerLevel.equals("总经理")){ //判断事件类型:请假,加薪 ,请假天数。 if (request.getRequestTyep().equals("请假") ){ System.out.println("事由:【"+request.getRequestTyep()+"】"+"事由内容:【"+request.getRequestContext()+"】" + "天数:【"+request.getNumber()+"】"); System.out.println(name+managerLevel+"说被批准"); }else if(request.getRequestTyep().equals("加薪")&& request.getNumber()<=1000){ System.out.println("事由:【"+request.getRequestTyep()+"】"+"事由内容:【"+request.getRequestContext()+"】" + "加薪:【"+request.getNumber()+"】"); System.out.println(name+managerLevel+"说被批准"); }else if(request.getRequestTyep().equals("加薪")&& request.getNumber()>2000){ System.out.println(name+managerLevel+"说公司还需要考察考察你!!!"); System.out.println(name+managerLevel+"说不批准"); } } } } public class MainClass { public static void main(String[] args) { //请假, 天数3天 //Request request = new Request("请假","生病了,感冒",3); //Request request = new Request("加薪","升职加薪",1000); Request request = new Request("加薪","升职加薪",3000); //管理者 String name = "老王"; Manager manager = new Manager(name); //String managerLevel = "经理"; //String managerLevel = "总监"; String managerLevel = "总经理"; manager.getResult(managerLevel,request); } }

    这样实现来看, 类有太多的责任,这违背了单一职责原则,增加新的管理类别,需要修改这个类,违背了开闭原则。

    职责链模式实现

    public abstract class Handler { protected Handler handler; /** * 处理请求 */ public abstract void handleRequest(int request); /** * 设置继任者 * @param handler */ public void setHandler(Handler handler) { this.handler = handler; } } /** * @ClassName ConcreteHandler1 * @Description 具体的处理类,处理它所负责的请求,可访问它的后继任者,如果可处理该请求,就处理之,否则就将该请求转发给它的继任者 * @Version 1.0 **/ public class ConcreteHandler1 extends Handler{ @Override public void handleRequest(int request) { if(request>=0 && request<10){ System.out.println("具体处理者1负责处理该请求"); }else if(handler !=null){ //转发给它的继任者,也就是 ConcreteHandler2 handler.handleRequest(request); }else{ System.out.println("没有人处理请求"); } } } /** * @ClassName ConcreteHandler2 * @Description TODO * @Version 1.0 **/ public class ConcreteHandler2 extends Handler{ @Override public void handleRequest(int request) { if(request>=20 && request<30){ System.out.println("具体处理者2负责处理该请求"); }else if(handler !=null){ handler.handleRequest(request); }else{ System.out.println("没有人处理请求"); } } } public class MainClass { public static void main(String[] args) { Handler handler = new ConcreteHandler1(); Handler handler2 = new ConcreteHandler2(); //设置职责链上家与下家 handler.setHandler(handler2); int[] result = {2,5,12,22,18,27,20}; for (int i = 0; i < result.length; ++i) { handler.handleRequest(result[i]); } } }

    当客户提交一个请求时,请求是沿链传递直至有一个ConcreteHandler 对象负责处理它的。 这样做的好处是不是说请求者不用管哪个对象来处理,反正该请求会被处理就对了?是的,这就使得接收者和发送者都没有对方的明确信息,且链中的对象自己也并不知道链的结构。结果是职责链可简化对象的相互连接,它们仅需保持一个指向其后继者的引用,这样也就大大降低了耦合度。

    模式的应用场景

    前边已经讲述了关于责任链模式的结构与特点,下面介绍其应用场景,责任链模式通常在以下几种情况使用。 1,有多个对象可以处理一个请求,哪个对象处理该请求由运行时刻自动确定。 2,可动态指定一组对象处理请求,或添加新的处理者。 3,在不明确指定请求处理者的情况下,向多个处理者中的一个提交请求。

    模式的扩展

    职责链模式存在以下两种情况。 1,纯的职责链模式:一个请求必须被某一个处理者对象所接收,且一个具体处理者对某个请求的处理只能采用以下两种行为之一:自己处理(承担责任);把责任推给下家处理。 2,不纯的职责链模式:允许出现某一个具体处理者对象在承担了请求的一部分责任后又将剩余的责任传给下家的情况,且一个请求可以最终不被任何接收端对象所接收。

    Processed: 0.043, SQL: 9