设计模之观察者模式上篇

观察者模式上篇

观察者模式原理：

大家好，欢迎来到污污弹公司，最近啊，污污弹接到气象站的外包项目。

功能比较简单：

要对外提供天气接口(温度、气压、湿度)需要实时通知第三方；

还需要实时在市中心公告栏上发布天气情况。

司小司接到任务开始动手干了。根据Java面向对象特性分析后得到如下信息：

天气对象：WeatherData

公告板对象:CurrentConditions

天气更新时候，调用天气对象的dataChange方法，得到数据后，然后将数据通过display()方法展示出来。

根据上面信息，我们可以创建以下两个类：

天气对象：

公布栏对象具体内容如下：

我们进行测试：

运行方法：

数据输出与预期的一致。就这么简单的完事了。司小司快乐的下班了，吃炸鸡，喝啤酒。

正在嗨的时候，领导来电话了，说有个新公司要对接天气信息。司小司想，这个简单，要么新写个方法，要么在更新天气时候，新增加。如下图：

哇嘎嘎，搞定，接着嗨去。可是，一会老板又打电话，有30家要对接!

司小司一听，慌乱。我勒个去，这要是来一百个对接，然后又有不合作的，需要去掉的。如果每次都修改代码，重新上线，非疯掉不可。无法动态添加第三方公司，扩展性很差，需要修改结构了。

重构思考：

哪些变化的？变化部分抽取出来，做成接口，提供。哪些不变化的？经过分析得到：

经常会变化的部分：公告板对象、天气变化方法

目前公告板一次性把温度、湿度、气压等公告出来了。以后可能只有温度或者只有湿度公告板或者多个组合的。所以，公告板对象一定会变化的。果断提取出一个接口。

从上面，我们可以看出，新接入一家，dataChange方法就要修改一次。所以这个也要抽取出来。

这里司小司打算引进观察者模式来经行处理。

先来看看什么是观察者模式：

简单理解，观察者模式就像我们在学校订阅杂志、报刊或者是定牛奶一样，或者就像我们订阅的公众号一样。先和提供方谈好条件，留下联系地址、联系人等信息。每天或固定时间，将最新信息送到指定位置。就像公众号，每天推送消息一样。

我们就以定牛奶业务为例来说说观察者模式。

定奶业务有两个角色：奶站(subject)、用户(Observer)

来看看这个两个角色主要功能：

subject：奶站，能够登记注册用户信息(registerObserver)、删除用户信息(移除:removeObserver)和给用户提供新的牛奶(通知:notifyObservers)

根据上面说的，我们可以得到subject接口

对应用户来说，主要功能，就是接收奶站提供的牛奶。

Observer：接收输入信息。

所以我们可以得到Observer接口：

举例图说：

通过上面举例，我们知道明白了观察者模式了吧。

总结，观察者模式：对象之间多对一依赖的一种设计方案，被依赖的对象为Subject，依赖的对象为Observer,两者之间的关系：subject通知Observer变化。

根据上面观察者模式的分析，司小司决定用观察者模式重新设计方案类图。如下：

类之间关系说明：

subject:实现了subject接口的weatherDataSt(新天气)对象。

observer:实现了observer的currentConditions(新公告板)对象。

其中，由新公告板指向新天气对象的箭头，表示observer向subject注册或者申请注销操作

由新天气对象指向新公告板对象的箭头，表示subject通知observer信息。

使用观察者模式具体代码实现：

先看项目结构：

结构说明：

interfaceObj：存放接口的包

    Observer：observer接口对象

    Subject：subject接口对象

CurrentConditionSt：实现了Observer接口的公告板对象

ForcastConditionSt：另一个实现了Observer接口的公告板对象(预测公告板)

ObserverWeatherMainTest：观察者模式的测试类

WeatherDataSt：实现了Subject接口的天气对象

Observer类里面代码：

Subject类里面代码：

CurrentConditionSt类里面代码：

ForcastConditionSt类里面代码：

新天气对象代码：

测试类里面代码：

运行结果：

注册了不同的公告板。打印出结果一不一样。达到我们预期的结果了。

联系凯哥--》凯哥Java(kaigejava)

个人博客：www.kaigejava.com

好了，本文就讲解到这里。在下一篇文章中，我们将要讲解的是：对观察者模式总结及在Java中内置的观察者模式