我们接受了一个任务，负责建立weather-o-Rama公司的下一代气象站，该气象站必须建立在该公司专利申请中的WeatherData对象上，由WeatherData对象负责跟踪目前的天气状况（温度，湿度，气压），该公司希望我们能建立一个应用，有3中布告板，分别显示目前状况，气象统计及简单的预报。由WeatherObject对象获得最新的测量数据，3中布告板必须随时更新。
WeatherData对象知道如何跟物理气象站取得联系，以取得最新的数据，WeatherData对象会随即更新3个布告板的显示。 我们收到了该公司发给我们的WeatherData源文件，看了下代码，一切很直接：
需要说明的是，该公司人员告诉我们：一旦气象更新，measurementsChange（）方法会被调用。我们的工作是实现measurementsChanged（），好让他更新3中布告板。
先看一个错误的释放：
上面的实现有什么不对？
update（）至少看起来像一个统一的接口，布告板的方法名称都是update，参数都相同。
改变的地方，需要封装起来。
我们上面是针对具体实现编程，会导致我们以后在增加或删除布告板时必须修改程序。现在我们来看看观察者模式。
认识观察者模式
我们来看看报纸和杂志的订阅是怎么回事。
1.报纸的业务是出版报纸。
2.向某家报社订阅报纸，只要他们有新报纸出版，就会给你送来，只要你是他们的订户，你就会一直受到新报纸。
3.当你不想再看报纸的时候，取消订阅，他们就不会再送来新报纸
4只要报社还在运营，就会一直有人向他们订阅报纸或取消报纸订阅。
出版者+订阅者=观察者模式
如果你来了解报纸订阅是怎么回事，其实就知道观察者模式是怎么回事，只是名称不太一样：出版者改称为“主题”（Subject），
订阅者改称为“观察者”（Observer）。让我们来看仔细一点：
定义观察者模式
观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
我们的主题是真正拥有数据的人，观察者是主题的依赖者，在数据变化时更新，这样让许多对象控制同一份数据库来，可以得到更干净的oo设计。
实现观察者模式的方法不止一种，但是以保护subject接口与observer接口的类设计的做法最常见。
松耦合的威力
当2个对象之间松耦合，他们依然可以交互，但是不太清楚彼此的细节。观察者提供了一种对象设计，让subject和observer之间松耦合。
为什么呢？
关于观察者的一切，主题只知道观察者实现了某个接口（也就是observer接口），主题不需要知道观察者的具体类是谁，做了些什么等其他细节。
任何时候我们都可以增加观察者，因为主题唯一依赖的东西是一个实现observer接口 的对象列表，
所以我们可以随时增加观察者。
设计原则：为了交互对象之间的松耦合设计而努力。