java責(zé)任鏈模式的示例分析

這篇文章主要介紹java責(zé)任鏈模式的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

概述

在現(xiàn)實生活中，常常會出現(xiàn)這樣的事例：一個請求有多個對象可以處理，但每個對象的處理條件或權(quán)限不同。例如，公司員工請假，可批假的領(lǐng)導(dǎo)有部門負責(zé)人、副總經(jīng)理、總經(jīng)理等，但是每個領(lǐng)導(dǎo)能批準(zhǔn)的天數(shù)不同，員工必須根據(jù)自己要請假的天數(shù)去找不同的領(lǐng)導(dǎo)簽名，也就是說員工必須記住每個領(lǐng)導(dǎo)的姓名、電話和地址等信息，這增加了員工請假的難度。因為領(lǐng)導(dǎo)有很多，員工到底找哪位領(lǐng)導(dǎo)他還得自己判斷，所以這會顯得特別特別麻煩。這樣的例子還有很多，如找領(lǐng)導(dǎo)出差報銷、生活中的"擊鼓傳花"游戲等。

說了這么多，不知你有沒有在公司請過假，要是你請過假，想想是不是這么一回事啊！很顯然，在該例子中，請假就是一個請求，而且多個對象都可以處理該請求，有部門負責(zé)人、副總經(jīng)理、總經(jīng)理等，他們都可以進行批假，但是每個對象的處理條件或權(quán)限不同，比如部門負責(zé)人有可能只能批1~2天的假，一旦超過這一請假天數(shù)，員工就得去找部門負責(zé)人的頂頭上司，也就是副總經(jīng)理了，要是還超過了副總經(jīng)理批假的一個范圍的話，那么員工就得再去找總經(jīng)理批假了，這是不是就增加了員工請假的難度?。?/p>

既然問題出現(xiàn)了，那么又該如何去解決呢？使用責(zé)任鏈模式。那什么又是責(zé)任鏈模式呢？下面我們就來看一看它的概念。

又名職責(zé)鏈模式，為了避免請求發(fā)送者與多個請求處理者耦合在一起，將所有請求的處理者通過前一個對象記住其下一個對象的引用而連成一條鏈；當(dāng)有請求發(fā)生時，可將請求沿著這條鏈傳遞，直到有對象處理它為止。

很多人看完，完全不知道啥意思，這里我就為大家稍微解釋解釋。就以員工請假案例來說，請求發(fā)送者指的就是員工，因為是員工（例如張三）要請假的；多個請求處理者指的是部門負責(zé)人、副總經(jīng)理、總經(jīng)理等這些人。這樣，張三請假的示意圖就是下面這樣了。

從上圖中可以看到，張三要請假的話，那么他只需要去找自己部門的負責(zé)人就可以了，因為對于他來說，他肯定知道自己部門的負責(zé)人是誰。然后，部門負責(zé)人會根據(jù)張三請假的天數(shù)來決定是否批假，如果部門負責(zé)人能批假，那么自然就幫張三批了；可如果他不能批，那么他就會去找他的頂頭上司，即副總經(jīng)理，因為他們已經(jīng)連成一條鏈了。同理，副總經(jīng)理也是一樣，他也會根據(jù)他所能批準(zhǔn)的請假天數(shù)來判斷，如果在自己的批準(zhǔn)范圍之內(nèi)，那么廢話不多說，直接批假；如果批不了的話，那么再去找對應(yīng)他的頂頭上司，即總經(jīng)理。于此一來，當(dāng)整個鏈走完，張三請假的流程就算是結(jié)束了。

理解了責(zé)任鏈模式的概念之后，接下來，我們再來看一下責(zé)任鏈模式的結(jié)構(gòu)。

結(jié)構(gòu)

責(zé)任鏈模式主要包含以下角色：

• 抽象處理者（Handler）角色：定義一個處理請求的接口，包含抽象處理方法和一個后繼連接（即記住下一個對象的引用）。

注意了，對于該角色，我們既可以定義成接口，也可以定義成抽象類，一般來說，我們都會定義成抽象類。

• 具體處理者（Concrete Handler）角色：實現(xiàn)抽象處理者的處理方法，判斷能否處理本次請求，若可以處理請求則處理，否則將該請求轉(zhuǎn)給它的后繼者。

• 客戶類（Client）角色：創(chuàng)建處理鏈，并向鏈頭的具體處理者對象提交請求，它不關(guān)心處理細節(jié)和請求的傳遞過程。

也就是說，客戶類不需要去找對應(yīng)的對象進行處理，而只需將處理鏈創(chuàng)建好即可。就拿上述張三請假的示意圖來說，他只需要找他自己的部門負責(zé)人即可，至于請假流程要經(jīng)過哪幾步，他并不需要去關(guān)注。

以上是“java責(zé)任鏈模式的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！