學而時習之，溫故而知新。這句話用在設計模式上真是太恰當不過了！博主從上大二的時候就開始閱讀設計模式，當時對物件導向的思維理解的不是很深刻。所以一些設計模式弄得一知半解，只知其形而不知其神。工作之餘也沒有放棄過對設計模式的學習和琢磨，每次閱讀相關的設計模式總有不同的心得體會。收貨頗多。所以在此建議讀者也要時不時翻看下設計模式。從中演化出適合自己的模式出來。可以說設計模式是物件導向思維的集大成者。越閱讀越有味道。
閒言少敘，本篇博文就簡單的梳理下博主對責任鏈模式的理解和體會，如有不當之處歡迎批評指正。正規的責任鏈模式有如下兩點：
1、責任鏈一般有兩種物件，乙個是請求者。乙個是處理者。需要注意的是處理者是有可能返回處理結果給請求者的。查閱了好多篇關於責任鏈模式的文章，這點好像都沒有提及。
2、多個物件中，每個物件都持有下乙個物件的引用，這就構成了鏈這種結構。（但是一定要如此嗎？後面會有說明）
因為在**設計中我們會將處理者抽象出乙個介面，所以實現這個介面的處理者可能。
責任鏈模式的主要工作就是在眾多的處理者中找到能處理當前請求的那乙個處理者物件！所以具體的處理者需要持有下乙個處理者的引用！concretehandler1偽**如下：
public
class
concretehandler1
extends
handler
else
}}
list
handlers=
inithandlers()
;for
(handler currenthandler:handlers)
}
concretehandler1**的擴充套件，因為它比較靈活！concretehandler1在設計的時候需要指定下乙個處理者。而for迴圈遍歷的這種方式，我們只需要在inithandlers()初始化處理者集合的時候，合理的安排好集合中的順序即可將這種擊鼓傳花的遊戲玩下去。
考慮到另外乙個場景：公司的請假系統，需要層層批准,上乙個部分批准後需要把後續流程交個下乙個部門，這種工作模式最適合責任鏈模式。但是如果需要層層批准的話，那麼上面的偽**concretehandler1就不符合，因為它處理完屬於自己的工作後就不忘後傳了，所以就需要進行如下改造：
public
class
concretehandler1
extends
handler
}
在okhttp的***中，發起乙個網路請求，我們將請求封裝成request物件。交給***中的某個***，該***處理完自己的工作之後，根據具體業務邏輯判斷是否需要交給下乙個***。如果不需要，就將處理結果response物件返回給請求者！其流程圖如下圖所示：
到此為止，關於責任鏈模式的心得體會書寫完畢。後期可能隨著自己體會的不斷加深，該篇博文需要進行修改，敬請期待吧。
設計模式之 責任鏈模式
在一些情況下，對乙個訊息 含事件 的響應和處理需要很多物件來參與，這些物件對訊息的處理有前後順序，形成乙個處理鏈條，但物件是否真正處理訊息有賴於在它之前的物件的處理策略，前乙個物件處理後，後乙個物件則不需參與處理，這就是責任鏈模式。現實中有很多類似的場景，比如上訪，上訪一般是從最基層的信訪部門接受信...
設計模式之（責任鏈模式）
chain of responsibleity 責任鏈模式 在責任鏈模式 中，很多物件由每乙個物件對其下家的引用而接。起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某乙個物件決定處理此請求。客戶並不知道鏈上的哪乙個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者...
設計模式之責任鏈模式
假設現在乙個公司的請假流程如下 一天及以下由小組組長審批，一天以上三天以下由經理審批，三天以上七天以下由老闆審批，七天以上直接勸退。如果每次請假時都很長的if else 來判斷該去找誰請假，很不容易擴充套件，我們使用責任鏈模式來實現。首先，是乙個抽象的父類 public abstract class...