设计模式思想换位之另类的观察者

    观察者模式(Observers)  定义了对象之间的一对多依赖，这个一来，当一个对象改变状态时，它所有的依赖者都会收到通知并自动更新,主题和观察者定义了一对多的关系 观察者依赖于主题，只要主题状态一有改变，观察者就会接受到通知 根据通知的风格。

    当两个对象之间松耦合，它们依然可以交互，但不太清除彼此的细节。观察者模式提供了一种对象设计，让主题和观察者之间松耦合。主题只知道观察者实现了某个接口(也就是Observer接口)主题不需要知道观察者的具体类是谁，做了些什么或其他的任何细节。任何时候我们可以添加新的观察者。因为主题唯一依赖的东西是一个实现Observer接口的对象列表。

    松耦合的设计之所以能让我们建立有弹性的OO系统，能够应对变化，是因为对象之间的互相依赖降到了最低。所以我们为了交互对象之间的松耦合设计而在努力。

    笔者学习过很多观察者模式的文章，也在项目中使用过，下面我们通过一个Dome慢慢的认识体会设计模式的思想。

    Demo - 气象监测应用系统

    气象观测局专利申请在WeatherData对象中，由WeatherData负责追踪天气状态。成功以后在气象监测局显示以供广大网民查询并提供接口给大型网站显示，这时候访问关系是，

    注意箭头的方向，访问取得数据的压力都压在气象局中，久而久之根据访问量的递增气象局不定的添加服务器，负载均衡，缓冲等技术解决。

    而知，有时候，如果您发现项目中后期维护的问题太多，那就回到起点从新思考问题。每次网民通过各大合作方网站访问数据，各大合作方又来访问气象局得到数据。这无形中让压力增加。那么我们如何将压力分布，减少无谓的浪费。

    这时候让我们回到观察者模式中的思想，那就是“你们不要来访问我，如果我的数据发生改变我会通知你们”。讲到这里请看新的设计关系图：

    看看此时的关系设计图表中，合作方不再从气象局获取到数据，而使用本地数据储存方式，当气象局数据发生变化更新各合作方，则将各个合作方的数据更新到最新，而气象局的数据是主题，而合作方便是也就是观察者，两方便是一对多的关系，气象局不需要知道合作方取了数据如何使用，只要在获得到新的数据后更新即可。

    接近尾声的时候，这次就不贴代码了，讲到这里实现起来该DOME肯定没问题，这次虽然短短的些字，但确实本人不才些经验和悟性，其实我这整篇文章想表达的是，设计模式表达的一种思想，是从项目业务逻辑中和后期变化中去思考。