0%

设计模式:职责链模式

概要

设计模式:职责链模式

博客

原帖收藏于IT老兵博客

前言

职责链,chain of responsibility。
这篇笔记第一版记录于2015年,那个时候在研究安卓代码的时候,安卓对于事件的传递使用到了职责链。
现在研究到了Spring的filter chain。
上面两个都是职责链和外观两种设计模式结合在一起使用。
这篇笔记主要是结合四人帮的《设计模式》来学习,这本书写的有点深奥了,难懂,需要慢慢来消化。

正文

1.意图
使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。
处理对象需要连成一个链,不确定由谁来处理,不处理需要往下传,处理了也可以继续往下传(安卓的事件传递是处理了就不传了)。
请求需要被传递,这个请求可能是原封不动地被传递,也有可能略作修改地去传递,所以,这里处理对象的接口最好也是一致的,继承自一个公共的父类(这个时候可能虚基类就比较合理了)。
3.适用性
在以下条件下使用Responsibisibility链:
• 有多个的对象可以处理一个请求,哪个对象处理该请求运行时刻自动确定。
• 你想在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。
• 可处理一个请求的对象集合应被动态指定。
在这里插入图片描述

可处理一个请求的对象集合应被动态指定。

以上摘录自《设计模式》,奇怪的是《PHP设计模式介绍》这本书没有讲职责链,这个是不是和PHP本身面向对象的能力不足有关呢?这个问题留待以后去验证。
我的理解:
1.这个请求要可以被传递,那么这些对象最好是有相同的可以接收这样规格请求的接口,例如安卓的事件传递(安卓的事件传递就是一个职责链,哪一层的view消耗了该事件,就返回true,然后这个返回值就向回传递。在职责链前面往往会使用外观模式,对于外部用户,他并不知道后面的职责链,这个是有外观实现者来处理的)。如果接口不一致的话,恐怕就会有些问题,应该每个对象都可以单独接收这个请求,只是要处于某种特定的情况下。
2.消耗了请求,请求就不再继续向下传递,而是往回返回了;但其实,个人感觉,没有消耗请求的对象也可以针对请求有所响应。
3.每个对象都可以响应请求,也就是请求需要满足一定的条件,所以,对象的顺序是要合理安排的。
上面引用的这段,是15年的笔记,记录了当时研究安卓代码时,对这个职责链的理解。

《设计模式》里面这个样例有些绕,需要整理一下思路。

参考

http://blog.csdn.net/zhang_xinxiu/article/details/9963305, 职责链模式,这篇文章写的很好。
http://blog.csdn.net/hguisu/article/details/7533759, 外观模式,这篇文章写的也很好。