毕竟是做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 方法来调整观察者的状态。这样观察者模式就走完了一个流程。

　　由于观察者模式使用的过多，这里就不举例了，仅让大家参考一下这个概念。

设计模式之观察者模式