欢迎来到天天文库
浏览记录
ID:44010981
大小:191.38 KB
页数:17页
时间:2019-10-17
《模式设计连载三》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库。
1、气象站的故事-观察者模式前言大家好!好久没有更新这个系列的文章了,这两个来月回家过了新年,公司搬了新家,就是这个系列的文章还没有更新,实在惭愧!同时再次真诚地感谢一直喜欢和支持这个系列文章的朋友们,因为你们的鼓励,我才有动力继续下去。可能因为这个系列每篇文章都比较长的原因,为了保证质量我总是字斟句酌,所以每次想动笔的时候都有点胆怯的感觉,但是还好每次只要写了开头我就会坚持把它写完的,还是万事开头难啊。上篇【策略模式】得到了很多朋友的支持,倍感欣慰。这篇文章将延续以往的风格,故事来源同样取材于《He
2、adFirstDesignPatterns》,气象站的故事部分并非我原创,只是把原书的内容用更通俗易懂的方式展现给大家,特此声明一下,而这里更多的是作者对模式本身的理解和扩展的引申。关于HFDP,推荐大家去购买和阅读原版图书。OK!我们这就开始!(提示:西红柿和鸡蛋都是好东西,请不要乱丢)气象站的故事 现在我们要为一家气象站开发一套气象监控系统,按照客户的要求,这个监控系统必须可以实时跟踪当前的天气状况(温度、湿度、大气压力),并且可以在三种不同设备上显示出来(当前天气状况、天气统计、天
3、气预测)。客户还希望这个系统可以对外提供一个API接口,以便任何开发者都可以开发自己的显示设备,然后无缝挂接到系统中,系统可以统一更新所有显示设备的数据。客户还会提供一个可以访问气象站的硬件设备的组件,如下图所示: 它提供了三个方法(get开头),可以分别取得实时的温度、湿度和大气压力,还有一个MeasurementsChanged()方法,当任何天气状况发生变化的时候,这个方法都会自动被触发,当前这个方法只是一个空函数,扩展的代码还需要我们自己去扩充。至于WeatherData是如何取
4、得天气状况的,还有MeasurementsChanged()方法是如何被自动触发的这些事情都不需要我们去考虑,我们只管考虑如果做好跟显示设备有关的事情就好了。 OK!让我们来考虑一下这个系统的实现,先重新理一下思路:1. 客户提供了获取实时的天气状况的方法。2. MeasurementsChanged()方法会在天气状况变化时被自动调用。3. 系统要实现三种显示模式,分别显示天气状况、天气统计和天气预测,而且这些显示的信息必须跟当前最新的天气状况实时同步。4. 系统还必须支持在显示方式上的
5、扩展性,而且使用者可以任意添加和移除不同的显示模式。基于上面这些信息,我们大概都会想到可以象下面这样来实现这个系统: //伪代码 publicclassWeatherData { //实例化显示设备(省略) publicvoidMeasurementsChanged() { floattemp=getTemperature();//取得温度 floathumidity=getHumidity();
6、//取得湿度 floatpressure=getPressure();//取得气压 currentConditionsDisplay.update(temp,humidity,pressure);//同步显示当前天气状况 statisticsDisplay.update(temp,humidity,pressure);//同步显示天气统计信息 forecastDisplay.update(temp,humidity,p
7、ressure);//同步显示天气预报信息 }} 因为客户已经给我们提供了实时的数据,还提供了数据更新时候的触发机制,那么我们要做的就是把最新的数据提供给不同的显示设备就OK了,上面的代码好象已经可以基本解决问题啦。哈哈! 真的就这么简单就搞定了吗?让我们用上一篇【策略模式】里学习到的原则来审视一下这个实现。首先,xxxDisplay这几个对象都是具体的类实例,也就是说我们在这里违背了“面向接口编程,而不要面向实现编程。”的原则,这样实现会带来的问题是系统无法满足在不修改代码的
8、情况下动态添加或移除不同的显示设备。换句话说,显示设备相关的部分是系统中最不稳定的部分,应该将其单独隔离开,也就是前面学过的另一个原则:“找到系统中变化的部分,将变化的部分同其它稳定的部分隔开。”那么我们到底该怎么办呢?呵呵,既然这篇文章是讲观察者模式的,当然要用它来结束战斗!下面我们先来认识一下观察者模式~这就是观察者模式 我们还是先看一下官方的定义: TheObserverPatterndefinesaone-to-manydependencybetween
此文档下载收益归作者所有