《HeadFirst设计模式》读书笔记二：观察者模式

作者：折纸
个人博客：https://www.zhezhi.press
记录菜鸡的成长之旅！

1. 模式定义和特点

观察者（Observer）模式的定义：指多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式，它是对象行为型模式。

观察者模式是一种对象行为型模式，其主要优点如下。

• 降低了目标与观察者之间的耦合关系，两者之间是抽象耦合关系。符合依赖倒置原则。
• 目标与观察者之间建立了一套触发机制。

它的主要缺点如下。

• 目标与观察者之间的依赖关系并没有完全解除，而且有可能出现循环引用。
• 当观察者对象很多时，通知的发布会花费很多时间，影响程序的效率。

2. 模式的类图结构

观察者需要获取到某些数据，但只有主题对象才是真正管理这些数据的角色；这比起所有观察者统一控制同一份数据具有更低的耦合性

我们常说的高内聚，低耦合是什么意思？我的理解：该紧密联系的时候就紧密联系，不该紧密联系的时候就该拆分出来。(同一模块内功能没有必要拆分）

松耦合

当两个对象松耦合时它们依然可以交互，但不了解彼此的细节(对象之间的互相依赖降到了最低) --> 实现了有弹性的系统

关于观察者的一切，主题只知道观察者实现了某个接口（也就是Observer接口）。主题不需要知道观察者的具体类是谁、做了些什么或其他任何细节。

任何时候我们都可以增加新的观察者。因为主题唯一依赖的东西是一个实现Observer接口的对象列表，所以我们可以随时增加观察者。事实上，在运行时我们可以用新的观察者取代现有的观察者，主题不会受到任何影响。同样的，也可以在任何时候删除某些观察者。

有新类型的观察者出现时，主题的代码不需要修改。我们可以独立地复用主题或观察者。如果我们在其他地方需要使用主题或观察者，可以轻易地复用。因为二者并非紧耦合。

改变主题或观察者其中一方，并不会影响另一方。因为两者是松耦合的，所以只要他们之间的接口仍被遵守，我们就可以自由地改变他们。

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

3. 模式的实现

3.1 Java内置观察者模式类图

3.1.1 如何把对象变成观察者…

如同以前一样，实现观察者接口（java.uitl.Observer），然后调用任何Observable对象的addObserver）方法。不想再当观察者时，调用deleteObserver（）方法就可以了。

3.1.2 可观察者/主题要如何送出通知……

首先，你需要利用扩展java.util.Observable接口产生“可观察者”类，然后，需个步骤：
①先调用setChanged（）方法，标记状态已经改变的事实。
②然后调用两种notifyObservers0方法中的一个：
notifyobservers（）或 notifyobservers（object arg）

3.1.3 观察者如何接收通知……

同以前一样，观察者实现了更新的方法，但是方法的签名不太一样：

如果你想“推”（push）数据给观察者，你可以把数据当作数据对象传送给notifyObservers（arg）方法。否则，观察者就必须从可观察者对象中“拉”（pull）数据。

其中 setChanged()方法是用来标记状态是否改变的，好让notifyObservers（）知道当它被调用时应该更新观察者。如果调用notifyObservers）之前没有先调用setChanged（），观察者就“不会”被通知。让我们看看Observable内部，以了解这一切：

3.2 自定义实现

3.2.1 java.util.Observable的弊端

java.uitl.Observable实现了它的notifyObservers（）方法，这导致了通知观察者的次序不同于我们先前的次序。谁也没有错，只是双方选择不同的方式实现罢了。但是可以确定的是，如果我们的代码依赖这样的次序，就是错的。为什么呢？因为一旦观察者/可观察者的实现有所改变，通知次序就会改变，很可能就会产生错误的结果。这绝对不是我们所认为的松耦合。

首先，因为Observable是一个“类”，你必须设计一个类继承它。如果某类想同时具有Observable类和另一个超类的行为，就会陷入两难，毕竟Java不支持多重继承。
这限制了Observable的复用潜力（而增加复用潜力不正是我们使用模式最原始的动机吗？）。

再者，因为没有Observable接口，所以你无法建立自己的实现，和Java内置的Observer API搭配使用，也无法将java.util的实现换成另一套做法的实现（比方说，Observable将关键的方法保护起来如果你看看ObservableAP1，你会发现setChanged）方法被保护起来了（被定义成protected）。那又怎么样呢？这意味着：除非你继承自Observable，否则你无法创建Observable实例并组合到你自己的对象中来。这个设计违反了第二个设计原则：“多用组合，少用继承”。

如果你能够扩展java.util.Observable，那么Observable“可能”可以符合你的需求。否则，你可能需要像本章开头的做法那样自己实现这一整套观察者模式。

4. 模式的应用场景

在软件系统中，当系统一方行为依赖另一方行为的变动时，可使用观察者模式松耦合联动双方，使得一方的变动可以通知到感兴趣的另一方对象，从而让另一方对象对此做出响应。

通过前面的分析与应用实例可知观察者模式适合以下几种情形。
1、对象间存在一对多关系，一个对象的状态发生改变会影响其他对象。
2、当一个抽象模型有两个方面，其中一个方面依赖于另一方面时，可将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
3、实现类似广播机制的功能，不需要知道具体收听者，只需分发广播，系统中感兴趣的对象会自动接收该广播。
4、多层级嵌套使用，形成一种链式触发机制，使得事件具备跨域（跨越两种观察者类型）通知。

5. 总结

设计原则：

• 封装变化
• 多用组合 少用继承
• 针对接口编程 而不是针对实现编程
• 为交互对象之间的松耦合而努力