觀察者模式：定義了物件之間的一對多依賴，這樣一來，當乙個物件改變狀態時，它的所有依賴者都會收到通知並自動更新
這種模型很像 報紙或雜誌的訂閱，把報社看成是乙個物件，那麼訂閱報紙的人就是報社的依賴者，報社和訂閱者之間存在一種一對多的依賴關係，當報社出版報紙的時候訂閱者將會收到報社寄來的報紙
觀察者模型會用到一些oo的設計原則：
觀察者模型的框架：
或許你對這些原則還不太清楚，沒關係，我們將會在下面這個例項中一一解釋
專案名稱：模擬氣象站
專案描述：我們需要根據某氣象局提供的天氣資料做出三個公告板，目前狀況（氣溫，濕度，氣壓）公告板，天氣統計公告板，天氣預報公告板
專案分析：根據上面的描述，我們不需要知道這些天氣資料是如何被設定的，只需要關心當氣象站更新天氣時我們的這三個公告板會自動更新上面的資料顯示，
公告板和氣象局之間存在一對多的依賴關係，這時觀察者模型就適用於這個專案，公告板是觀察者，氣象站是主題
專案設計（使用觀察者模型）：
根據模型的框架，我們的專案模型設計如圖：
下面我們就對照oo的幾個設計原則對這個設計圖進行分析：
依照oo的設計原則一，找出這個專案中變化的部分，首先是主題狀態的變化（也就是天氣資料的變化），依次是觀察者數目的變化（如果有需要還可新增更多的公告板），我們把這些變化的部分單獨提出來。如圖上看，主題和觀察者分別是不同的介面。
原則二，針對介面程式設計，在這個專案中建了三個介面，subject,observer,displayelement,
觀察者currentcoditionsdisplay中宣告了suject的介面變數，呼叫registerobverser(this)為自己註冊為觀察者，因為觀察者一直使用的都是主題的介面，它並沒有去實現介面，這就是針對介面程式設計。在最後的測試類weatherstation中才去例項化weatherdata，並把這個值傳給currentcoditionsdisplay的構造方法上
主題 weatherdata （implements suject）中的宣告了observer介面佇列和observer變數，也是一直使用介面，在測試類weatherstation中才例項化了currentcoditionsdisplay類，把weatherdata傳給它，然後在currentcoditionsdisplay的registerobverser(this)中把自己傳給weatherdata
原則三，多用組合，顯然在這個專案中的多個觀察者是通過組合把主題聯絡在一起的
原則四，物件的松耦合，當兩個物件通過松耦合聯絡在一起時，它們依然可以互相的互動，但是它們不太清楚對方的細節
對於主題來說，它只知道觀察者實現了哪個介面（observer），它只需要去使用這個介面，它並不知道具體的觀察者是誰或者哪些具體的觀察者實現了這個介面，主題唯一依賴的只是observer這個介面而已，這樣一來，主題和觀察者之間耦合度就變小了，以至於專案可以隨時新增或刪除觀察者，但並不會影響到主題的**
同樣對於觀察者來說，它也是唯一依賴於subject這個介面，當主題改變時也並不會影響到觀察者
本文到這裡已全部結束，恭喜你！又學到了一點新的內容！
注：本文中所有全都來自《head first設計模式》一書中的截圖
參考：《head first設計模式》
python 設計模式 觀察者 觀察者設計模式
在觀察者設計模式這種模式中，物件被表示為等待事件觸發的觀察者。一旦發生指定的事件，觀察者就會關注該主體。當事件發生時，主體告訴觀察者它已經發生。以下uml圖表示觀察者模式 如何實現觀察者模式？現在讓我們來看看如何實現觀察者模式。參考以下實現 import threading import time ...
設計模式 觀察者模式
觀察者模式定義了物件間一對多的依賴關係，乙個物件發生變化時，所有依賴它的物件都得到通知並被自動更新。本文主要闡述觀察者模式在分布式scada人機介面中的使用，利用這種模式使得人機介面顯示效率更高。發布者 郵局 觀察者 參與者 讀者 訂閱者 當郵局收到報社新雜誌的時候，即郵局狀態發生了改變，於是郵局把...
設計模式 觀察者模式
核心思想 註冊 通知 撤銷註冊 observer 將自己註冊到被觀察物件 subject 中，被觀察物件將觀察者存放在乙個容器 container 裡。被觀察物件發生了某種變化 如圖中的somechange 從容器中得到所有註冊過的觀察者，將變化通知觀察者。觀察者告訴被觀察者要撤銷觀察，被觀察者從容...