设计模式之观察者模式-IAS条线-吴紫群-20111212.doc

设计模式之观察者模式 项目代号 文档类型 发布版本 发布日期 编制 吴紫群 编制日期 2011-12-12 审核 审核日期 批准 批准日期 上海互联网软件有限公司 文件修订记录 序号 版本 修订人 修订项 修订时间  项目背景 在项目的架构设计中，需要考虑系统的灵活性和可扩展性。观察者模式在现有的很多项目中已有应用，开发框架就应用了多种设计模式，其中也包括了观察者模式，并且在多处使用，本文主要介绍观察者模式的原理，通过一步步的代码比较和需求的演变来说明为什么需要用观察者模式。 概述 观察者模式，简单的讲就是观察。有观察的对象也有被观察的对象。彼此之间的关系不是调用。而是观察。首先是观察的对象，比如：农民关心天气，旅游者关心天气，上班的人关心天气，....这里面，农民，旅游者，上班的人都是观察者。他们都有一个特点：关心天气。因此我们可以设计一个接口IObserver。标明他们有个共同的特点，关注天气。他们之间又有不同，就是关注天气后的动作。如农民关心天气后的动作和旅游者不一样。 农民一看到明天下雨，就不浇菜了。旅游者一看到下雨，明天就不出游了。那么每个观察者实现了同样的接口，但具体的实现不一样。好，回过头来看看被观察者，就是气象台了。发布信息的地方。当然，观察者关心是天气信息。因此可能只是条信息。那么被观察者呢，发出这条信息。当然很有可能不会是一个气象台。那么我们同样定义一个接口，只要实现发布天气就好了。叫IObservable.可被观察对象。 这样气象局也好，其他的一些只要能发布气象信息的机构都可以实现这个接口提供服务了。 说完了主体。现在说最重要的：观察。 观察者和被观察者之间的纽带。 那么现实生活中，如何做到呢？一种，当天气变更。气象台发出通知。一种，农民，旅游者，上班人 当需要知道气象信息向气象台跑，获取信息。 第一种，需要考虑的是我发出通知，如果人家不需要呢，那通知就白发了。第二种，如果气象没有发生改变呢，也白跑了。 其实也是常见的推和拉。推，即气象台主动推销，拉，则观察者主动打听信息。 其实两种都有个目标受众群的概念，气象台需要知道哪些人想知道信息。而受众想知道气象是否发生变化。这样才利于消息的传递。因此需要建立联系的纽带，我们这边简单设计一个。就是通知人名单。 我们来从代码层面看，观察者模式的演化过程：public static void main() { ? ? ??TextBox?txtWeather =?new?TextBox?(); ????????bool?isChange = (txtWeather.Text !=?); ????????if?(isChange) ??????? { ????????????//农民观察天气行为 ??????????? System.IO.File.AppendAllText(c:\\farmer.txt, txtWeather.Text); ????????????//旅游者观察天气行为 ??????????? System.IO.File.AppendAllText(c:\\tourist.txt, txtWeather.Text); ????????????//上班族 ??????????? System.IO.File.AppendAllText(c:\\officeWorker.txt, txtWeather.Text); ?? } 评述： 当天气发生变化，就执行三者的行为。 这并不是一个面向对象的设计方式，是一个面向过程设计。 一个程序顺序执行下来，没有任何对象的概念。 没有面向对象的设计方式，最大的问题是，大量的重复代码，比如当有大量的其他地方需要调用农民的观察到天气行为时， System.IO.File.AppendAllText(c:\\farmer.txt, txtWeather.Text); 这段代码将遍布整个项目。当然，如果不变，也就是该操作永远不变，则无需考虑此无问题。为了，解决上述代码的统一管理，我们可能这样来处理。 实现 public?class?Demo ??? { ????????public?static?void?main() ??????? { ????????????TextBox?txtWeather =?new?TextBox(); ????????????bool?isChange = (txtWeather.Text !=?); ????????????if?(isChange) ??????????? { ????????????????//农民观察天气行为 ?????????