|
很多同學(xué)學(xué)Python一段時(shí)間了，但是總感覺自己的寫代碼不好維護(hù)，或者時(shí)間長了一旦增加需求或者需要擴(kuò)展功能，發(fā)現(xiàn)自己寫的代碼就是一團(tuán)糟！盡管也代碼不斷的重構(gòu)了，好像也遵循了PEP8的風(fēng)格，為啥代碼量一旦大了就亂了呢，因?yàn)槟銢]有用武林秘籍“設(shè)計(jì)模式”呀。 由于你沒有用一些設(shè)計(jì)模式去優(yōu)化你的代碼，所以導(dǎo)致很多小伙伴只能把自己的代碼重寫。這次我們通過請假條來講講設(shè)計(jì)模式-'職責(zé)模式' 比如我們要請假，我們一般都是寫個(gè)請假條，然后提交給系統(tǒng)！系統(tǒng)會(huì)自動(dòng)根據(jù)你的請假的情況，找對(duì)應(yīng)的主管去審批。請假條處理的流程是一環(huán)接一環(huán)的，就像一個(gè)鏈條一樣，所有處理請假條的人構(gòu)成了一個(gè)職責(zé)鏈條。 職責(zé)模式： 職責(zé)模式的精妙之處在于把請求者和接受者解耦了，就是做了分層處理！請求者不知道是誰處理請假條，不需要知道具體的業(yè)務(wù)邏輯和處理請假條的鏈上有多少人，它只管提交，這樣的話系統(tǒng)的靈活性和擴(kuò)展性就非常好，不信我們看實(shí)戰(zhàn)案例。 老板讓程序員小李去設(shè)計(jì)一個(gè)請假系統(tǒng)，應(yīng)該怎么設(shè)計(jì)呢，小李想了想就用上面的職責(zé)模式吧，二話不說先畫一個(gè)UML圖，把業(yè)務(wù)邏輯關(guān)系設(shè)計(jì)出來。 1).設(shè)計(jì)請假人類 我們把請假人抽象為一個(gè)對(duì)象，里面屬性肯定是要有名字，請多少天，請假理由等等.所以Person接口的時(shí)候我們留了三個(gè)參數(shù)(name,dayoff,reason)。 這個(gè)類里面最關(guān)鍵的是setLeader()和request()函數(shù):
2).設(shè)計(jì)主管類 主管的角色有很多種，比如小組長，部門經(jīng)理，部門總監(jiān)，公司老總，HR, 行政總監(jiān)等等。我們把這些人都抽象提取為一個(gè)基類叫主管類。 這個(gè)Manager類是基類，主要是處理get和set NextHandler.就是請假條在一個(gè)鏈條上，需要有一個(gè)一層一層提交的關(guān)系，比如組長的下一層nextHandler是部門經(jīng)理，部門經(jīng)理的下一層處理是公司老板。 3).具體的幾個(gè)角色類 比如我們設(shè)計(jì)這個(gè)請假系統(tǒng)里面有TeamLeader,DeptMaanger,Director等等。 每個(gè)的權(quán)利不一樣，比如：
我們舉一個(gè)例子,比如小組長這個(gè)類。它主要是重寫了handlerRequest這個(gè)類。(大家注意看Pycharm左邊有一個(gè)藍(lán)色的小圓圈，表示重寫了父類的函數(shù)) DeptMaanger也是類似的，主要在與審批的天數(shù)不一樣。 HR的類主要是處理登記備案: 經(jīng)過了上面的類的重重設(shè)計(jì)，我們的模型應(yīng)該可以運(yùn)行了。我們用幾個(gè)請假條來測一下看看： >> Leo 申請請假2天,請假理由:參加谷歌大會(huì) 同意Leo,請假。簽字人:Eric,(小組長) 請假申請已經(jīng)審核，情況屬實(shí)!已備案處理.處理人Tina:行政總監(jiān) -------------------------------------------------- Susan 申請請假10天,請假理由:去歐洲旅游，還要去日本泡溫泉 同意Susan,請假。簽字人:Leo,(研發(fā)經(jīng)理) 請假申請已經(jīng)審核，情況屬實(shí)!已備案處理.處理人Tina:行政總監(jiān) -------------------------------------------------- Lili 申請請假22天,請假理由:生病休息 同意Lili,請假。簽字人:老王,(公司老板) 請假申請已經(jīng)審核，情況屬實(shí)!已備案處理.處理人Tina:行政總監(jiān) |
|
|
