定义:Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.Chain the receiving objects and pass the request along the chain until an object handles it.(使多个对象都有机会处理请求,从而避免了请求的发送者和接受者之间的耦合关 系。将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止。)
这段代码有以下几个问题:
1、职责界定不清晰 对女儿提出的请示,应该在父亲类中做出决定,父亲有责任、有义务处理女儿的请示, 因此Father类应该是知道女儿的请求自己处理,而不是在Client类中进行组装出来,也就是说 原本应该是父亲这个类做的事情抛给了其他类进行处理,不应该是这样的。
2、代码臃肿 我们在Client类中写了if...else的判断条件,而且能随着能处理该类型的请示人员越 多,if...else的判断就越多,想想看,臃肿的条件判断还怎么有可读性?!
3、耦合过重 这是什么意思呢,我们要根据Women的type来决定使用IHandler的那个实现类来处理请 求。有一个问题是:如果IHandler的实现类继续扩展怎么办?修改Client类?与开闭原则违背 了!
4、异常情况欠考虑 妻子只能向丈夫请示吗?如果妻子(比如一个现代女性穿越到古代了,不懂什么“三从 四德”)向自己的父亲请示了,父亲应该做何处理?我们的程序上可没有体现出来,逻辑失败了
责任链模式的优点:
责任链模式非常显著的优点是将请求和处理分开。请求者可以不用知道是谁处理的,处 理者可以不用知道请求的全貌(例如在J2EE项目开发中,可以剥离出无状态Bean由责任链处 理),两者解耦,提高系统的灵活性。
责任链模式的缺点:
责任链有两个非常显著的缺点:一是性能问题,每个请求都是从链头遍历到链尾,特别 是在链比较长的时候,性能是一个非常大的问题。二是调试不很方便,特别是链条比较长, 环节比较多的时候,由于采用了类似递归的方式,调试的时候逻辑可能比较复杂。
注意事项:
链中节点数量需要控制,避免出现超长链的情况,一般的做法是在Handler中设置一个 最大节点数量,在setNext方法中判断是否已经是超过其阈值,超过则不允许该链建立,避免 无意识地破坏系统性能
生活中的开发例子:
如项目开发的时候,需求确 认是这样的:一个请求(如银行客户存款的币种),一个处理者(只处理人民币),但是随 着业务的发展(改革开放了嘛,还要处理美元、日元等),处理者的数量和类型都有所增 加,那这时候就可以在第一个处理者后面建立一个链,也就是责任链来处理请求,如果是人 民币,好,还是第一个业务逻辑来处理;如果是美元,好,传递到第二个业务逻辑来处理; 日元、欧元……这些都不用在对原有的业务逻辑产生很大改变,通过扩展实现类就可以很好 地解决这些需求变更的问题。