由于你沒有用一些設計模式去優(yōu)化你的代碼，所以導致很多小伙伴只能把自己的代碼重寫。這次我們通過請假條來講講設計模式-"職責模式"

一、什么是職責模式

比如我們要請假，我們一般都是寫個請假條，然后提交給系統(tǒng)!系統(tǒng)會自動根據(jù)你的請假的情況，找對應的主管去審批。請假條處理的流程是一環(huán)接一環(huán)的，就像一個鏈條一樣，所有處理請假條的人構成了一個職責鏈條。

職責模式：

• 職責模式的精妙之處在于把請求者和接受者解耦了，就是做了分層處理!請求者不知道是誰處理請假條，不需要知道具體的業(yè)務邏輯和處理請假條的鏈上有多少人，它只管提交，這樣的話系統(tǒng)的靈活性和擴展性就非常好，不信我們看實戰(zhàn)案例。

二、實戰(zhàn)案例

老板讓程序員小李去設計一個請假系統(tǒng)，應該怎么設計呢，小李想了想就用上面的職責模式吧，二話不說先畫一個UML圖，把業(yè)務邏輯關系設計出來。

1).設計請假人類

我們把請假人抽象為一個對象，里面屬性肯定是要有名字，請多少天，請假理由等等.所以Person接口的時候我們留了三個參數(shù)(name,dayoff,reason)。

這個類里面最關鍵的是setLeader()和request()函數(shù):

• setLeader的目的設置請假的提交給主管，但是具體是哪一級別的主管你不用管。
• request的目的是把請假條扔出去，至于這個請假條哪一個級別的主管來批你也不用管，因為用handleRequest()這個函數(shù)來處理。

2).設計主管類

主管的角色有很多種，比如小組長，部門經(jīng)理，部門總監(jiān)，公司老總，HR, 行政總監(jiān)等等。我們把這些人都抽象提取為一個基類叫主管類。

這個Manager類是基類，主要是處理get和set NextHandler.就是請假條在一個鏈條上，需要有一個一層一層提交的關系，比如組長的下一層nextHandler是部門經(jīng)理，部門經(jīng)理的下一層處理是公司老板。

3).具體的幾個角色類

比如我們設計這個請假系統(tǒng)里面有TeamLeader,DeptMaanger,Director等等。

每個的權利不一樣，比如：

• 請假2天內的又TeamLeader審批
• 請假2-10天有部門經(jīng)理申請
• 請假10-22天的有研發(fā)總監(jiān)申請

我們舉一個例子,比如小組長這個類。它主要是重寫了handlerRequest這個類。(大家注意看Pycharm左邊有一個藍色的小圓圈，表示重寫了父類的函數(shù))

DeptMaanger也是類似的，主要在與審批的天數(shù)不一樣。

HR的類主要是處理登記備案:

三、測試一下模型

經(jīng)過了上面的類的重重設計，我們的模型應該可以運行了。我們用幾個請假條來測一下看看：

>>

Leo 申請請假2天,請假理由:參加谷歌大會

同意Leo,請假。簽字人:Eric,(小組長)

請假申請已經(jīng)審核，情況屬實!已備案處理.處理人Tina:行政總監(jiān)

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

Susan 申請請假10天,請假理由:去歐洲旅游，還要去日本泡溫泉

同意Susan,請假。簽字人:Leo,(研發(fā)經(jīng)理)

請假申請已經(jīng)審核，情況屬實!已備案處理.處理人Tina:行政總監(jiān)

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

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

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

請假申請已經(jīng)審核，情況屬實!已備案處理.處理人Tina:行政總監(jiān)