设计模式2-观察者模式(Observer)全面解析+案例实践+总结

本文是对面向对象设计模式--观察者模式的全面解析，主要分为对设计模式的一些思考整理、定义解析、以气象布告板案例讲解观察者模式、多案例练习加深对观察者模式的理解、最后总结知识要点与观察者模式的一些优缺点与适用场景。

第一篇：设计模式二三事

1）设计模式实际是告诉我们如何组织类和对象，以解决某种问题。它们不是被发明的，而是被前人发现的，是历经验证的能够解决某种问题的一些软件设计经验的总结，并得到了共同认可。

2）设计模式已经成为了共享词汇，能够使得开发者之间能够非常方便的沟通这些设计模式所代表的观念、思想与设计。

3）设计模式并不会直接进入到代码编写里，而是应该进入你的脑海里。当你的脑海里装入许多设计模式知识，就能够开始在新的代码设计中采用它们，或者对旧有代码进行重构。

4）设计模式能够帮助我们建造有良好设计质量的系统。软件建造中我们的目的是建立有弹性、可维护的系统，可以应付改变。

 

第二篇：定义解析

策略模式是GoF四人帮整理的《设计模式-可复用面向对象软件基础》一书中23种设计模式中归类为行为型模式中的一种，23种设计模式根据它们的用途分为三大类：5种创建型模式、7种结构型模式、11种行为型模式。

引自GoF四人帮对观察者模式(Observer)模式的定义与类图：

Observer（观察者模式）：定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖它的对象都得到通知并自动刷新。

根据定义与类图其实很好理解，其实就是通过利用接口抽象将有一对多依赖关系的对象间关系进行解耦，为“一”的一端不需要关注“多”的那端的对象具体是什么，只需要保证”多“的一端的对象实现了Observer接口即可保证当其状态发生改变时，能够通知到“多”的一端的所有对象。

OO设计原则：为了交互对象之间的松耦合设计而努力。

观察者模式提供了一种对象设计，让主题和观察者实现了松耦合。任何时候我们都可以任意添加或者删除观察者，因为惟一依赖的东西是一个实现了Observer接口的对象列表。有新的观察者类出现，只需要其实现Observer接口，然后注册为观察者即可，主题类代码不需要任何改变。

 

第三篇：从气象布告板讲解观察者模式

引自《Head First 设计模式》-- 让你的对象知悉现况。

需求：

1、我们希望能够建立一个应用，有三种布告板，分别显示目前状况、天气统计、天气预报。

2、系统中WeatherData对象能够从外部气象站获取天气数据（当外部系统有新数据更新时会调用WeatherData对象中的measurementsChanged()方法）。

3、当WeatherData对象获得最新数据时，三种布告板必须实时更新。

4、能够公布一组API，以便其余开发者能够开发自己的布告板。

5、附WeatherData类结构。

需求分析：

根据需求把系统划分成两个部分：外部系统、我们需要实现的部分（WeatherData、布告板）。

 

外部系统：通过物理装置获取气象数据，并调用WeatherData将气象数据发送到我们的系统。

WeatherData对象：获取外部系统发送过来的气象数据，并立即更新所有气象布告板数据。

布告板：用于将气象数据显示给客户查看，目前有三种布告板目前状况、天气统计、天气预报。

一旦WeatherData收到气象数据，所有布告板必须立即更新。并且系统还要可扩展，能够让其它开发人员实现自己的气象布告板。

错误示范

直接将所有布告板具体实现，写到WeatherData中。

public class WeatherData {

// 实例变量声明

public void measurementsChanged() {

float temp = getTemperature();

float humidity = getHumidity();

float pressure = getPressure();

currentConditionsDisplay.update(temp, humidity, pressure); //更新目前状况

statisticsDisplay.update(temp, humidity, pressure); //更新气象统计

forecastDisplay.update(temp, humidity, pressure);//更新天气预报

}

// 这里是其他WeatherData方法

}

缺点：

WeatherData与所有布告板绑定死在一起，耦合度高。

针对具体实现编程，每增加一个布告板，我们都需要修改WeatherData类。

我们并未对变化进行封装，不能够运行时动态的增加或删除布告板。

 

认识观察者模式：

出版者+订阅者=观察者模式

1.报社出版报纸，客户向报社订阅报纸。

2.当报社出版新报纸时，所有订阅的客户都能收到新的报纸。

3.报社一直运营下去，就会不断的有新客户订阅报纸，同时也会有旧客户取消订阅报纸。

如现状：鸭子对象、猫对象、狗对象在报社（主题）订阅了报纸，老鼠对象没有订阅报纸。

 

报社出版报纸（主题对象管理某些数据），老鼠对象向报社订阅报纸（普通对象向主题注册成为观察者），狗对象向报社提出取消订阅（主题对象删除具体的观察者对象），当报社（主题）有新报纸出版时（主题对象状态更新），将新报纸发给每个订阅了的客户（观察者对象收到通知）。

报社只向订阅的客户发送新报纸，没有订阅的对象将不会收到报纸。如上图鸭子对象、猫对象、老鼠对象将收到新的报纸，而狗对象将不再收到新的报纸。

观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变时，它的所有依赖者都会收到通知并自动更新。

主题和观察者定义了一对多关系，只要主题一有变化，观察者就会被通知。

主题接口基本接口方法包括：删除观察者方法、注册观察者方法、通知所有观察者方法。

观察者接口基本接口方法包括：update方法。

主题接口，普通对象使用主题接口注册成为观察者，或者观察者对象把自己从观察者中删除。

观察者接口，所有潜在的观察者都需要实现此接口。这个接口只有一个update()方法，当主题对象改变时被调用。具体观察者可以是实现此接口的任意类。观察者必须注册具体主题，以便接收更新。

 

气象布告板实现

Weather-Data对象获取到气象数据,通知所有布告板。

把Weather-Data对象当做主题,把所有布告板当做观察者。布告板对象为了获得信息，必需先向Weather-Data对象注册。

每个布告板类都实现了同一个Observer接口，好让Weather-Data对象知道如何把信息送给它们。

 

使用Java内置的观察者实现气象布告板

Observable被观察者对象，是一个类。保存所有观察者信息，并通知它们。Weather-Data对象扩展继承它。

布告板对象实现Observer接口，然后调用Observable的addObserver()方法，即可成为观察者。调用deleteObserver()即可将观察者删除。

Observable被观察者对象发送通知前校验setChanged()设置的状态，是否为true。是则通知所有观察者，否则不通知。

缺点：Observable是一个类，限制了它的复用潜力，Java不支持多重复用。

 

第四篇：案例实践

练习案例源码：https://github.com/chentian114/100-dayaction/tree/master/designpattern-1

WeatherDemo气象布告板案例(实现观察者模式)

• WeatherData对象获取气象站数据,当数据有更新时,需要实时更新三个气象板的数据(当前情况、气象统计、天气预报）

WeatherJDKDemo气象布告板案例(使用JDK内置的观察者模式实现)

• WeatherData对象获取气象站数据,当数据有更新时,需要实时更新三个气象板的数据(当前情况、气象统计、天气预报）

MagazineDemo订阅杂志案例

订阅杂志，有Magazine对象，People对象

• 将观察者与被观察者（主题）解耦，普通类只需简单实现一个接口或抽象类就可以转换成观察者类， 而且不需要观察者不断向被观察者抓取数据，被观察者会主动将自己的改变通知给多个观察者。
• 在观察者中分为两种push模型与pull模式。
• push模型
• 　push模型是指被观察者发生改变时，将状态改变的信息全部或部分发送给观察者。
• pull模型
• 　pull模型是指被观察者发生改变时，将被观察者对象发送观察者，观察者可以自己获取感兴趣的内容。
• 观察者模式给程序员提供一个建立对象之间一对多关联关系的良好方法，并能够将信息生成层与响应层分离，给以后的修改留下很好的结构。

PoliceDemo警察蹲点监察嫌犯案例

• 观察者模式定义的是一对多的依赖关系，一个被观察者可以拥有多个观察者，并且通过接口对观察者与被观察者进行逻辑解耦，降低二者的直接耦合。

 

第五篇：总结

1.设计模式二三事，对设计模式的简单概述与好处（如何组织类与对象以解决某种问题的设计经验总结，是开发者之间的共享词汇）、目的是为了构建有弹性，可维护的系统能够应付改变。

2.气象布告板需求分析与实现，从气象布告板需求分析到观察者模式，逐步讲解。

3.OO原则-为了交互对象之间的松耦合设计而努力。观察者模式使用到的一个面向对象设计原则。

4.一些观察者模式的简单案例实践：气象布告板、警察与嫌犯等。

 

优点：

1.观察者和被观察者之间是抽象耦合

2.建立一套触发机制

 

缺点：

1.开发调试比较复杂；需要考虑一下开发效率和运行效率问题， 一个被观察者，多个观察者，开发和调试就会比较复杂。

2.顺序执行需要考虑执行效率；在Java中消息的通知默认是顺序执行，一个观察者卡壳，会影响整体的执行效率。 在这种情况下， 一般考虑采用异步的方式。

 

使用场景：

1.关联行为场景。 需要注意的是， 关联行为是可拆分的， 而不是“组合”关系。

2. 事件多级触发场景。

3. 跨系统的消息交换场景， 如消息队列的处理机制。