訂閱報紙的栗子
1）報社的業務是出版報紙
2）你向某家報社訂閱他們的報紙，然後你就成為了他們的訂閱使用者，
只要報社有新的報紙出版，就會將報紙傳送給你
3）當你取消訂閱報紙時，你就從報社的訂閱使用者中刪除，報社就不會再傳送報紙給你
4）只要報社還在運營，就會一直有人訂閱或取消訂閱報紙
一般我們稱上慄中的報社為「主題」，稱訂閱使用者為「觀察者」。
1）主題用於管理某些資料，一旦資料發生改變，新的資料就會傳送到觀察者手中
2）在主題資料發生改變時，只有訂閱主題的觀察者才能收到更新的資料
3）當新的物件訂閱主題時，它會成為乙個觀察者，它可以收到主題更新的資料
4）當某個觀察者取消訂閱主題時，它不會再收到主題更新的資料
主題與觀察者的圖（待補。。。）
概念
定義了物件之間一對多的依賴關係，當乙個物件的狀態發生改變時，它所有的依賴者都會收到通知並更新資料。
uml類圖
uml類圖說明
1）主題介面，物件使用此介面註冊觀察者，刪除觀察者和更新觀察者的狀態
2）觀察者介面，所有的潛在觀察者必須實現此介面，其中只有乙個update()方法，當主題狀態發生變化時，它將被呼叫；
每個主題可以有多個觀察者
3）乙個具體的主題總是實現主題介面，並實現其註冊觀察者，刪除觀察者和更新觀察者的狀態的方法；
具體的方法也可以有設定/獲取狀態的方法。
4）具體的觀察者可以是實現觀察者介面的任意類，觀察者必須註冊具體的主題，以便接收和更新資料。
那麼說下什麼是松耦合
有兩個相互依賴的物件，改變其中的一方並不會影響另一方，只要它們的介面仍被遵守，
我們就可以自由的改變它們。
主題與觀察者之間松耦合，它們可以互動，但是不清楚彼此的細節,
對於觀察者，主題只需知道觀察者實現了某個介面，並不需要知道觀察者的具體類是誰，做了什麼等細節
主題唯一依賴的東西是乙個實現observer介面的物件列表，所以我們可以隨時增加、刪除觀察者，用新的觀察者取代現有的觀察者，
主題不會受到任何影響。
當有新型別的觀察者出現時，主題並不需要修改**
v需要做的是新的型別實現此觀察者的介面
然後註冊成為觀察者即可
v主題只傳送通知給實現此觀察者介面的物件
如果我們需要使用觀察者和主題，可以輕易的復用它們
松耦合的優點
將物件之間的相互依賴降到了最低，能夠應對變化，進而可以建立有彈性的物件導向系統。
案例需求
建立乙個氣象站，該氣象站必須建立在我們申請的weatherdata物件上，
由weatherdata物件追蹤目前的天氣狀況（溫度，濕度，氣壓），
有三種佈告板，分別顯示目前的狀況、氣象統計和簡單的預報，
當weatherobject物件獲得最新的測量資料時，三種布告必須實時更新。
分析weatherdata原始檔
1）通過weatherdata 可以獲取三個測量值：溫度、濕度和氣壓
2） 一旦氣象測量資料更新，measurementschanged()方法會被呼叫
3）需要實現3個使用天氣資料的佈告板：目前狀況佈告板、氣象統計佈告板和天氣預報佈告板，一旦weatherdata有新的資料，它們立即更新
4）此系統必須可擴充套件，比如其他開發人員可增加或刪除任何佈告板
有人認為直接把觀測值傳入觀察者中更新狀態是最直接的方法，但是這種形式會有很多隱患，
比如，觀察者種類的個數可能發生改變，如果這樣，我們只能修改更多的**去滿足這些變化，
但是這並不是我們想看到的
參考p57
那麼將更新的狀態傳給觀察者，有什麼好的解決方案呢？
uml類圖設計
python 設計模式 觀察者 觀察者設計模式
在觀察者設計模式這種模式中，物件被表示為等待事件觸發的觀察者。一旦發生指定的事件，觀察者就會關注該主體。當事件發生時，主體告訴觀察者它已經發生。以下uml圖表示觀察者模式 如何實現觀察者模式？現在讓我們來看看如何實現觀察者模式。參考以下實現 import threading import time ...
觀察者設計模式
觀察者模式定義了一種一對多的依賴關係，讓多個觀察者物件同時監聽某乙個主題物件。這個主題物件在狀態上發生變化時，會通知所有觀察者物件，讓它們能夠自動更新自己。抽象主題角色 subject 把所有對觀察者物件的引用儲存在乙個集合中，每個抽象主題角色都可以有任意數量的觀察者。抽象主題提供乙個介面，可以增加...
設計模式 觀察者
1.核心 觀察者模式主要用於1 n的通知。當乙個物件 目標物件subject或者objservable 的狀態變化時，需要告知一系列物件 觀察者物件，observer 讓他們做出響應 通知觀察者的方式 推 每次都把通知以廣播的方式傳送給所有觀察者，所有觀察者只能被動接收 拉 觀察者知道有訊息，至於什...