職責鏈模式

uml類圖：

職責鏈模式(chain of responsibility pattern)：避免請求傳送者與接收者耦合在一起，讓多個物件都有可能接收請求，將這些物件連線成一條鏈，並且沿著這條鏈傳遞請求，直到有物件處理它為止。職責鏈模式是一種物件行為型模式。

● handler（抽象處理者）：它定義了乙個處理請求的介面，一般設計為抽象類，由於不同的具體處理者處理請求的方式不同，因此在其中定義了抽象請求處理方法。因為每乙個處理者的下家還是乙個處理者，因此在抽象處理者中定義了乙個抽象處理者型別的物件（如結構圖中的successor），作為其對下家的引用。通過該引用，處理者可以連成一條鏈。

● concretehandler（具體處理者）：它是抽象處理者的子類，可以處理使用者請求，在具體處理者類中實現了抽象處理者中定義的抽象請求處理方法，在處理請求之前需要進行判斷，看是否有相應的處理許可權，如果可以處理請求就處理它，否則將請求**給後繼者；在具體處理者中可以訪問鏈中下乙個物件，以便請求的**。

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

職責鏈模式優缺點：

1.主要優點

(1) 職責鏈模式使得乙個物件無須知道是其他哪乙個物件處理其請求，物件僅需知道該請求會被處理即可，接收者和傳送者都沒有對方的明確資訊，且鏈中的物件不需要知道鏈的結構，由客戶端負責鏈的建立，降低了系統的耦合度。

(2) 請求處理物件僅需維持乙個指向其後繼者的引用，而不需要維持它對所有的候選處理者的引用，可簡化物件的相互連線。

(3) 在給物件分派職責時，職責鏈可以給我們更多的靈活性，可以通過在執行時對該鏈進行動態的增加或修改來增加或改變處理乙個請求的職責。

(4) 在系統中增加乙個新的具體請求處理者時無須修改原有系統的**，只需要在客戶端重新建鏈即可，從這一點來看是符合「開閉原則」的。

2.主要缺點

職責鏈模式的主要缺點如下：

(1) 由於乙個請求沒有明確的接收者，那麼就不能保證它一定會被處理，該請求可能一直到鏈的末端都得不到處理；乙個請求也可能因職責鏈沒有被正確配置而得不到處理。

(2) 對於比較長的職責鏈，請求的處理可能涉及到多個處理物件，系統效能將受到一定影響，而且在進行**除錯時不太方便。

(3) 如果建鏈不當，可能會造成迴圈呼叫，將導致系統陷入死迴圈。

職責鏈模式適用場景：

在以下情況下可以考慮使用職責鏈模式：

(1) 有多個物件可以處理同乙個請求，具體哪個物件處理該請求待執行時刻再確定，客戶端只需將請求提交到鏈上，而無須關心請求的處理物件是誰以及它是如何處理的。

(2) 在不明確指定接收者的情況下，向多個物件中的乙個提交乙個請求。

(3) 可動態指定一組物件處理請求，客戶端可以動態建立職責鏈來處理請求，還可以改變鏈中處理者之間的先後次序。

#pragma once
#ifndef _handle_h_
#define _handle_h_
#include#define safe_delete(p) \
if(nullptr!=(p)) \
//抽象處理類
class handle
handle(handle* psuc=nullptr)
~handle()
{} virtual void handlerequest()=0;
virtual void setsuccessor(handle* m_suc)
protected:
handle* m_successor;
};class concretehandlea :public handle
~concretehandlea() }
virtual void handlerequest()
else
}};class concretehandleb :public handle
~concretehandleb() }
virtual void handlerequest()
else
}};class concretehandlec :public handle
~concretehandlec() }
virtual void handlerequest()
else
}};#endif

#include#include"handle.h"
using namespace std;
int main(void)

職責鏈模式

職責鏈模式

職責鏈模式

職責鏈模式

相關推薦