1、Observer模式
《設計模式》一書中對Observer模式的意圖是這樣敘述的：定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都將得到通知並自動更新。
Observer模式並不是只要在對象間存在依賴關係時就要使用。例如，假設在一個票據處理系統中，有一個Tax對象處理繳稅問題，顯然當票據的項目增加時，Tax對象必須得到通知以便重新計算稅額。但這並不適合Observer模式，因爲這種通知事先已經知道，而且不可能再添加其他觀察者。當依賴關係固定（或實際上固定）時，引入Observer模式可能只會增加複雜性。
如果需要得到某時間通知的對象列表是變化的，或者是有條件的，那麼Observer模式更具有價值。這些變化可能是由於需求的改變，或者由於需要通知的對象列表的變化而引起的。如果系統在不同的情況下運行，或由不同的用戶運行，需要的觀察者列表都會不同，這是Observer模式也很有用。
一個觀察者可能只需要處理事件的某些情況。在這種情況下，觀察者必須將額外的通知篩選掉。
將篩選通知的責任轉給Subject對象，可以避免額外的通知。最好的實現方式是Subject對象使用一個Strategy模式測試通知使用應該發出。每個觀察者在註冊時都將正確的Strategy對象提供給Subject對象。
有時候，Subject會調用觀察者的Update方法，傳遞信息，這可以避免觀察者回調Subject，但是，經常是不同的觀察者有不同的信息需求。這這種情況下，可以再次使用Strategy模式，這時，用Strategy對象調用觀察者的Update方法。同樣，觀察者必須將正確的Strategy對象提供給Subject對象使用。
2、Observer模式關鍵特徵
|
意圖 |
在對象之間定義一種一對多的依賴關係，這樣當一個對象的狀態改變時，所有依賴者都將得到通知並自動更新。 |
|
問題 |
當某個事件發生時，需要向一系列變化着的對象發出通知。 |
|
解決方案 |
Observer將監視某個事件的責任委託給中心對象：Subject |
|
參與者與協作者 |
Subject知道自己的Observer，因爲Observer要向它註冊。Subject必須在所監視的事件發生時通知Observer。Observer負責向Subject註冊，以及在得到通知時從Subject處獲取信息。 |
|
效果 |
如果某些Observer只對事件的一個子集感興趣，那麼Subject可能會告訴它們不需要知道的事件。如果Subject通知Observer，Observer還返回請求更多信息，則可能需要額外的通信。 |
|
實現 |
讓某個事件發生時需要知道的對象（Observer）將自己註冊到另一個監視事件發生或自己觸發事件的對象（Subject）上。 事件發生時，Subject告訴Observer事件已經發生。 爲了對所有Observer類型的對象實現Observer接口，有時候需要使用Adapter模式。 |