很多同學(xué)學(xué)Python一段時間了，但是總感覺自己的寫代碼不好維護，或者時間長了一旦增加需求或者需要擴展功能，發(fā)現(xiàn)自己寫的代碼就是一團糟！盡管也代碼不斷的重構(gòu)了，好像也遵循了PEP8的風(fēng)格，為啥代碼量一旦大了就亂了呢，因為你沒有用武林秘籍“設(shè)計模式”呀。

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

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

職責(zé)模式：

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

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

1).設(shè)計請假人類

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

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

• setLeader的目的設(shè)置請假的提交給主管，但是具體是哪一級別的主管你不用管。

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

2).設(shè)計主管類

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

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

3).具體的幾個角色類

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

每個的權(quán)利不一樣，比如：

• 請假2天內(nèi)的又TeamLeader審批

• 請假2-10天有部門經(jīng)理申請

• 請假10-22天的有研發(fā)總監(jiān)申請

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

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

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

經(jīng)過了上面的類的重重設(shè)計，我們的模型應(yī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)