1700464020
1700464021
}
1700464022
1700464023
}
1700464024
1700464025
}
1700464026
1700464027
首先是通过随机方法产生了5个古代妇女的对象，然后看她们是如何就逛街这件事去请示的，运行结果如下所示（由于是随机的，您看到的结果可能和这里有所不同）：
1700464028
1700464029
––—女儿向父亲请示––-
1700464030
1700464031
女儿的请示是：我要出去逛街
1700464032
1700464033
父亲的答复是：同意
1700464034
1700464035
––—母亲向儿子请示––-
1700464036
1700464037
母亲的请示是：我要出去逛街
1700464038
1700464039
儿子的答复是：同意
1700464040
1700464041
––—妻子向丈夫请示––-
1700464042
1700464043
妻子的请示是：我要出去逛街
1700464044
1700464045
丈夫的答复是：同意
1700464046
1700464047
––—女儿向父亲请示––-
1700464048
1700464049
女儿的请示是：我要出去逛街
1700464050
1700464051
父亲的答复是：同意
1700464052
1700464053
“三从四德”的旧社会规范已经完整地表现出来了，你看谁向谁请示都定义出来了，但是你是不是发现这个程序写得有点不舒服？有点别扭？有点想重构它的感觉？那就对了！这段代码有以下几个问题：
1700464054
1700464055
❑职责界定不清晰
1700464056
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
妻子只能向丈夫请示吗？如果妻子（比如一个现代女性穿越到古代了，不懂什么“三从四德”）向自己的父亲请示了，父亲应该做何处理？我们的程序上可没有体现出来，逻辑失败了！
[
上一页 ]
[ :1.70046402e+09 ]
[
下一页 ]