设计模式-Observer 模式
1. 解决的问题:
假如现在要编写一个天气预报的公布栏, 公布栏有两种显示方式, 一种是图像方式显示, 一种是表格形式显示.
2. 问题分析:
应该根据数据与现实分离的原则将天气预报数据和现实形式分别封装起来,
今后可能增加其他的显示形式;
天气预报数据发生变化后,需要对所有的显示形式进行更新.
3. UML图与
代码实现:
1)用Push的方式更新Observer数据, 通过Subject对Observer进行注册:

2)用Pull的方式更新Observer数据, Observer自己进行注册:

上面两种实现的执行结果如下:
4. Push还是Pull?
对于上面的例子, Observer中的数据是从Subject中一次性全部更新的(temperature 和 humidity), 这种更新数据的方式便是push;然而如果WeatherData中的数据量非常大, 而有些Observer并不需要所有的数据, 比如现在要新增两个显示方式,一个是只显示温度,而另一个则只显示湿度, 这样的话就没有必要让所有的Observer都得到所有的数据. 最好的方式是Observer能根据自己的需要从Subject中去取得数据,这种更新数据的方式便是Pull. Observer模式中Push和Pull两种设计方法体现在具体的程序中就是Observer中的Update()接口参数不同, 对于Push模式, Update()接口的参数通常就是需要Push的那些数据,比如这里的温度和湿度; 对于Pull模式, Update()的参数是Subject的一个引用, 然后Subject提供一些数据接口,由Observer通过这些接口自己取得所需要的数据.
5. 总结:
1. Strategy 模式定义:
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新.
2. 体现的设计原则:
- 将数据与现实分别封装;
- 多使用组合,少使用继承;
- 面向接口编程,而不面向实现编程;
3. UML图:

4. 要点:
- Strategy 基类需要定义出可供Client使用的一些算法接口;
- 可以随时根据需要增加 Strategy 而不会影响到Client;
- Client 里面需要包含对 Strategy 的引用;
- Client 可以随时更换 Strategy;
6. 理解:
- Observer模式是解决对象之间数据传递问题的一种模式;
- Observer的注册可以由Subject执行也可以由Observer自己执行;
- 和Strategy模式的比较:
1) Observer模式中Observer 中定义了 Update()接口供 Subject调用; 而Strategy模式中,Strategy定义了AlgrithmInterface()供Client调用;
2) Observer模式中Subject和Observer是一对多的关系, 因此Subject是一次调用n个Observer的Update()接口;而Strategy模式中Client与Strategy之间是一对一的关系, Client 就是调用指定的那个Strategy的AlgrithmInterface();
3) 也正因为这种对应关系的不同, 在Observer模式中, Subject可以Register或者Remove某个Observer, 而Strategy模式中通常只是set某个Strategy