要想正確理解設計模式，首先必須明確它是為了解決什么問題而提出來的。
設計模式學習筆記，歡迎交流。
——Shulin
轉載請注明出處：http://blog.csdn.net/zhshulin
觀察者模式是對象的行為模式，外號非常多...??！又叫發布-訂閱(Publish/Subscribe)模式、模型-視圖(Model/View)模式、源-監聽器(Source/Listener)模式或從屬者(Dependents)模式。
觀察者模式定義了一種一對多的依賴關系，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態上發生變化時，會通知所有觀察者對象，使它們能夠自動更新自己。
被觀察者對象在狀態變化時，通知所有觀察者對象，使它們能夠自動更新自己。保證整體的數據一致性。此種模式通常被用來實現事件處理系統。
適用性：
1）. 當一個抽象模型有兩個方面,其中一個方面依賴于另一方面。將這二者封裝在獨立的對 象中以使它們可以各自獨立地改變和復用。
2）. 當對一個對象的改變需要同時改變其它對象,而不知道具體有多少對象有待改變。
3）. 當一個對象必須通知其它對象，而它又不能假定其它對象是誰。
? 抽象主題(Subject)角色：
抽象主題角色把所有對觀察者對象的引用保存在一個聚集（比如ArrayList對象）里，每個主題都可以有任何數量的觀察者。抽象主題提供一個接口，可以增加和刪除觀察者對象，抽象主題角色又叫做抽象被觀察者(Observable)角色。
? 具體主題(ConcreteSubject)角色：
將有關狀態存入具體觀察者對象；在具體主題的內部狀態改變時，給所有登記過的觀察者發出通知。具體主題角色又叫做具體被觀察者(Concrete Observable)角色。
? 抽象觀察者(Observer)角色：
為所有的具體觀察者定義一個接口，在得到主題的通知時更新自己，這個接口叫做更新接口。
? 具體觀察者(ConcreteObserver)角色：
存儲與主題的狀態自恰的狀態。具體觀察者角色實現抽象觀察者角色所要求的更新接口，以便使本身的狀態與主題的狀態 像協調。如果需要，具體觀察者角色可以保持一個指向具體主題對象的引用。
該實例模擬了燒水的過程，涉及三個對象，Heater(熱水器)，Display（顯示器），Alarm(報警器)。模擬過程：為了便于運行，水的初始化溫度為90，沸點為100，顯示器依據熱水器顯示溫度，顯示器顯示溫度為100時，報警器開始報警。明顯可以看出Heater是subject ,Display 是它的 Obsrver，同時Display亦是subject，因為它要被報警器觀察，所以Alarm是Display的Observer.
（PS：如果不知道各種符號的意思，看這里——http://blog.csdn.net/zhshulin/article/details/18088633）
Subject：抽象被觀察者
[java] view plain copy PRint?package org.zsl.designmodel.observer; import java.util.ArrayList; import java.util.List; /** * 被觀察者角色 * @author ZSL * */ public abstract class Subject { private List<Observer> list = new ArrayList<Observer>(); /** * 注冊觀察者對象 * @param observer 觀察者 */ public void registerObserver(Observer observer){ list.add(observer); System.out.println("注冊了一個觀察者角色！"); } /** * 刪除觀察者對象 * @param observer 觀察者 */ public void removeObserver(Observer observer){ list.remove(observer); } /** * 通知所有注冊的觀察者對象，我的狀態改變咯 * @param newState */ public void notifyAllObservers(String newState){ for(Observer observer : list){ observer.update(newState); } } }Observer ：觀察者接口，只有一個update()方法
[java] view plain copy print?package org.zsl.designmodel.observer; /** * 觀察者接口 * @author ZSL * */ public interface Observer { /** * 更新接口 * @param state 更新的狀態 */ public void update(String state); }Heater：熱水器，一個具體被觀察者
[java] view plain copy print?package org.zsl.designmodel.observer; public class Heater extends Subject { private int temperature; public int getTemperature() { return temperature; } public void setTemperature(int temperature) { this.temperature = temperature; } public void boilWater(){ for(int i=95;i<105;i++){ temperature = i; this.setTemperature(temperature); //設置新的溫度 this.notifyAllObservers(Integer.toString(temperature)); //通知所有注冊的觀察者 } } }Display：既是觀察者，又是被觀察者
[java] view plain copy print?package org.zsl.designmodel.observer; /** * 顯示器，既是觀察者又是被觀察者 * @author Administrator * */ public class Display extends Subject implements Observer { private boolean isBoiled = false; //表示水是否燒開了 private int displayTemperature; //定義顯示器的溫度 public boolean isBoiled() { return isBoiled; } public void setBoiled(boolean isBoiled) { this.isBoiled = isBoiled; } @Override public void update(String state) { displayTemperature = Integer.parseInt(state); System.out.println("當前顯示器顯示的溫度是："+displayTemperature); this.displayTemperature(displayTemperature); } private void displayTemperature(int temperature){ if(temperature>100){ this.setBoiled(true); this.notifyAllObservers(Boolean.toString(isBoiled)); } } }Alerm：只是觀察者
[java] view plain copy print?package org.zsl.designmodel.observer; public class Alarm implements Observer { private String observerState; //定義觀察者的狀態 @Override public void update(String state) { Boolean flag = Boolean.parseBoolean(state); if(flag){ System.out.println("報警器響了，水溫超過100度了。"); } } }測試
[java] view plain copy print?package org.zsl.designmodel.observer; public class Test { public static void main(String[] args) { Heater heater = new Heater(); Display display = new Display(); Alarm alarm = new Alarm(); heater.registerObserver(display); display.registerObserver(alarm); heater.boilWater(); } }結果：
a、支持松耦合和減少依賴性
客戶端不再依賴于觀察器，因為通過使用主體和 Observer 接口對客戶端進行了隔離。 許多框架具有此優點，在這些框架中的應用程序組件可以注冊為當（低級）框架事件發 生時得到通知。結果，框架將調用應用程序組件，但不會依賴于它。
b、提高了應用程序的可維護性和重用性
面向對象設計的一個原則是：系統中的每個類將重點放在某一個功能上，而不是其他方面。一個對象只做一件事情，并且將他做好。觀察者模式在模塊之間劃定了清晰的界限，提高了應用程序的可維護性和重用性。
c、觀察器數目可變
觀察器可以在運行時附加和分離，因為主體對于觀察器數目沒有任何假定。此功能在這樣的情況下是很有用的：觀察器數在設計時是未知的。例如，如果用戶在應用程序中打開的每個窗口都需要一個觀察器。
a、性能降低。
在許多實現中，觀察器的 update() 方法可能與主體在同一線程中執行。如果觀察器列表很長，則執行 Notify() 方法可能需要很長時間。抽取對象依賴性并不意味著添加觀察器對應用程序沒有任何影響。
b、內存泄漏。
在 Observer 中使用的回調機制（當對象注冊為以后調用時）會產生一個常見的錯誤，從而導致內存泄漏，甚至是在托管的 C# 代碼中。假定觀察器超出作用范圍，但忘記取消對主體的訂閱，那么主體仍然保留對觀察器的引用。此引用防止垃圾收集在主體對象也被破壞之前重新分配與觀察器關聯的內存。如果觀察器的生存期比主體的生存期短得多（通常是這種情況），則會導致嚴重的內存泄漏。
c、隱藏的依賴項。
觀察器的使用將顯式依賴性（通過方法調用）轉變為隱式依賴性（通過觀察器）。如果在整個應用程序中廣泛地使用觀察器，則開發人員幾乎不可能通過查看源代碼來了解所發生的事情。這樣，就使得了解代碼更改的含意非常困難。此問題隨傳播級別急劇增大（例如，充當 Subject 的觀察器）。因此，應該僅在少數定義良好的交互（如 Model-View-Controller 模式中模型和視圖之間的交互）中使用觀察器。最好不要在域對象之間使用觀察器。
d、測試 / 調試困難。
盡管松耦合是一項重大的體系結構功能，但是它可以使開發更困難。將兩個對象去耦的情況越多，在查看源代碼或類的關系圖時了解它們之間的依賴性就越難因此，僅當可以安全地忽略兩個對象之間的關聯時才應該將它們松耦合（例如，如果觀察器沒有副作用）。
新聞熱點
疑難解答
