请假条去哪儿了，用Python设计一个请假模式

很多同学学Python一段时间了，但是总感觉自己的写代码不好维护，或者时间长了一旦增加需求或者需要扩展功能，发现自己写的代码就是一团糟！尽管也代码不断的重构了，好像也遵循了PEP8的风格，为啥代码量一旦大了就乱了呢，因为你没有用武林秘籍“设计模式”呀。

由于你没有用一些设计模式去优化你的代码，所以导致最好很多小伙伴只要把自己的代码重写。马上年底了，很多同学要去休假了，不如我们通过请假条来讲讲设计模式-"职责模式"

一

什么是职责模式

比如我们要请假，我们一般都是写个请假条，然后提交给系统！系统会自动根据你的请假的情况，找对应的主管去审批。请假条处理的流程是一环接一环的，就像一个链条一样，所有处理请假条的人构成了一个职责链条。

职责模式：

职责模式的精妙之处在于把请求者和接受者解耦了，就是做了分层处理！请求者不知道是谁处理请假条，不需要知道具体的业务逻辑和处理请假条的链上有多少人，它只管提交，这样的话系统的灵活性和扩展性就非常好，不信我们看实战案例。

二

实战案例

老板让程序员小李去设计一个请假系统，应该怎么设计呢，小李想了想就用上面的职责模式吧，二话不说先画一个UML图，把业务逻辑关系设计出来。

1).设计请假人类

我们把请假人抽象为一个对象，里面属性肯定是要有名字，请多少天，请假理由等等.所以Person接口的时候我们留了三个参数(name,dayoff,reason)。

这个类里面最关键的是setLeader()和request()函数:

setLeader的目的设置请假的提交给主管，但是具体是哪一级别的主管你不用管。

request的目的是把请假条扔出去，至于这个请假条哪一个级别的主管来批你也不用管，因为用handleRequest()这个函数来处理。

2).设计主管类

主管的角色有很多种，比如小组长，部门经理，部门总监，公司老总，HR, 行政总监等等。我们把这些人都抽象提取为一个基类叫主管类。

这个Manager类是基类，主要是处理get和set NextHandler.就是请假条在一个链条上，需要有一个一层一层提交的关系，比如组长的下一层nextHandler是部门经理，部门经理的下一层处理是公司老板。

3).具体的几个角色类

比如我们设计这个请假系统里面有TeamLeader,DeptMaanger,Director等等。

每个的权利不一样，比如：

请假2天内的又TeamLeader审批

请假2-10天有部门经理申请

请假10-22天的有研发总监申请

我们举一个例子,比如小组长这个类。它主要是重写了handlerRequest这个类。(大家注意看Pycharm左边有一个蓝色的小圆圈，表示重写了父类的函数)

DeptMaanger也是类似的，主要在与审批的天数不一样。

HR的类主要是处理登记备案:

三

测试一下模型

经过了上面的类的重重设计，我们的模型应该可以运行了。我们用几个请假条来测一下看看：

Leo 申请请假2天,请假理由:参加谷歌大会

同意Leo,请假。签字人:Eric,(小组长)

请假申请已经审核，情况属实!已备案处理.处理人Tina:行政总监

--------------------------------------------------

Susan 申请请假10天,请假理由:去欧洲旅游，还要去日本泡温泉

同意Susan,请假。签字人:Leo,(研发经理)

请假申请已经审核，情况属实!已备案处理.处理人Tina:行政总监

--------------------------------------------------

Lili 申请请假22天,请假理由:生病休息

同意Lili,请假。签字人:老王,(公司老板)

请假申请已经审核，情况属实!已备案处理.处理人Tina:行政总监

设计模式还是很值得好好研究的，有趣是从菜鸟进阶为高手，代码的架构能力很重要。好的上面的内容分享完了，下面送个来自 Udacity 的新年礼物。

来自优达学城 Udacity的新年礼物：通往未来的登机牌+未来之城日历

登机牌实际上是 Udacity ¥300 礼品卡，可抵用任一纳米学位学费。

同时送上三本可撕日历，每撕下一周都会有一个小惊喜，最后一页有个彩蛋，这里就不剧透了。

这个日历非常酷炫，一共有3份日历。如何获取呢？2019年你计划做什么事情让自己变得更好？在留言区告诉我，抽3位粉丝送出。

另外：下周开始礼品会刷屏的，又是月底又是年底，我们会继续送书送红包的！大家敬请期待哦！