職責鏈模式

1概述

當乙個請求，有多個處理物件時，如果硬編碼指定某個由某個物件來處理，需要採用ifelse的結構，從而產生了**的耦合，如果要新增新的請求處理物件或調整請求處理的次序，必然會修改同乙個方法，違背開閉原則。

2 gof中的定義

意圖：  

使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它為止。

結構圖：

適用性：

1>有多個的物件可以處理乙個請求，哪個物件處理該請求執行時刻自動確定。

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

3>解耦ifelse，將處理物件組織乙個鏈並希望處理的次序由客戶端來定義；

3專案中的例子

在簡單的審批處理中，經理與總經理有著不同的處理級別。比如，在請假審批中，經理可以批准3天的，而當要請假5天時需要總經理審批。在這裡，我們定義請假3天的級別為3，請假5天的級別為5。

4緊耦合的實現

**：

public

class
manager
else}}
static
void main(string
args)

5松耦合的實現

**：

///

///處理請求物件的基類
/// public
abstract
class
manager
//////
請求處理方法，由子類實現
/// ///
public
abstract
void handelrequest(int
reqlevel);
}//////
經理 
/// public
class
nomalmanager:manager
：同意請假
", this
.gettype().name);
}else
if (nexthander != null
) }}
//////
總經理 
/// public
class
generalmanager:manager
：同意請假
", this
.gettype().name);
}else
if (nexthander != null
) }}
static
void main(string
args)

6總結

職責鏈模式解決的是將ifelse解耦，但它與策略模式不同，它將行為物件組織成乙個鏈式結構來處理請求，一步步向後處理。很明顯這樣做會浪費一些效能，如載入了一些不會用的到類（因為只有乙個對物件才會處理某個請求），另外如果請求只有最後乙個才能處理，要經過之前的層層判斷才會至最後乙個。但是在一些業務系統中，這樣的做會更加容易理解與維護。

職責鏈模式

1.職責鏈 namespace dutychainpattern 用來處理請求 public abstract void transmitrequest int request 班主任 職責鏈上的乙個節點，在裡面進行判斷，看能否處理請求，不能則將請求轉移 public class classadvi...

職責鏈模式

軟體領域中的設計模式為開發人員提供了一種使用專家設計經驗的有效途徑。設計模式中運用了物件導向程式設計語言的重要特性 封裝 繼承 多型，真正領悟設計模式的精髓是可能乙個漫長的過程，需要大量實踐經驗的積累。最近看設計模式的書，對於每個模式，用c 寫了個小例子，加深一下理解。主要參考 大話設計模式 和 設...

職責鏈模式

劇情簡要 學習此模式，讓筆者聯想到自然界的生物鏈。打個比方 大魚吃小魚，小魚吃蝦公尺。河裡的小蝦公尺問大魚，你要不要吃我啊？大魚說 你太小了，吃了 沒吃，return 懶得吃！然後蝦公尺又問小魚 小螃蟹 小河馬同樣的問題。其實如果小蝦公尺這麼想自我了結的話，根本不用這麼費勁。這就開始了我們職責鏈模式...