内容来自尚硅谷Java设计模式（图解+框架源码剖析）_哔哩哔哩_bilibili

写在前面:本文内容大致和原视频内老师的笔记内容相同，会偶尔插入自己的注释和理解，尽量会完成作业

兄弟们！学就完事了！加油！奥里给！

第20章观察者模式

20.1天气预报项目需求,具体要求如下

1)      气象站可以将每天测量到的温度，湿度，气压等等以公告的形式发布出去(比如发布到自己的网站或第三方)。需要设计开放型API，便于其他第三方也能接入气象站获取数据。

2)      提供温度、气压和湿度的接口

3)      测量数据更新时，要能实时的通知给第三方

20.2天气预报设计方案 1-普通方案

20.2.1WeatherData类

传统的设计方案

代码实现

Ø  问题分析

其他第三方接入气象站获取数据的问题

无法在运行时动态的添加第三方(新浪网站)

违反ocp原则->观察者模式

在WeatherData中，当增加一个第三方,都需要创建一个对应的第三方的公告板对象,并加入到dataChange,不利于维护，也不是动态加入

public void dataChange(){

        //调用接入方的update方法

        currentConditions.update(getTemperature(),getPressure(),getHumidity());

}

20.3观察者模式的基本原理

1)      观察者模式类似订牛奶业务

2)      奶站/气象局:Subject

3)      用户/第三方网站:Observer

Ø  Subject:登记注册、移除和通知

1)      registerObserver注册

2)      removeObserver移除

3)      notifyObservers()通知所有的注册的用户，根据不同需求，可以是更新数据，让用户来取，也可能是实施推送，看具体需求定

Ø  Observer:接收输入

Ø  观察者模式:对象之间多对一依赖的一种设计方案，被依赖的对象为Subject，依赖的对象为Observer，Subject通知Observer变化,比如这里的奶站是Subject，是1的一方。用户时Observer，是多的一方。

20.4观察者模式解决天气预报需求

20.4.1类图说明

20.4.2代码实现

20.4.3观察者模式的好处

1)      观察者模式设计后，会以集合的方式来管理用户(Observer)，包括注册，移除和通知。

2)      这样，我们增加观察者(这里可以理解成一个新的公告板)，就不需要去修改核心类WeatherData不会修改代码,遵守了ocp原则。

20.5观察者模式在Jdk应用的源码分析

1)      Jdk的 Observable类就使用了观察者模式

2)      代码分析+模式角色分析

Observable的作用和地位等价于我们前面讲过Subject

Observable是类，不是接口，类中已经实现了核心的方法 ,即管理Observer的方法 add..delete ..notify...

Observer 的作用和地位等价于我们前面讲过的Observer，有update

Observable 和Observer的使用方法和前面讲过的一样，只是Observable是类，通过继承来实现观察者模式