深入淺出觀察者模式：從訂閱報紙理解鬆耦合設計

什麼是觀察者模式？

觀察者模式定義了物件之間的一對多依賴關係，當一個主題物件狀態改變時，所有依賴它的觀察者都會收到通知並自動更新。這是《Head First 設計模式》中最經典的模式之一，核心在於「發布-訂閱」機制。

生活化類比：報社與訂閱者

想像你訂閱了《人民日報》：

• 一對多依賴：報社不只你一個訂閱者，擁有成千上萬的讀者。
• 狀態變更通知：報社每天出版新報（主題狀態改變）。
• 自動更新：報社將新報送達每位訂閱者，讀者獲取最新資訊（觀察者收到通知並更新）。

在這個模型中，《人民日報》是主題，你和其他讀者是觀察者。觀察者不需要知道報社內部運作細節，只需等待報紙送達；報社也不關心具體哪個讀者，只管按名單投遞。

核心設計原則

1. 找出變化點，封裝變化

主題與觀察者之間是鬆耦合關係：

• 觀察者取消訂閱時，主題無需修改代碼，只需從名單移除該觀察者。
• 主題內容變更時，不需修改觀察者代碼；觀察者增減時，主題邏輯不變。

2. 針對介面程式設計，而非實作

所有觀察者實作共同介面，主題僅依賴此介面發送通知，不直接依賴具體觀察者類別。正如報社只認「報刊介面」，不管訂閱者是個人、圖書館還是咖啡廳。

觀察者模式關鍵要點總結

• 定義物件間一對多關係
• 主題透過共同介面更新觀察者
• 主題與觀察者鬆耦合，主題不知觀察者細節
• 推薦使用「推模型」（主題主動推送資料），而非「拉模型」（觀察者主動取資料）
• 多觀察者時，不依賴特定通知順序
• Java 內建 java.util.Observable 但違反「針對介面程式設計」原則，有局限性
• 手動實作觀察者模式很簡單，彈性更高
• Swing 事件監聽機制（如按鈕點擊）大量應用此模式

何時使用觀察者模式？

當系統中有多個物件需對某物件狀態變化做出反應，且不希望這些物件緊密耦合時，觀察者模式是最佳選擇。典型場景包括：GUI 事件處理、訊息推送系統、快取失效通知、股價監控等。