設計模式利劍10 責任鏈模式

2021-05-22 13:53:18 字數 1196 閱讀 3124

定      義:使多個物件都有機會處理請求,從而避免了請求的傳送者和接受者之間的耦合,將這些物件連成一條鏈,並沿著這條鏈傳遞該請求,

直到有物件處理它為止

優      點:將請求和處理分開,請求者可以不知道是誰處理的,處理者不用知道請求的全貌,兩者解耦,提高了靈活性,責任鏈模式減低了請求

的傳送端和接收端之間的耦合,使多個物件有機會處理這個請求。乙個鏈可以是一條線,乙個樹,也可以是乙個環。鏈的拓撲結構可

以是單連通的或多連通的,責任鏈模式並不指定責任鏈的拓撲結構。但是責任鏈模式要求在同一時間裡,命令只可以被傳給乙個下家

(或被處理掉),而不可以傳給多於乙個下家。

缺      點:效能會收到一定的影響,因為每次都要從頭傳到尾才行

使用環境:

1.系統已經有乙個由處理者物件組成的鏈。這個鏈可能由合成模式給出。

2.有多於乙個的處理者物件會處理乙個請求,而且事先並不知道到底由哪乙個處理者物件處理乙個請求。這個處理者物件是動態確定

3.系統想發出乙個請求給多個處理者物件中的某乙個,但是不明確指定是哪乙個處理者物件會處理此請求。

4.處理乙個請求的處理者物件集合需要動態地指定時。

理    解:在責任鏈模式裡,很多物件由每乙個物件對其下家的引用而連線起來形成一條鏈。請求在這個鏈上傳遞,直到鏈上的某乙個物件決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪乙個物件最終處理這個請求,這使系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。

應用案例:

先來看看這個責任鏈模式的uml圖:

再來看看這個圖的具體解釋:

抽象處理者角色(handler):定義出乙個處理請求的介面。如果需要,介面可以定義出乙個方法,以設定和返回下家的引用。

具體處理者角色(concretehandler):具體處理者接到請求後,可以選擇將請求處理掉,或者將請求傳給下家。由於處理者持有下家引用,因此,如果需要,具體處理者可以訪問下家。

再來看乙個我們實際生活中的例子:員工請假,部門經理可以批3天以下的假期,中心總監可批5天以下的假期,副總裁可批10天以下的假期,ceo可以批20天以下假期,超過20天需要開會決定,首先這個審批時有乙個流程的,乙個基層員工要請假,首先他並不知道這個原則,首先他得去諮詢相關人員這個請假規定,然後根據規定來找相關的人,這樣對員工來講非常的苦悶,如果要請20天,那麼還得去找ceo,可是ceo並不認識我,這個假還怎麼請呢?那麼我們使用責任鏈模式,讓員工不再為請假而煩惱,設計的uml圖如下:

簡易設計模式10 責任鏈模式

我們在工作過程中有時候會請假休息,當我們填寫一張請假單後,在這張假單簽字的人,是一級接一級地推進,比如直屬領導 部門總監 ceo 行政人員這樣乙個流程,處理這張假單的過程就是乙個責任的傳遞,他們構成了乙個責任的鏈條,這就是責任鏈模式的核心思想。本篇將詳細梳理責任鏈模式。責任鏈模式也稱職責模式,它是一...

設計模式 行為型模式,責任鏈模式(10)

顧名思義,責任鏈模式 chain of responsibility pattern 為請求建立了乙個接收者物件的鏈。這種模式給予請求的型別,對請求的傳送者和接收者進行解耦。這種型別的設計模式屬於行為型模式。在這種模式中,通常每個接收者都包含對另乙個接收者的引用。如果乙個物件不能處理該請求,那麼它會...

10 責任鏈模式

責任鏈模式也叫做職責鏈模式 職責連鎖模式。在該模式下,很多物件由每乙個物件對其下家的引用而連線起來形成一條鏈,請求在這個鏈上傳遞,直到某個物件處理了該請求。在鏈上的處理者有兩個選擇,乙個是處理該請求,乙個是將請求推給下一家。乙個請求最終可能會出現沒有被處理的情況。例如客戶把乙個請求交給a,a完成了a...