这篇文章主要讲解了“什么是责任链模式”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“什么是责任链模式”吧!
10年积累的网站设计、网站建设经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先做网站后付款的网站建设流程,更有宁国免费网站建设让你可以放心的选择与我们合作。
面试经历大家肯定都有过,但是面试的流程其实跟一种设计模式很像,每一轮的面试官都有自己的职责,一个求职者面试经历的过程就好比一次客户端的请求过程。
在设计模式系列的文章中之前已经为大家分享了创建型设计模式,感兴趣的小伙伴们可以再去翻看之前的分享。接下来开始分享设计模式三大类型中的行为型模式了,今天要分享的是责任链模式
什么是责任链?它的原理是什么?
将请求的发送和接收解耦,让多个接收对象都有机会处理这个请求。将这些接收对象串成一条链,并沿着这条链传递这个请求,直到链上的某个接收对象能够处理它为止。
以上定义来自《设计模式之美》
再看看一张官方图解吧
Client(客户端):实例化一个处理器的链,在第一个链对象中调用handleRequest 方法。
Handle(处理器):抽象类,提供给实际处理器继承然后实现handleRequst方法,处理请求
ConcreteHandler(具体处理器):继承了handler的类,同时实现handleRequst方法,负责处理业务逻辑类,不同业务模块有不同的ConcreteHandler。
这么看结构其实还是比较简单的,但是我们还是拿面试的流程来模拟一下责任链吧!
假设现在去一家公司面试,第一次去一面,第二次去二面,第三次去直接过了。那这个模拟面试代码怎么写呢?
public abstract class Handler { protected Handler handler; public void setHandler(Handler handler) { this.handler = handler; } public abstract void handleRequest(Integer times); }
首先我们还是定义一个抽象Handler处理器,同时添加一个抽象处理方法 handleRequest,后面我只需要编写具体的处理器来继承Handler类
public class FirstInterview extends Handler { @Override public void handleRequest(Integer times) { // 条件判断是否是属于当前Handler的处理范围之内,不是则向下传递Handler处理器 if(times ==1){ // 假设这里是处理的业务逻辑代码 System.out.println("第一次面试"+times); } handler.handleRequest(times); } }
其次构建第一次面试Handler,内部实现handleRequest方法,判断一下是否是当前处理应该处理的业务逻辑,不是则向下传递。同样的第二次的SecondInterview和FirstInterview代码基本是一致的,我就不给大家贴出来了,直接看最后一个
public class ThreeInterview extends Handler { @Override public void handleRequest(Integer times) { if (times == 3) { System.out.println("第三次面试"+ times + ",恭喜面试通过,HR会跟你联 系!!!"); } } public static void main(String[] args) { Handler first = new FirstInterview(); Handler second = new SecondInterview(); Handler three = new ThreeInterview(); first.setHandler(second); second.setHandler(three); // 第一次面试 first.handleRequest(1); System.out.println(); // 第二次面试 first.handleRequest(2); System.out.println(); // 第三次面试 first.handleRequest(3); System.out.println(); } }
这个结果可以很明显的看出,根据我们传参,不同的Handler根据自己的职责处理着自己的业务,这就是责任链。
责任链在很多框架源码中也有体现。比如开始学SpringMVC中的 ServletFilter
以及Spring中的 SpringInterceptor 这里面其实都是运用了责任链模式的思想,达到框架的可扩展性的同时也遵循着开闭原则。
作为常见的RPC框架的DUBBO其实里面也同样有这个责任链的思想。
给大家一个思考问题?
dubbo服务一旦暴露出去了,那么基本任何服务都能调用,但是在一些特殊的业务中需要我们暴露服务,但是又不希望被不了解业务的人随便调用。
比如:商品的库存修改的dubbo服务,我们只允许下单,购物车,添加修改商品等一些指定场景可以调用。
那么有什么办法,在Provider这端做好拦截,针对特定的服务才允许调用,否则拦截下来不允许执行?
第一种方法,添加服务名称APP_NAME作为传参校验,这是很常见也最容易想到的办法。
第二种方法,实现一个DUBBO拦截器,对RPC调用进行选择性过滤。
针对上面的两种方法,给大家详细讲讲第二种方法具体怎么实现,每个公司都会基于现有的DUBBO源码做自己的特定化改动,那么第二种方式也是同样需要我们改动线有dubbo源码。
先修改ConsumerContextFilter消费者拦截器
这里我们以dubbo的2.7.19版本为例。在ConsumerContextFilter中添加APP_NAME至Attachments中,那么作为本次的RPC调用都能从Attachments中获取到我们塞入的值。
至于这个APP_NAME的获取 可以通过 System.getProperty("project.name", "") 来获取服务名
这里我就不对DUBBO做过多的展开,大家如果有强烈建议讲解。那么在结束设计模式再跟大家详细剖析一下dubbo,以及zookeeper里面的ZAB,一致性选举算法等等。
CONSUMER既然已经填充了服务名称,那么在Provider同样的也就只需要写一个ProviderFilter 就可以了
这里就基本实现怎么处理每一次RPC调用的拦截了,然后想要那个服务拦截,在provider里面的filter里面指定一下这个DubboProviderFilter就可以了,也可以全局都实现。
注意 :这个Filter 要是用DUBBO包里面的,不要搞错了。
框架中既然都有这种思想,那么怎么运用到业务代码中呢?
还是给大家举一个例子:
商品详情展示我们可以是分模块展示的,比如头图,商品信息,sku信息,配送地址,分期付费等等。
public abstract class AbstractDataHandler{ // 处理模块化数据 protected abstract T doRequest(String query) throws Exception; }
首先我们还是定一个抽象数据Handler,然后分别建立ItemInfoHandler 和SkuInfoHandler 来继承抽象处理器
@Component public class ItemInfoHandler extends AbstractDataHandler{ @Override protected ItemInfoHandler.ItemInfo doRequest(String query) { ItemInfoHandler.ItemInfo info = new ItemInfo(); info.setItemId(123456L); info.setItemName("测试商品"); return info; } @Data public static class ItemInfo { private Long itemId; private String itemName; } }
同样SkuInfoHandler类也是一样的
@Component public class SkuInfoHandler extends AbstractDataHandler{ @Override protected SkuInfoHandler.SkuInfo doRequest(String query) { SkuInfoHandler.SkuInfo info = new SkuInfoHandler.SkuInfo(); info.setSkuId(78910L); info.setSkuName("测试SKU"); return info; } @Data public static class SkuInfo { private Long skuId; private String skuName; } }
最后就是我们的测试代码了
@Component public class DataAggregation { @Autowired private SkuInfoHandler skuInfoHandler; @Autowired private ItemInfoHandler itemInfoHandler; public Map convertItemDetail() throws Exception { Map result = new HashMap(); result.put("skuInfoHandler", skuInfoHandler.doRequest("模拟数据请求")); result.put("itemInfoHandler",itemInfoHandler.doRequest("模拟数据请求")); return result; } public static void main(String[] args) throws Exception { ApplicationContext applicationContext = new ClassPathXmlApplicationContext("classpath:applicationContext.xml"); DataAggregation dataAggregation = (DataAggregation) applicationContext.getBean("dataAggregation"); Map map = dataAggregation.convertItemDetail(); System.out.println(JSON.toJSONString(map)); // 打印的结果数据 // {"skuInfoHandler":{"skuId":78910,"skuName":"测试SKU"},"itemInfoHandler":{"itemId":123456,"itemName":"测试商品"}} } }
这个例子其实是经过一点小小的改动的,我们没有通过向下传递处理器的方式,而是通过实际业务逻辑在 convertItemDetail 的方法中去构建每个模块的数据,最后返回出一个Map结构数据。
这里其实还有另外的一种写法,把每一个需要处理的Handler 可以加载到一个List容器中,然后循环调用每个Handler中的doRequest方法,当然这是针对一些其他的业务场景这么写。
看完大家也能发现其实每个Handler是可以共用的,每一块业务的代码逻辑非常的清晰,这样的代码写出来就感觉很舒服了。
设计模式不是一成不变的,只有适合自己当前业务的模式才是最好的模式。理解前辈的思想,组合我们自己需要的模式。
感谢各位的阅读,以上就是“什么是责任链模式”的内容了,经过本文的学习后,相信大家对什么是责任链模式这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!