1700464057
对女儿提出的请示，应该在父亲类中做出决定，父亲有责任、有义务处理女儿的请示，因此Father类应该是知道女儿的请求自己处理，而不是在Client类中进行组装出来，也就是说原本应该是父亲这个类做的事情抛给了其他类进行处理，不应该是这样的。
1700464058
1700464059
❑代码臃肿
1700464060
1700464061
我们在Client类中写了if……else的判断条件，而且能随着能处理该类型的请示人员越多，if……else的判断就越多，想想看，臃肿的条件判断还怎么有可读性？！
1700464062
1700464063
❑耦合过重
1700464064
1700464065
这是什么意思呢，我们要根据Women的type来决定使用IHandler的那个实现类来处理请求。有一个问题是：如果IHandler的实现类继续扩展怎么办？修改Client类？与开闭原则违背了！
1700464066
1700464067
❑异常情况欠考虑
1700464068
1700464069
妻子只能向丈夫请示吗？如果妻子（比如一个现代女性穿越到古代了，不懂什么“三从四德”）向自己的父亲请示了，父亲应该做何处理？我们的程序上可没有体现出来，逻辑失败了！
1700464070
1700464071
既然有这么多的问题，那我们要想办法来解决这些问题，我们先来分析一下需求，女性提出一个请示，必然要获得一个答复，甭管是同意还是不同意，总之是要一个答复的，而且这个答复是唯一的，不能说是父亲作出一个决断，而丈夫也作出了一个决断，也即是请示传递出去，必然有一个唯一的处理人给出唯一的答复，OK，分析完毕，收工，重新设计，我们可以抽象成这样一个结构，女性的请求先发送到父亲类，父亲类一看是自己要处理的，就作出回应处理，如果女儿已经出嫁了，那就要把这个请求转发到女婿来处理，那女婿一旦去天国报道了，那就由儿子来处理这个请求，类似于如图16-2所示的顺序处理图。
1700464072
1700464073
1700464074
1700464075
1700464076
图16-2 女性请示的顺序处理图
1700464077
1700464078
父亲、丈夫、儿子每个节点有两个选择：要么承担责任，做出回应；要么把请求转发到后序环节。结构分析得已经很清楚了，那我们看怎么来实现这个功能，类图重新修正，如图16-3所示。
1700464079
1700464080
1700464081
1700464082
1700464083
图16-3 顺序处理的类图
1700464084
1700464085
从类图上看，三个实现类Father、Husband、Son只要实现构造函数和父类中的抽象方法response就可以了，具体由谁处理女性提出的请求，都已经转移到了Handler抽象类中，我们来看Handler怎么实现，如代码清单16-8所示。
1700464086
1700464087
代码清单16-8 修改后的Handler类
1700464088
1700464089
public abstract class Handler{
1700464090
1700464091
public final static int FATHER_LEVEL_REQUEST=1；
1700464092
1700464093
public final static int HUSBAND_LEVEL_REQUEST=2；
1700464094
1700464095
public final static int SON_LEVEL_REQUEST=3；
1700464096
1700464097
//能处理的级别
1700464098
1700464099
private int level=0；
1700464100
1700464101
//责任传递，下一个人责任人是谁
1700464102
1700464103
private Handler nextHandler；
1700464104
1700464105
//每个类都要说明一下自己能处理哪些请求
1700464106