⑴ 觀察者模式(Observer Pattern)
觀察者模式又稱為發布訂閱模式。一個發布者對應多個訂閱者，一旦發布者的狀態發生改變時，訂閱者將收到訂閱事件。
先看看一個生活中的例子：
我們使用想瀏覽Java相關的文章，於是我們點擊訂閱了薯團［Java專題］，當［Java專題］有新文章發布就會推送給我們，當然其他人也可以訂閱［Java專題］並收到［Java專題］的推送。這就是觀察者。 定義對象間的一對多關系，當一個對象的狀態發生變化時，所依賴於它的對象都得到通知並主動更新。在觀察者模式中，多個訂閱者成為觀察者(Observer)，被觀察的對象成為目標(Subject)。
實現觀察者模式的方法不只一種，但是以包含Subject與Observer介面的類設計的做法最常見。（Java API 內置觀察者模式用的是Observer介面與Observable類）
觀察者模式UML圖：
先定義觀察者模式數源橘的介面
在觀察者模式的實現上，有推模式和拉模式兩種方式。
上面例子中
void updateByPush(Object obj) 就是推模式；
void updateByPull(Subject subject)就是拉模式
java.util包內包含最基本的Observer介面與Observable類（其實對應的就是Subject類）
我們看一下Observer源碼
我們看到update更新方法有兩個參數：Observable、Object，可見Java API 內置觀察者模式同時支持［拉］和［取］
我們再來看看Observable類源碼
注意Observable是一個類，而不是介面，這有一定的局限性。因為如果某個類想同時具有Observable類和另一個超類的行為，就會陷入兩難，畢竟Java不支持多重繼承。
有點需要特別提一下的就是，Java API 內置的Observable需要調用一下 setChanged();觀察者才能收到推送，我們看一下源碼，發現notifyObservers方法里有判斷changed的狀態為true才去通知觀察者。
我們自己實現觀察者模式的時候是沒有這一點的，那加上這一個標志位有什麼好處？好處就是更靈活，Observable類只提供這個boolean值來表明是否發生變化，而不定義什麼叫變化，因為每個業務中對變化的具體定義不一樣，因此子類自己來判斷是否變化；該變數既提供了一種抽象(變與不變)，同時提供了一種觀察者更新狀態的可延遲載入，通裂顫過後面的notifyObservers方法分析可知觀察者是否會調用update方法，依賴於changed變數，因此即使被觀察者在邏輯上發生改變了，只要不調用setChanged，update是不會被調用的。如果我們在某些業務場景不需要頻繁觸發update，則可以適時調用setChanged方法來延遲刷新。
阿里雲折扣快速入口
⑵ 觀察者模式基本簡介
觀察者模式，作為一種設計模式，其核心理念是將觀察者與被觀察對象分離，確保了兩者之間的獨立性。以一個簡單的場景為例，想像用戶界面作為一個獨立的觀察者，而業務數據則是需要被監測的對象。當業務數據發生變化時，用戶界面能夠即時察覺並相應地更新顯示。這種模式遵循面向對象設計的一個基本原則，即每個類專注於單一功能，避免了不必要的復雜性，讓代碼更易於理解和維護。
觀察者模式強調了職責的明確劃分，使得模塊之間的交互更加清晰。每個類只負責自身的任務，提高了應用程序的可重用性，當需要對業務數據進行修改或增加新的顯示邏輯時，只需要對觀察者進行相應的調整，而不會影響到被觀察者本身。這種設計策略有利於代碼的擴展和優化，使得軟體系統更加穩定和高效。
觀察者模式（有時又被稱為發布-訂閱模式、模型-視圖模式、源-收聽者模式或從屬者模式）是軟體設計模式的一種。在此種模式中，一個目標物件管理所有相依於它的觀察者物件，並且在它本身的狀態改變時主動發出通知。這通常透過呼叫各觀察者所提供的方法來實現。此種模式通常被用來實作事件處理系統。