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

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

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

三、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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值