版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/xml1996/article/details/84677784
回顾职责链
经典问题：发请假协商 ：
问题原因：请假人本身需要判断时间的多少来给相应的权限的人来发送请求。
改善目的：为了减少请假人错误发送，减少操作这边带来失误的影响，减少请假人的操作。
改善结构：请假人，只需要发送需要多长时间，请假原因就可以了。中间的处理过程需要程序自己完成，最后接受到的是请假的审批情况。
思考：当然这样的要求其实if-else判断也可以实现，为什么要用职责链？
需求更改1：增加一个审批级别:？使用if-else的结果就是再增加一个嵌套
需求更改2：调整审批顺序呢？比如一二级审批更换位置？使用if-else的结构就是需要删除修改部分代码。
其实这两个需求更改带来的问题职责链都可以解决，它的思想就是高内聚底耦合。
如果增加：完全不用涉及到其他的审批级别
如果调顺序：完全不用删除修改大量的代码实现，只需要在调用部分更换上下级传递关系。
回顾UML图
实例代码的实现
外观层调用
这里的上机时长、准备时长、至少上机时长，需要提前提供值进行传递。
学习过程多理解多体会，欢迎交流指正