前言
假如有這樣一個需求：在一個請假流程中，同時需要領導A 、領導B、領導C審批，那麼我能將怎麼設計呢？當然是分別通知三個領導做審批了。於是我們就需要有一種機制，能夠同時通知到三個或者更多的領導，觀察者模式就是在類似於這樣場景下產生的。
觀察者模式圖解
1）觀察者模式的定義
觀察者模式定義一系列對象之間的一對多關係，當一個對象改變、更新狀態時，依賴它的都會收到通知改變或者更新。從定義中我們可以知道，在觀察者模式中，當被觀察對象改變時，其他依賴的對象都會收到改變信息的狀態。
2）何時使用觀察者模式
- 一個抽象模型有兩個方面，其中一個方面依賴於另一個方面。將這些方面封裝在獨立的對象中使它們可以各自獨立地改變和複用。
- 一個對象的改變將導致其他一個或多個對象也發生改變，而不知道具體有多少對象將發生改變，可以降低對象之間的耦合度。
- 一個對象必須通知其他對象，而並不知道這些對象是誰。
- 需要在系統中創建一個觸發鏈，A對象的行為將影響B對象，B對象的行為將影響C對像。這種情況下就可以使用觀察者模式創建一種鏈式觸發機制。
3）四大要素
- Subject被觀察者：定義被觀察者必須實現的職責，它必須能夠動態地增加、取消觀察者。它一般是抽象類或者是實現類，僅僅完成作為被觀察者必須實現的職責：管理觀察者並通知觀察者。
- Observer觀察者：觀察者接收到消息後，即進行update（更新方法）操作，對接收到的信息進行處理。
- ConcreteSubject具體的被觀察者：定義被觀察者自己的業務邏輯，同時定義對哪些事件進行通知。
- ConcreteObserver具體的觀察者：每個觀察在接收到消息後的處理反應是不同，各個觀察者有自己的處理邏輯。
具體實現
我們就以發起一個請假流程為例，王先生請假，需要A、B、C三個領導審批。首先創建觀察者 Observer 如下
Observer 接口
在這個接口中，定義了一個 approval() 方法,該方法用於審批所有的請假請求，當接收到通知時，會調動該方法，處理審批邏輯。真正的處理邏輯在它的三個實現類中，如下：
如上所示，三個領導 A、B、 C 分別實現了 Observer接口，並且處理自己的邏輯，當接到通知時，這個三個類會分別做處理。
下面定義被觀察者接口 Subject ，該接口中只是定義了一個 notice() 方法，用戶通知所有觀察者，做相應的處理。
Subject 接口
真正的被觀察者邏輯在 Subject 的實現類中，它可以添加、移除觀察者對象，並且提供處理真正的通知邏輯。在 notice() 方法中，會找到所有的觀察者，並將變化一一通知到他們，每個觀察者會在自己的處理邏輯中做處理。
Leave 類實現 Subject接口
OK，整個設計過程已經完成，我們開始測試，首先實例化 Abserver 接口的三個 實現類的對象，並通過 Leave 的 add() 方法將對象註冊進去，然後調動 notice() 方法，即可
三個領導分別做自己的處理邏輯。
總結
觀察者模式定義了對象間的一種一對多的依賴關係， 當一個對象的狀態發生改變時， 所有依賴於它的對象都得到通知並被自動更新，在實際開發中，觀察者模式使用的非常多，比如：監聽器、 日誌收集、 短信通知、郵件通知等。在 spring 中的 監聽器用的就是觀察者模式。
創作不易，轉載請聲明，如有意見、建議請在下方評論區留言！
