博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
责任链模式
阅读量:7048 次
发布时间:2019-06-28

本文共 840 字,大约阅读时间需要 2 分钟。

hot3.png

优点:

•责任链模式降低了请求的发送端和接收端之间的耦合,使多个对象都有机会处理这个请求。
•由于是在客户端来定义责任链的结构,可以动态地增加或修改处理一个请求的结构,增强了给对象指派职责的灵活性。
缺点:
•责任链模式一般是从链子的开头位置进行遍历,找到时候的处理对象,对性能有一定的损耗。
适用场合:
•有多个的对象可以处理一个请求,哪个对象处理该请求运行时刻自动确定。
•想在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。
•可处理一个请求的对象集合应被动态指定。
•当一个方法的传入参数将成为分支语句的判断条件,分支条件存在扩展的可能,每一个分支的职责相对独立,且逻辑较为复杂时。

与状态模式的区别:

责任链模式注重责任的传递,并且责任链由客户端进行配置,具体的操作对象维护了一下后继者的引用(由客户端配置),如果自己能够处理,则处理,不能处理调用后继者处理。

状态模式注重对象状态的转换,这个转换过程对客户端是透明的。重点是把状态的判断逻辑封装在“表示不同状态的一系列类中”具体的操作完成后,修改被操作这的状态,这个状态的修改对客户端是透明的。

PS:

•纯责任链模规定一个具体的处理对象只能对请求作出处理请求或传给后继者两种动作,不能出现处理了一部分,把剩下的传给后继者处理的情况,而且请求在责任链中必须被处理。然而责任链模的思想在于,通过将多个处理对象建立关联,来达到请求与具体的某个处理者的解耦。所以在实际的需求中不一定非要达到一种纯责任链模式的设计。
•责任链模式并不创建责任链。责任链的创建必须由系统的其它部分创建出来。
•责任链可以是一个链可以是一条线,一个树,也可以是一个环。
•GoF规定一个请求必须被某一个处理者对象所处理,所以为了避免一个请求有可能到了链的末端都得不到处理,或者因为没有正确配置而得不到处理,可以提供一个默认处理所有请求的对象。

转载于:https://my.oschina.net/u/729507/blog/87067

你可能感兴趣的文章
XenServer 6.5实战系列之五:XenCenter 6.5
查看>>
CentOS5.8 x86_64系统手动释放内存
查看>>
孤军奋战的百合网 下一城会在哪?
查看>>
Shell脚本之:生成随机密码的若干种可能
查看>>
FireEye:雪人行动针对美国海外战争退伍军人网站
查看>>
读书笔记—做事坚定,做人柔软
查看>>
我是怎样不关站通过备案的
查看>>
JavaScript(React Native、Node.js等)移动、服务端通吃的全栈语言
查看>>
0成本日涨粉1000+,新媒体小白也能实操的引流方法
查看>>
微软MCITP系列课程(十五)搭建DHCP服务器
查看>>
《VMware虚拟化与计算应用案例详解》第三次印刷!
查看>>
Lync Server 2013企业版部署系列之六:AD准备
查看>>
ORA-600 [Kgeade_is_0]内部错误一例
查看>>
六个SEO关键词分析工具
查看>>
SQL Server 的一些操作
查看>>
FootPrint提取并自动化建模(简化)
查看>>
【技术贴】百度输入法老皮肤下载|百度输入法老的默认皮肤|百度皮肤下载
查看>>
discuz x2.5 模版制作 滚动图片
查看>>
使用GDB和Valgrind调试C程序
查看>>
不可思议,40个令人惊叹的iOS应用程序图标的设计灵感
查看>>