## 一、職責鏈模式
使對個對象都有機會處理請求,從而避免請求的發送者和接受者之間的耦合關系.將這個對象連成一條鏈,并沿著這條鏈傳遞該請求,直到有一個對象處理它為止。
客戶端發出的請求時,并不知道哪一個對象最終處理這個請求,請求只是沿鏈傳遞,直至有一個對象負責處理它,且鏈中的對象自己也并不知道鏈的結構。這樣系統的更改可以在不影響客戶端的情況下動態的重新組織和分配責任,簡化了對象的相互連接,他們僅需保持一個指向其后繼者的引用,而不需保持它所有的候選接受者的引用,這樣就降低了耦合度。
### 鏈的所在
我在理解這個模式時,覺得它之所以叫做職責鏈,最關鍵的是“鏈”這個字眼。從結構上來看,看下面的類圖,沒有什么特殊,一個個Handler類,幾個concreteHandler來繼承,并實現其功能。那么這個鏈體現在哪了呢?
在Handler類中的SetSuccessor方法。這個方法是用來設定后繼者的。就是通過這個方法,一個個對象被連在一起。
客戶發出一個請求,我們只需要給出處理請求鏈的開始端口,首個對象調用自己的HandRequest方法,解決了就結束請求,解決不了的請求,通過設定后繼者后傳,直到請求被解決。請求就這樣被傳遞了,這些都是自動發生的。
有個比喻不知道恰當不?老師不知道拿錯了誰的書,隨便找了這個班一個人,把書給他負責把書還給書主人,這個同學,到班里,把書按座位傳遞,傳到書主人那,就停止傳遞。按座位傳遞就是我們設定的職責鏈,每個同學就是一個個對象,書主人是最終處理請求的人。
## 二、類圖

問題:從ConcreteHandler到Handler為什么是聚合關系?
- 前言
- 抽象工廠——創建型設計模式一
- 工廠三姐妹——創建型設計模式之二
- 初識面向對象設計模式
- 建造者模式——創建型模式之三
- 原型模式——創建型設計模式四
- 適配器 and 組合模式——結構性模式之一
- 橋接模式——結構性設計模式之二
- 組合模式——結構型設計模式之三
- 裝飾模式——結構型設計模式之四
- 外觀模式——結構型設計模式之五
- 代理模式——結構型設計模式之六
- 觀察者模式——行為型設計模式之五
- 模板設計——行為設計模式之一
- 命令模式——行為設計模式之二
- 狀態模式——行為型設計模式之三
- 職責模式——行為設計模式之四
- 中介模式——行為模式之六
- 策略+簡單工廠 實戰篇
- 看觀察者怎么全方位觀察機房收費系統
- 登陸也需要裝飾——機房收費系統裝飾模式實戰
- 何為抽象?你有本末倒置嗎?
- 再回首,策略、簡單工廠是否依然?
- 再回首——行為型設計模式