基于设计模式的学习之旅-----观察者模式
1、初始观察者模式
在网络还不是那么发达的年代，很多人想了解隔天的天气预报都是得在规定时间去看电视直播，但是有时想关注天气的时候发现电视直播已经过了。这真是一件让人很不爽的事情啊。
基于这种情况，移动推出了“预定查询天气预报”业务。手机用户告诉移动他关心第二天的天气情况，订阅了天气通知的业务。当移动收到气象站告知的天气情况时，就会发送给所有订阅了这个服务的用户。 这样用户就不用为天气情况头疼了。
2、什么是观察者模式
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
别名：依赖(Dependents), 发布-订阅( P u b l i s h - S u b s c r i b e )
3、模式结构图
4、模式代码事例
4.1 涉及到相关的类
AbstractObsever(抽象观察者)、AbstractSubject(抽象目标)、MNOWeatherSubject(移动气象站服务目标)、MobileUserObsever(移动用户)、WeatherStation(气象站)
4.2具体代码实现
AbstractObsever
AbstractSubject
MNOWeatherSubject
MobileUserObsever
WeatherStation
PatternRun
4.3 事例输出结果
5、模式参与者
目标：AbstractSubject、MNOWeatherSubject
观察者：AbstractObsever、MobileUserObsever
6、模式优缺点
A、目标和观察者间的抽象耦合
一个目标所知道的仅仅是它有一系列观察者 , 每个都符合抽象的O b s e r v e r类的简单接口。目标不知道任何一个观察者属于哪一个具体的类。这样目标和观察者之间的耦合是抽象的和最小的
B、支持广播通信
不像通常的请求, 目标发送的通知不需指定它的接收者。通知被自动广播给所有已向该目标对象登记的有关对象。目标对象并不关心到底有多少对象对自己感兴趣 ;它唯一的责任就是通知它的各观察者。这给了你在任何时刻增加和删除观察者的自由。处理还是忽略一个通知取决于观察者
C、意外的更新
因为一个观察者并不知道其它观察者的存在 , 它可能对改变目标的最终代价一无所知。在目标上一个看似无害的的操作可能会引起一系列对观察者以及依赖于这些观察者的那些对象的更新。此外 , 如果依赖准则的定义或维护不当，常常会引起错误的更新 , 这种错误通常很难捕捉
7、模式适用性
A、当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
B、当对一个对象的改变需要同时改变其它对象 , 而不知道具体有多少对象有待改变。
C、当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之 , 你不希望这些对象是紧密耦合的。
点击下载“文档以及源码下载”
欢迎转载，请注明出处“http://www.cnblogs.com/luxiaofeng54/archive/2013/04/10/3012822.html”