设计模式-观察者模式

前言

关于观察者模式比较简单，网上解释的很多很多，解释的都挺好理解的，因此这里并不打算说明太多，有关实现和案例源码已上传至https://github.com/zhuzhenke/design-patterns。欢迎加星关注，后续会有持续更新。design-patterns提供了两种实现方案，一种是jdk实现，一种是我自己实现了可多观察者观察多主题。

本文重点

本文的关注点在于领域模式的封装，重点在于jdk的实现，和自己实现的区别，各自优势分析。下面是我在分析时想到的10个问题，理解自己综合分析后的理解。

1.主题定义在哪里

Observable是一个类，可以直接继承Obervable，直接调用addObserver方法添加观察者，观察者实现update(Observable o, Object arg)方法。

2.update内容对象是怎么定义，使用泛型吗

没有使用泛型，直接使用的Object。如果使用泛型，则会让Observer丧失掉扩展性，因为Observer同时订阅多个目标时，无法保证每个目标的通知对象都是同一个类。在实现update方法中，根据Observable来判定是哪个目前的更新消息，并通过instanceof 来判断Object的类型，并强制转化后使用

3.addObserver在哪里调用

在继承Observable的类中，调用addObserver方法

4.主题和具体观察者实现有无依赖关系？

从面向接口编程的角度来看，其实是有的，主题对象Observable会保存所有Observer，具体观察者会实现Observer的update方法。但是这一层依赖是松耦合的

5.自己可以实现简单的观察者模式，但是jdk是怎么抽象出来的。(领域模型设计)

从实现难度上来说，jdk自带的观察者模式并不难，且和自己实现起来的方式差别不大。

6.观察者是否需要保留主题对象的引用，不然怎么注册

不一定，看自己业务需要和代码层次。不建议混在一起，可以有个单独的类介于两者之间来做这件事情，

7.jdk这次observer是否支持推和拉两种方式？如何实现的

推为主，拉为次。一般推的数据已经很全的，但是也有可能数据太多只推一部分，业务根据各自需求，来从arg中获取，或另外通过RPC接口回调拉数据

8.Observable是类，不可多继承。

这边会限制Observable的使用，目标对象必须extendsObservable。由于java不可多继承类，所以在考虑类的继承实现关系上需要注意。但是本人认为这是Observable的一个优势，因为Observable已经帮忙实现了很多逻辑。但是如果在java8中，如果这个类可以换为接口，通过default方法提供目前JDK1.0就已经提供的功能，那就真是完美了。见common-utils的design-patterns模块的com.common.observer.jdk18包下实现

9.如何实现订阅多observable

对多个Observable调用addObserver方法，在Observer的update的实现中，对Observable的类型进行判断是哪个Observable目标，对不同目标，使用不同的处理逻辑。这里给出了实现源码，我自己实现了可多观察者观察多主题

10.微博订阅关系如何实现

这里我的理解还不能说服自己，所以先把这篇文章给大家Feed设计与实现

11.Observable使用了Vector obs来保存观察者， 为什么在addObserver 和 deleteObserver时使用synchronizend？

• Observer的Null值校验，Vector允许插入空值，但是观察者Observer不能为空
• Observer去重，Vector允许插入重复数据，但是业务上观察者模式需要允许多次订阅，但只通知一次
• 并发控制，避免在notifyObservers时获取观察者列表时有添加或移除动作发生

优势分析

1. jdk的实现简单，封装了简单的细节，容易使用，但是只能满足多对一的模式
2. 自己的多对多模式，就是为了解决jdk实现的不足，让观察者模式可以适用更多场景