前言
最近心情很差,因?yàn)樯睿驗(yàn)楣ぷ鳎凰韵胝?qǐng)幾天假去麗江玩玩。就向項(xiàng)目經(jīng)理提交了休假申請(qǐng),我的項(xiàng)目經(jīng)理向項(xiàng)目主管提交了我的休假申請(qǐng),項(xiàng)目主管向部門經(jīng)理提交了我的休假申請(qǐng);最后,部門經(jīng)理同意了我的休假申請(qǐng)。是的,一個(gè)簡(jiǎn)單的休假申請(qǐng),需要這么復(fù)雜的流程,這也是一個(gè)公司保證它正常運(yùn)行的必要。如果部門經(jīng)理休假了,那么我的休假申請(qǐng)由誰審批呢?這個(gè)時(shí)候由項(xiàng)目主管代替部門經(jīng)理進(jìn)行審批。一個(gè)休假申請(qǐng)的審批制度有著嚴(yán)格的要求。而在處理這個(gè)請(qǐng)假審批時(shí),各個(gè)人員就好比在一條鏈上的節(jié)點(diǎn),我不知道我的請(qǐng)求由誰審批,但是,我的請(qǐng)求最終會(huì)有人來處理的。而這樣的一種行為,就好比我今天需要總結(jié)的職責(zé)鏈模式一樣。
什么是職責(zé)鏈模式?
在GOF的《設(shè)計(jì)模式:可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書中對(duì)職責(zé)鏈模式是這樣說的:使多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求,從而避免請(qǐng)求的發(fā)送者和接收者之間的耦合關(guān)系。將這些對(duì)象連成一條鏈,直到有一個(gè)對(duì)象處理它為止;如下圖:
對(duì)于每個(gè)角色,他們都有他們的職責(zé);當(dāng)我提交了休假申請(qǐng)時(shí),項(xiàng)目經(jīng)理需要判斷,看看自己能否處理,如果休假超過了2個(gè)小時(shí),那么項(xiàng)目經(jīng)理就不能處理了;項(xiàng)目經(jīng)理將這個(gè)請(qǐng)求提交到項(xiàng)目主管,項(xiàng)目主管判斷部門經(jīng)理在不在,如果部門經(jīng)理在,項(xiàng)目主管就不能處理了;最后,我的休假申請(qǐng)就到了部門經(jīng)理那里了,由他親自審批。可以很明顯的看到,項(xiàng)目經(jīng)理、項(xiàng)目主管和部門經(jīng)理都有可能處理我的休假申請(qǐng),我的請(qǐng)求沿著這條鏈一直走下去,直到有人處理了我的請(qǐng)求。
UML類圖
Handler:定義了一個(gè)處理請(qǐng)求的接口;其它類如果需要處理相同的請(qǐng)求,可以實(shí)現(xiàn)該接口就好了;
ConcreteHandler:處理它所負(fù)責(zé)的請(qǐng)求,如果可處理該請(qǐng)求,就處理掉這個(gè)請(qǐng)求;否則將該請(qǐng)求轉(zhuǎn)發(fā)給它的下一個(gè)可以處理該請(qǐng)求的對(duì)象,所以它必須能訪問它的下一個(gè)可以處理同樣請(qǐng)求的對(duì)象;
Client:向處理對(duì)象提出具體的請(qǐng)求。
當(dāng)客戶提交一個(gè)請(qǐng)求時(shí),請(qǐng)求沿著一條鏈傳遞,直至有一個(gè)ConcreteHandler對(duì)象負(fù)責(zé)處理它。
使用場(chǎng)合
1.有多個(gè)的對(duì)象可以處理一個(gè)請(qǐng)求,由哪個(gè)對(duì)象處理該請(qǐng)求是在運(yùn)行時(shí)刻自動(dòng)確定的;
2.如果想在不明確指定接收者的情況下,向多個(gè)對(duì)象中的一個(gè)提交一個(gè)請(qǐng)求;
3.可以處理一個(gè)請(qǐng)求的對(duì)象集合應(yīng)被動(dòng)態(tài)指定。
代碼實(shí)現(xiàn)
優(yōu)缺點(diǎn)
1.降低耦合度;職責(zé)鏈模式使得一個(gè)對(duì)象不用知道是哪一個(gè)對(duì)象處理它的請(qǐng)求。對(duì)象僅需要知道該請(qǐng)求會(huì)被正確的處理。接收者和發(fā)送者都沒有對(duì)方的明確的信息,且鏈中的對(duì)象不需要知道鏈的結(jié)構(gòu);
2.增強(qiáng)了給對(duì)象指派職責(zé)的靈活性;當(dāng)在對(duì)象中分派職責(zé)時(shí),職責(zé)鏈給你更多的靈活性。你可以通過在運(yùn)行時(shí)對(duì)該鏈進(jìn)行動(dòng)態(tài)的增加或修改來增加或改變處理一個(gè)請(qǐng)求的那些職責(zé);
3.不保證被接受,既然一個(gè)請(qǐng)求沒有明確的接收者,那么就不能保證它一定會(huì)被處理;該請(qǐng)求可能一直到鏈的末端都得不到處理。一個(gè)請(qǐng)求也可能因該鏈沒有被正確配置而得不到處理。
總結(jié)
職責(zé)鏈模式在實(shí)現(xiàn)時(shí),需要處理好它的后繼者的問題,就是說,如果我不處理這個(gè)請(qǐng)求,那么我將把這個(gè)請(qǐng)求發(fā)給誰去處理呢?同時(shí),職責(zé)鏈模式在實(shí)現(xiàn)時(shí),它的鏈的形狀并不是由職責(zé)鏈本身建立和維護(hù)的,而是由客戶進(jìn)行創(chuàng)建的,由客戶指定每一個(gè)處理者的后繼者是誰。這就大大的提高了職責(zé)鏈的靈活性。在實(shí)際中,我們也可以將職責(zé)鏈模式與組合模式相結(jié)合,一個(gè)構(gòu)件的父構(gòu)件可以作為它的后繼者。
新聞熱點(diǎn)
疑難解答