chain of responsibleity（責任鏈模式）：
在責任鏈模式 中，很多物件由每乙個物件對其下家的引用而接。起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某乙個物件決定處理此請求。客戶並不知道鏈上的哪乙個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。乙個請求可以最終不被任何接收端物件所接受。
打個有趣的比方：
—晚上去上英語課，為了好開溜坐到了最後一排，哇，前面坐了好幾個漂亮的mm哎，找張紙條，寫上「hi,可以做我的女朋友嗎？ 如果不願意請向前傳」，紙條就乙個接乙個的傳上去了，糟糕，傳到第一排的mm把紙條傳給老師了，聽說是個老**呀，快跑! （詳見見下圖第二種uml圖）
圖中上方的模型為傳統的設計模式：
由是用者按照既定的次序分別呼叫一系列的處理類，這樣這一系列的處理類就和呼叫者產生依賴關係。
圖中下方的責任鏈模式：
呼叫方從某乙個處理類呼叫，不和其他的類產生直接聯絡，由處理類將這種鏈式的處理關係依次想下傳遞，然後將結果返回給呼叫者，呼叫者根本不知道返回的結果都被那些處理中處理過。如果將這種鏈式關係維護在xml檔案中，這樣處理類之間的呼叫次序以及處理類的刪除和擴充套件都可以輕鬆實現。
設計模式之 責任鏈模式
在一些情況下，對乙個訊息 含事件 的響應和處理需要很多物件來參與，這些物件對訊息的處理有前後順序，形成乙個處理鏈條，但物件是否真正處理訊息有賴於在它之前的物件的處理策略，前乙個物件處理後，後乙個物件則不需參與處理，這就是責任鏈模式。現實中有很多類似的場景，比如上訪，上訪一般是從最基層的信訪部門接受信...
設計模式之責任鏈模式
假設現在乙個公司的請假流程如下 一天及以下由小組組長審批，一天以上三天以下由經理審批，三天以上七天以下由老闆審批，七天以上直接勸退。如果每次請假時都很長的if else 來判斷該去找誰請假，很不容易擴充套件，我們使用責任鏈模式來實現。首先，是乙個抽象的父類 public abstract class...
設計模式之責任鏈模式
一 定義 使多個物件都有接受請求的機會，而只有符合自己條件的物件才能處理這個請求。二 例項 2.1 例項 有乙個公司x，每乙個員工都有向公司借錢的機會，但是根據數目的不同需要的審批人也不同，比如1000到5000是等級1，只需要 研發組的小組長同意就行了，但是5000到10000是等級2，需要經理同...