您好,登錄后才能下訂單哦!
這篇文章主要介紹java責任鏈模式的示例分析,文中介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們一定要看完!
在現實生活中,常常會出現這樣的事例:一個請求有多個對象可以處理,但每個對象的處理條件或權限不同。例如,公司員工請假,可批假的領導有部門負責人、副總經理、總經理等,但是每個領導能批準的天數不同,員工必須根據自己要請假的天數去找不同的領導簽名,也就是說員工必須記住每個領導的姓名、電話和地址等信息,這增加了員工請假的難度。因為領導有很多,員工到底找哪位領導他還得自己判斷,所以這會顯得特別特別麻煩。這樣的例子還有很多,如找領導出差報銷、生活中的"擊鼓傳花"游戲等。
說了這么多,不知你有沒有在公司請過假,要是你請過假,想想是不是這么一回事啊!很顯然,在該例子中,請假就是一個請求,而且多個對象都可以處理該請求,有部門負責人、副總經理、總經理等,他們都可以進行批假,但是每個對象的處理條件或權限不同,比如部門負責人有可能只能批1~2天的假,一旦超過這一請假天數,員工就得去找部門負責人的頂頭上司,也就是副總經理了,要是還超過了副總經理批假的一個范圍的話,那么員工就得再去找總經理批假了,這是不是就增加了員工請假的難度啊!
既然問題出現了,那么又該如何去解決呢?使用責任鏈模式。那什么又是責任鏈模式呢?下面我們就來看一看它的概念。
又名職責鏈模式,為了避免請求發送者與多個請求處理者耦合在一起,將所有請求的處理者通過前一個對象記住其下一個對象的引用而連成一條鏈;當有請求發生時,可將請求沿著這條鏈傳遞,直到有對象處理它為止。
很多人看完,完全不知道啥意思,這里我就為大家稍微解釋解釋。就以員工請假案例來說,請求發送者指的就是員工,因為是員工(例如張三)要請假的;多個請求處理者指的是部門負責人、副總經理、總經理等這些人。這樣,張三請假的示意圖就是下面這樣了。
從上圖中可以看到,張三要請假的話,那么他只需要去找自己部門的負責人就可以了,因為對于他來說,他肯定知道自己部門的負責人是誰。然后,部門負責人會根據張三請假的天數來決定是否批假,如果部門負責人能批假,那么自然就幫張三批了;可如果他不能批,那么他就會去找他的頂頭上司,即副總經理,因為他們已經連成一條鏈了。同理,副總經理也是一樣,他也會根據他所能批準的請假天數來判斷,如果在自己的批準范圍之內,那么廢話不多說,直接批假;如果批不了的話,那么再去找對應他的頂頭上司,即總經理。于此一來,當整個鏈走完,張三請假的流程就算是結束了。
理解了責任鏈模式的概念之后,接下來,我們再來看一下責任鏈模式的結構。
責任鏈模式主要包含以下角色:
抽象處理者(Handler)角色:定義一個處理請求的接口,包含抽象處理方法和一個后繼連接(即記住下一個對象的引用)。
注意了,對于該角色,我們既可以定義成接口,也可以定義成抽象類,一般來說,我們都會定義成抽象類。
具體處理者(Concrete Handler)角色:實現抽象處理者的處理方法,判斷能否處理本次請求,若可以處理請求則處理,否則將該請求轉給它的后繼者。
客戶類(Client)角色:創建處理鏈,并向鏈頭的具體處理者對象提交請求,它不關心處理細節和請求的傳遞過程。
也就是說,客戶類不需要去找對應的對象進行處理,而只需將處理鏈創建好即可。就拿上述張三請假的示意圖來說,他只需要找他自己的部門負責人即可,至于請假流程要經過哪幾步,他并不需要去關注。
以上是“java責任鏈模式的示例分析”這篇文章的所有內容,感謝各位的閱讀!希望分享的內容對大家有幫助,更多相關知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。