在現實生活中，有很多請求並不是乙個人說了就算的，例如面試時的工資，低於1萬的薪水可能技術經理就可以決定了，但是1萬~1萬5的薪水可能技術經理就沒這個權利批准，可能就需要請求技術總監的批准，所以在面試的完後，經常會有面試官說，你這個薪水我這邊覺得你這技術可以拿這個薪水的，但是還需要技術總監的批准等的話。這個例子也就詮釋了本文要介紹的內容。生活中的這個例子真是應用了責任鏈模式。
從生活中的例子可以發現，某個請求可能需要幾個人的審批，即使技術經理審批完了，還需要上一級的審批。這樣的例子，還有公司中的請假，少於3天的，直屬leader就可以批准，3天到7天之內就需要專案經理批准，多餘7天的就需要技術總監的批准了。介紹了這麼多生活中責任鏈模式的例子的，下面具體給出物件導向中責任鏈模式的定義。
責任鏈模式指的是——某個請求需要多個物件進行處理，從而避免請求的傳送者和接收之間的耦合關係。將這些物件連成一條鍊子，並沿著這條鍊子傳遞該請求，直到有物件處理它為止。
從責任鏈模式的定義可以發現，責任鏈模式涉及的物件只有處理者角色，但由於有多個處理者，它們具有共同的處理請求的方法，所以這裡抽象出乙個抽象處理者角色進行**復用。這樣分析下來，責任鏈模式的結構圖也就不言而喻了，具體結構圖如下所示。
主要涉及兩個角色：
有了上面的介紹，下面以公司採購東西為例子來實現責任鏈模式。公司規定，採購架構總價在1萬之內，經理級別的人批准即可，總價大於1萬小於2萬5的則還需要副總進行批准，總價大於2萬5小於10萬的需要還需要總經理批准，而大於總價大於10萬的則需要組織乙個會議進行討論。對於這樣乙個需求，最直觀的方法就是設計乙個方法，引數是採購的總價，然後在這個方法內對**進行調整判斷，然後針對不同的條件交給不同級別的人去處理，這樣確實可以解決問題，但這樣一來，我們就需要多重if-else語句來進行判斷，但當加入乙個新的條件範圍時，我們又不得不去修改原來設計的方法來再新增乙個條件判斷，這樣的設計顯然違背了「開-閉」原則。這時候，可以採用責任鏈模式來解決這樣的問題。具體實現**如下所示。
namespace chainofresponsibility
// 產品名字
public string productname
public purchaserequest(double amount, string productname)
}// 審批人,handler
public abstract void processrequest(purchaserequest request);
}// concretehandler
public override void processrequest(purchaserequest request)}}
// concretehandler,副總
public override void processrequest(purchaserequest request)}}
// concretehandler，總經理
public override void processrequest(purchaserequest request)
else}}
class program}}
在以下場景中可以考慮使用責任鏈模式：
責任鏈模式的優點不言而喻，主要有以下點：
責任鏈模式也具有一定的缺點，如：
責任鏈降低了請求端和接收端之間的耦合，使多個物件都有機會處理某個請求。如考試中作弊傳紙條，泡妞傳情書一般。在下一章將繼續分享訪問者模式。
設計模式之 責任鏈模式
在一些情況下，對乙個訊息 含事件 的響應和處理需要很多物件來參與，這些物件對訊息的處理有前後順序，形成乙個處理鏈條，但物件是否真正處理訊息有賴於在它之前的物件的處理策略，前乙個物件處理後，後乙個物件則不需參與處理，這就是責任鏈模式。現實中有很多類似的場景，比如上訪，上訪一般是從最基層的信訪部門接受信...
設計模式之（責任鏈模式）
chain of responsibleity 責任鏈模式 在責任鏈模式 中，很多物件由每乙個物件對其下家的引用而接。起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某乙個物件決定處理此請求。客戶並不知道鏈上的哪乙個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者...
設計模式之責任鏈模式
假設現在乙個公司的請假流程如下 一天及以下由小組組長審批，一天以上三天以下由經理審批，三天以上七天以下由老闆審批，七天以上直接勸退。如果每次請假時都很長的if else 來判斷該去找誰請假，很不容易擴充套件，我們使用責任鏈模式來實現。首先，是乙個抽象的父類 public abstract class...