職責鏈模式，屬于行為型模式。

行為型模式用于描述程序在運行時復雜的流程控制，即描述多個類或對象之間怎樣相互協作共同完成單個對象都無法單獨完成的任務，它涉及算法與對象間職責的分配。（字面意思可能有點難理解，可以比如為一個團隊，每個人怎么配合，怎么分工才能完成一件事情）

責任鏈模式（Chain of Responsibility Pattern）為請求創建了一個接收者對象的鏈。這種模式給予請求的類型，對請求的發送者和接收者進行解耦。

這里需要注意幾個名詞：”接受者對象的鏈“，”發送者和接收者解耦“。

UML圖：

職責鏈模型

下面以公司員工請假作為說明。見下圖：

員工請假

圖中，描述的很直觀，員工請假，每個領導的權限不一樣，比如小組長只能批1天假，經歷能批3天的假，董事長能批15天的假等等。圖中說明：

1：”請假人“ ?為發送者，發送請假申請。
2：”虛線里面的各個領導“ ? 是接收者。
3：而”虛線里面的各個領導“ ?又組成了一個“領導鏈“（因為請假需要各級領導簽字審批）
4：而 ”請假人“ 和 ”領導鏈“ 之間是又是解耦的，因為“請假人”并不知道“領導鏈”中的具體結構，請假審批到哪一步等等，”請假人“也并不需要關心。

下面以上面的例子做今天的代言演示，這里肯定需要有一個請假人，領導鏈（重點）：

發起者（請假人）：

請假人，以及請假理由和天數

接收者（領導鏈）：

領導抽象類

（這里的鏈通過類中有其自身來完成。比如組長的上級領導是經理，經理的上級領導是董事長等）

組長繼承領導抽象類，組長的職能是批一天以內的假

經理繼承領導抽象類，經理的只能是批3天以內的假

測試類：

測試結果

測試類中，請假人都調用了boss對象（teamleader）的handler方法就行，而每個領導的職能又不一樣，所以批準的領導也不一樣。

以上例子?

對于客戶端來說，得到的只是Boss對象， 而這個boss對象是teamleader向上轉型得到，還是ManagerLeader向上轉型得到，客戶端是不關心的，只需要Boss對象就能做請假（handler()）就行。

對于服務端來說，組裝好自己的“領導鏈”，各個層級有不同的職責，非常符合單一職責原則；對客戶端來說這些內部結構是不透明的；

這樣客戶端和服務端得到了真正的解耦。

在java中用到職責模式也有很多：

1：structs中的action。
2：spring中配置interceptor攔截路勁。
3：javaweb 里面的filter