标签:style blog io ar color os 使用 sp strong
责任链模式听上去不太好理解,但是其实是非常简单的一种行为型设计模式。举个类比就知道它的定义了,说一个病人看牙的时候,医生不小心把拔下的一个牙掉进了病人嗓子里。各个科室的医生推卸责任,搞得病人因此楼上楼下的跑了不少冤枉路,最后无果而终。
责任链模式就是这种“推卸”责任的模式,你的问题在我这里能解决我就解决,不行就把你推给另一个对象。至于到底谁解决了这个问题了呢?我管呢!
《设计模式》中给它的定义如下:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。
下面是《设计模式》中给出的适用范围:
1) 有多个的对象可以处理一个请求,哪个对象处理该请求运行时刻自动确定。
2) 你想在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。
3) 可处理一个请求的对象集合应被动态指定。
责任链模式真的能给发送者和接收者之间解耦(这好像很神奇)吗?先来看下它的组成角色。这个问题我会在下面提及。责任链模式由两个角色组成:
1) 抽象处理者角色(Handler):它定义了一个处理请求的接口。当然对于链子的不同实现,也可以在这个角色中实现后继链。
2) 具体处理者角色(Concrete Handler):实现抽象角色中定义的接口,并处理它所负责的请求。如果不能处理则访问它的后继者。
纯与不纯
责任链模式的纯与不纯的区别,就像黑猫、白猫的区别一样。不要刻意的去使自己的代码来符合一个模式的公式。只要能够使代码降低耦合、提高重用,满足系统需求并能很好的适应变化就好了。正所谓:管它黑猫白猫,抓住老鼠就是好猫!
纯的责任链模式,规定一个具体处理者角色只能对请求作出两种动作:自己处理;传给下家。不能出现只处理了一部分,把剩下的传给了下家的情况。而且请求在责任链中必须被处理,而不能出现无果而终的结局。
反之,则就是不纯的责任链模式。
不纯的责任链模式还算是责任链模式吗?比如一个请求被捕获后,每个具体处理者都尝试去处理它,不管结果如何都将请求再次转发。我认为这种方式的实现,算不算是责任链模式的一种倒不重要,重要的是我们也能从中体味到责任链模式的思想:通过将多个处理者之间建立联系,来达到请求与具体的某个处理者的解耦。
举个栗子:
1 //这是抽象处理者角色
2 public interface CodeAutoParse {
3 //这里就是统一的处理请求使用的接口
4 String[] generateCode(String moduleCode, int number, String rule,String[] target)
5 throws BaseException;
6 }
7
8 //这个为处理日期使用的具体处理者
9 public class DateAutoParse implements CodeAutoParse{
10 //获取当前时间
11 private final Calendar currentDate = Calendar.getInstance();
12 //这里用来注入下一个处理者,系统中采用Spring Bean 管理
13 private CodeAutoParse theNextParseOfDate;
14 public void setTheNextParseOfDate(CodeAutoParse theNextParseOfDate){
15 this.theNextParseOfDate = theNextParseOfDate ;
16 }
17 /*
18 *实现的处理请求的接口
19 *这个接口首先判断用户定义的格式是否有流水号,有则解析,没有则跳过
20 *下传到下一个处理者
21 */
22 public String[] generateCode(String moduleCode, int number, String rule, String[] target)
23 throws BaseException {
24 //这里省略了处理的业务
25 ……
26 if(theNextParseOfDate != null)
27 return theNextParseOfDate.generateCode(moduleCode , number , rule, target)
28 else
29 return target;
30 }
标签:style blog io ar color os 使用 sp strong
原文地址:http://www.cnblogs.com/simbachen/p/4139251.html