畢竟是做android的，對於contentobserver是很熟悉的，在監聽資料庫變化時使用很頻繁，android有一整套用來監聽的api，直接拿來用就行了。觀察者模式是用來監聽物件的變化的行為型模式。
觀察者（observer）模式又名發布-訂閱（publish/subscribe）模式。gof 給觀察者模式如下定義：定義物件間的一種一對多的依賴關係，當乙個物件的狀態發生改變時，所有依賴於它的物件都得到通知並被自動更新。
在這裡先講一下物件導向設計的乙個重要原則——單一職責原則。系統的每個物件應該將重點放在問題域中的離散抽象上。因此理想的情況下，乙個物件只做一件事情。這樣在開發中也就帶來了諸多的好處：提供了重用性和維護性，也是進行重構的良好的基礎。因此幾乎所有的設計模式都是基於這個基本的設計原則來的。觀察者模式的起源我覺得應該是在gui 和業務資料的處理上，因為現在絕大多數講解觀察者模式的例子都是這一題材。但是觀察者模式的應用決不僅限於此一方面。
下面我們就來看看觀察者模式的組成部分。
1) 抽象目標角色（subject）：目標角色知道它的觀察者，可以有任意多個觀察者觀察同乙個目標。並且提供註冊和刪除觀察者物件的介面。目標角色往往由抽象類或者介面來實現。
2) 抽象觀察者角色（observer）：為那些在目標發生改變時需要獲得通知的物件定義乙個更新介面。抽象觀察者角色主要由抽象類或者介面來實現。
3) 具體目標角色（concretesubject）：將有關狀態存入各個concreteobserver 物件。當它的狀態發生改變時, 向它的各個觀察者發出通知。
4) 具體觀察者角色（concreteobserver）：儲存有關狀態，這些狀態應與目標的狀態保持一致。實現observer 的更新介面以使自身狀態與目標的狀態保持一致。在本角色內也可以維護乙個指向concretesubject 物件的引用。
在 subject 這個抽象類中，提供了上面提到的功能，而且存在乙個通知方法：notify。還可以看到subject 和concretesubject 之間可以說是使用了模板模式。這樣當具體目標角色的狀態發生改變，按照約定則會去呼叫通知方法，在這個方法中則會根據目標角色中註冊的觀察者名單來逐個呼叫相應的update 方法來調整觀察者的狀態。這樣觀察者模式就走完了乙個流程。
由於觀察者模式使用的過多，這裡就不舉例了，僅讓大家參考一下這個概念。
設計模式之觀察者模式
首先說了乙個自己的小例子吧，前兩天我的乙個朋友來找我玩，因為路途比較遠，我需要知道他的位置，然後安排好時間去接他，那麼在這個例子中，我就是乙個觀察者，需要時時刻刻觀察他的位置，我的朋友就是乙個被觀察者。那麼需要知道我朋友的位置，就有兩種方式，第一，我自己打 問，第二，我的朋友告訴我，下面我們來看看這...
設計模式之觀察者模式
一 作用 讓多個觀察者監視某一物件的變化，如果物件變化，則通知所有觀察者。二 例子 抽象主題類 public abstract class subject 移除觀察者 public void detach observer observer 向觀察者 們 發出通知 public void notif...
設計模式之觀察者模式
觀察者模式的定義是 定義物件間的一種一對多的依賴關係。當乙個物件的狀態發生變化時，所有依賴它的物件都會得到通知並自動更新 報社跟讀者的例子 我們用報社和讀者之間的關係來模擬觀察者模式。包含以下主體 報社 news office 讀者介面 reader 具體讀者 reader 二逼青年 reader ...