设计模式之---观察者模式

一、模式定义
    定义一种对象之间的一对多的依赖关系，这样一来，当一个主题对象改变状态时，它的所有观察者都会收通知并自动更新。

二、 所体现出的设计原则
为交互对象之间的松散耦合设计而努力。

三、UML图示
                                      

四、应用场景

    1.  当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
    2,  当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。
    3.  当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。

五、注意事项

    Subject类需要维护一个列表，保存已经向其注册了的Observer对象列表（当然用C++实现的话，就是保存Observer基类指针）。Subject必须实现一种“推数据”的方法，即在“通知”各个Observer更新数据时，将Subject自身维护的全部数据，通过UpdateData(para1, para2, …)接口的调用传递给各个Observer对象。另一方面，Subject也可以实现很多接口，供各个observer“拉数据”。
“推数据”优点是：接口简单，不必要为每个数据提供一个get方法供Observer调用（想想看，如果有100个数据成员，就必须提供100个接口）。
“推数据”缺点是：强迫Observer接收全部数据，即便某些observer只需要部分数据；同时暴露了Subject的数据。
    “拉数据”优点是：比较灵活，如果本身数据增加或者减少，只需要提供新的接口，或者删除旧的接口就可以了。
    “拉数据”缺点是：如果一个observer对象需要的状态很多，就必须多次调用Subject提供的接口来获得，比较麻烦。

六、举例说明

    以天气预报为例。气象局的数据采集中心会定时从检测仪器上采集数据，经过大量超级复杂的计算并后生成新的天气预报，这里数据采集中心就好比是一个subject。然后各大门户网站的天气预报栏目就好比是各个观察者对象，一旦数据中心有通知，则各个观察者都可以取得最新的天气情况信息。当然啦，这个例子里的观察者模式是一个更大的，分布式的实例，可以利用各种分布式技术如CORBA，EJB等实现。

七、代码示例

    维基百科：http://zh.wikipedia.org/wiki/%E8%A7%82%E5%AF%9F%E8%80%85%E6%A8%A1%E5%BC%8F