職責鏈模式(Chain of Responsibility)

詳解

定義

爲了避免請求發送者與接收者耦合在一起,讓多個對象都有可能接收請求,將這些對象連接成一條鏈,並且沿着這條鏈傳遞請求,直到有對象處理它爲止,職責鏈模式又稱爲責任鏈模式,它是一種對象行爲型模式。(如果你接觸過異常處理,那麼套用異常處理機制可以更好地理解)。

職責鏈可以是一條直線,也可以是一個環,還可以是一個樹形結構,不過最常見的職責鏈是直線型,即沿着一條單向的鏈來傳遞請求。鏈上的每一個對象都是請求處理者,職責鏈模式可以將請求的處理者組織成一條鏈,並使請求沿着鏈傳遞,由鏈上的處理者對請求進行相應的處理,而客戶端無須關心請求的處理細節以及請求的傳遞,只需將請求發送到鏈上即可,通過這種方法將請求的發送者和請求的處理者解耦,消除兩個角色間的依賴關係,可以自由地組合。



原理結構



上圖闡釋的是職責連模式的實現原理,主要角色包括:

  • Handler:抽象處理者。定義出一個處理請求的接口。如果需要,接口可以定義出一個方法,以設定和返回對下家的引用。這個角色通常由一個抽象類或接口實現。
  • ConcreteHandler: 具體處理者。具體處理者接到請求後,可以選擇將請求處理掉,或者將請求傳給下家。由於具體處理者持有對下家的引用,因此,如果需要,具體處理者可以訪問下家。
  • Client:客戶端
  • handleRequest:抽象處理者的公用接口,要求每個鏈式節點都實現這個接口,能夠處理客戶端發過來的請求數據。
對於每個鏈式節點,需要滿足一下兩個條件:

  1. 實現抽象處理者(Handler)所定義的抽象接口,能夠識別接收的請求;
  2. 有一個successor,用於把當前不能處理的請求轉發傳遞到下一個節點,如此才能形成一個鏈。(successor是指下一個ConcreteHandler的引用,相當於鏈表裏面的next指針)
由於通過上述的編程設計,使得請求和處理該請求的對象完全沒有依賴關係,因爲客戶端甚至不知道是誰處理了這個請求,這樣的話,使得整個鏈式結構很靈活,可以隨時添加新的的節點,當然也支持隨意調節節點順序、刪除不必要的節點等等操作。

通過上述的講解,或許你發現了了我們這裏講的鏈式結構和我們所熟知的鏈表的關係。如果你認爲職責鏈就是一個鏈表,那麼,我只能說你Too young too simple。

示例代碼

(待續)

小結

行爲型模式是對在不同的對象之間劃分責任和算法的抽象化,行爲型模式不僅僅關注類和對象的結構,而且重點關注它們之間的相互作用。通過行爲型模式,可以更加清晰地劃分類與對象的職責,並研究系統在運行時實例對象之間的交互。行爲型模式可以分爲類行爲型模式和對象行爲型模式兩種。職責鏈模式可以避免請求發送者與接收者耦合在一起,讓多個對象都有可能接收請求,將這些對象連接成一條鏈,並且沿着這條鏈傳遞請求,直到有對象處理它爲止,它是一種對象行爲型模式。

在我們日常使用中,我們或許直接接觸這方面的機會不多,但是,如果你認真有研究過程序的一場處理機制,那麼你就能夠發現這種處理機制正是採用職責鏈的方式處理程序中拋出的異常錯誤的。

在職責鏈模式裏,很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞,直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪一個對象最終處理這個請求,這使得系統可以在不影響客戶端的情況下動態地重新組織鏈和分配責任。
職責鏈模式的主要優點在於可以降低系統的耦合度,簡化對象的相互連接,同時增強給對象指派職責的靈活性,增加新的請求處理類也很方便;其主要缺點在於不能保證請求一定被接收,且對於比較長的職責鏈,請求的處理可能涉及到多個處理對象,系統性能將受到一定影響,而且在進行代碼調試時不太方便。

優點:

  • 降低耦合度
  • 可簡化對象的相互連接
  • 增強給對象指派職責的靈活性
  • 增加新的請求處理類很方便
缺點:
  • 不能保證請求一定被接收。
  • 系統性能將受到一定影響,而且在進行代碼調試時不太方便(可能會造成循環調用)

參考

  1. 設計模式之三職責鏈模式
  2. 重溫設計模式(三)——職責鏈模式(chain of responsibility)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章