Java设计模式之观察者模式(UML类图分析+代码详解)
大家好，我是一名在算法之路上不断前进的小小程序猿！体会算法之美，领悟算法的智慧~
希望各位博友走过路过可以给我点个免费的赞，你们的支持是我不断前进的动力！！
加油吧！未来可期！！
本文将介绍java之观察者模式
案例引入
天气预报项目需求,具体要求如下：
1) 气象站可以将每天测量到的温度，湿度，气压等等以公告的形式发布出去(比如 发布到自己的网站或第三方)。 2) 需要设计开放型API，便于其他第三方也能接入气象站获取数据。 3) 提供温度、气压和湿度的接口 4) 测量数据更新时，要能实时的通知给第三方。
天气预报设计方案1-普通方案
WeatherData类 通过对气象站项目的分析，可以初步设计出一个WeatherData类 说明:
1) 通过getXxx方法，可以让第三方接入，并得到相关信息.
2) 当数据有更新时，气象站通过调用dataChange() 去更新数据，当第三方再次获取时，就能得到最新数据，当然也可以推送。
CurrentConditions(当前的天气情况) 可以理解成是气象局的网站 //推送
代码实现：
问题分析
1) 其他第三方接入气象站获取数据的问题
2) 无法在运行时动态的添加第三方
3) 违反ocp原则=>观察者模式 //在WeatherData中，当增加一个第三方，都需要创建一个对应的第三方的公告板 对象，并加入到dataChange, 不利于维护，也不是动态加入 public void dataChange() { currentConditions.update(getTemperature(), getPressure(), getHumidity()); }
观察者模式(Observer)原理
案例引入
观察者模式类似订牛奶业务
1) 奶站/气象局：Subject
2) 用户/第三方网站：Observer
Subject：登记注册、移除和通知
1) registerObserver 注册
2) removeObserver 移除
3) notifyObservers() 通知所有的注册的用户，根据不同需求，可以是更新数据，让用 户来取，也可能是实施推送，看具体需求定
Observer：接收输入
观察者模式：对象之间多对一依赖的一种设计方案，被依赖的对象为Subject， 依赖的对象为Observer，Subject通知Observer变化,比如这里的奶站是 Subject，是1的一方。用户时Observer，是多的一方。
观察者模式解决天气预报需求
思路分析图解(类图)
观察者模式的好处
1) 观察者模式设计后，会以集合的方式来管理用户(Observer)，包括注册，移除 和通知。
2) 这样，我们增加观察者(这里可以理解成一个新的公告板)，就不需要去修改核 心类WeatherData不会修改代码，遵守了ocp原则。
代码实现
观察者模式在Jdk应用的源码分析
1) Jdk的Observable类就使用了观察者模式 2) 代码分析+模式角色分析
模式角色分析
- Observable 的作用和地位等价于Subject
- Observable 是类，不是接口，类中已经实现了核心的方法 ,即管理Observer 的方法 add.. delete .. notify...
- Observer 的作用和地位等价于项目中的Observer, 有update - Observable 和 Observer 的使用方法和前面项目的一样，只是Observable 是 类，通过继承来实现观察者模式。
