观察者设计模式 Vs 事件委托（java）

【原文地址  点击打开链接】

1

什么是观察者模式

   

简单来说，当有多个观察者想同时观察同一个主题对象的时候，当主题对象的 状态发生变化，观察者能够回调自身的方法去更新自己

观察者模式的类UML图

1.1 实现步骤

要定义一个观察者接口

观察者实现观察者接口

要有一个被通知者接口，里面有addObserver（Observer observer）， 

removeObserver（Observer observer）， notifyObservers（）方法

在被观察者发生变化的时候，调用 notifyObservers（），遍历List，回调observer里面的方法

举例：

Android系统内容提供者 ，内容观察者就采用了这种观察者模式

RecyClerView和ListView的 Adapter就采用了观察者模式,关于RecyclerView的Adapter是怎样实现观察者模式的，可以参考我的 这篇博客 关于RecyclerView的Adapter的notifyItemInserted（）的一些分析（http://blog.csdn.net/gdutxiaoxu/article/details/51698261）

当两个界面想同时观察下载进度的话，可以采用观察者模式来解耦。

1.2 情景实例

班主任来啦！ 

小A对小B说：“今天真是笑死人了，我们班一位同学在仔细的时候看NBA球赛，被班主任抓了个正着。班主任脸都绿了，哈哈，真是笑死我了。 

小B说：”啊，你们怎么同学怎么敢在课上看电视啊？“ 

小A说：”没有的，他们那帮子男生经常自习的时候看球赛的。我们班有个女生坐在前排，那些男生就给她送写小礼物啊什么的。班主任来了，那个女生就去通知敲一下桌子。“ 

小B说：”好吧。这也行。那今天怎么会有人被抓？“ 

小A说：”这是因为刚好班主任来的时候，那个女生去上厕所了。结果一个看漫画的男生没被抓，那个看NBA球赛的男生被抓了。手机都被没收了呢！” 

小B说：“好吧。你说的这个场景，让我想起了一个设计模式，叫做观察者模式。要不给你讲讲？” 

小A吐血，倒地不起。。。。。。

1.3 代码示例

我们先来看一下被观察者接口

接着我们先来看一下观察者接口

接下来我们来看一下ConcreteSubject是怎样实现的:

简单来说就是当添加观察者的时候判断是否存在当前的观察者 ，不存在的话，添加到List集合当中

移除观察者的时候直接从List集合移除

当Subject的状态发生变化的时候，遍历List，调用Observer的update方法去更新自身

最后我们来看一下具体的ConcreteObserver具体做了什么? 

这里为了方便，就只是打印出当前的类名和通知者发出的消息而已，在具体的情景当中，我们可以拿着 Object data 去更新 自身的状态。

运行一下测试代码:

我们可以看到 输出以下的信息：

我是CartoonObserver， 老师来了别看漫画了

我是NBAObserver， 老师来了别看NBA了

观察者模式的实现分析到此为止。

1.4 观察者模式的优缺点

优点：

很好地解耦了通知者与观察者，观察者不需要了解通知者内部是怎样实现的，方便于日后代码的修改，体现了 依赖倒转的原则。

缺点分析：

“上面该机的代码中抽象通知者还是依赖了抽象观察者，万一没有抽象观察者，那岂不是功能都完成不了啦！

还有你这上面代码写的，所以对象更新的动作都一样的。万一我对象更新不一样呢？

比如，看NBA球赛的听见班主任来了就跑去上厕所，而看漫画的听见班主任来了就继续看书。代码又应该怎么写呢？”小A，揉了揉惺忪的睡眼，疑惑地问道。

小B说：“我去，我还以为你睡着了呢！原来你在听啊！我太高兴了。下面我们就利用一种叫做“事件委托”的东东去解决这个问题哈！”

小A说：“我滴个神，什么叫事件委托啊？”

2

事件委托

   

我们先来看一下 我们的通知者GoodNotifier是怎样实现的？

接着我们在来 看它的父类Notifier是怎样实现的：

看了上面notifier的代码以后，你是不是有一种似曾相识的感觉，是不是感觉跟我们的观察者模式中的通知者很相似。

观察者模式我们的通知者是这样实现的：

@Override
public void notifyAllObserver(Object data) {
   for (Observer observer : mList) {
       observer.update(this,data);
   }
}

在事件委托中我们是这样实现的：

两者的区别其实即使我们将其交给EventHandler去处理。

下面我们来看一下EventHandler我们是怎样实现的：

其实跟观察者 模式一样，我们把我们的事件对象存储在

objects=new ArrayList<Event>();  

当我们添加 事件的时候，把事件封装为Event对象，再添加到objects中

objects.add(new Event(object,methodName,args));

当我们要通知事件的时候，再遍历List，通知每一个事件对象

for(Event e : objects){  
    e.invoke();  
}

看到invoke()这个方法，你是不是想到了什么，没错，就是java的反射机制，我们封装在Event类 中，下面我们来看一下Event类是怎样实现的：



在Event类我们invoke()方法所做的工作就是根据我们的对象的方法名，方法参数，利用发射执行方法。

运行一下测试代码：

结果如下：

WatchCartoonListener 我正在看漫画，开始时间：Mon Jul 04 13:25:34 CST 2016

WatchingNBAListener我正在看NBA,开始时间是： Mon Jul 04 13:25:34 CST 2016

有新的同学委托尽职尽责的放哨人!

有新的同学委托尽职尽责的放哨人!

尽职尽责的放哨人告诉所有需要帮忙的同学：老师来了

WatchCartoonListener 老师来了，不要看漫画了，结束时间：Mon Jul 04 13:25:34 CST 2016

WatchingNBAListener老师来了，快关闭NBA直播 ， 结束时间是：Mon Jul 04 13:25:34 CST 2016

3

总结

   

观察者优缺点

优点：

    很好地解耦了代码，体现了 依赖倒转的原则

缺点:

抽象通知者还是依赖了抽象观察者，当没有观察者的时候，没办法更新

要求观察者的所有动作 必须一样 ，如果不一样的话，不能实现。

事件委托机制分析

放哨者完全不知道做游戏者的存在，完全解耦。（当然，功劳归功于Event和EventHandler，且这两个类具有通用性）

老师来了后游戏者停止游戏回到座位，看NBA者停止看NBA，看漫画这停止看漫画，玩游戏这停止玩游戏。（一次通知，执行了不同类的不同方法）

扩展性很高，再来一个打篮球的学生就先写个打篮球学生类，并在测试代码中告诉放哨者一下就好，放哨者完全没有变，重用性好。

PS：Java中是没有像c#delegate关键字的，所以我是通过用Java中的反射来实现。

题外话：为了写这篇博客，也是蛮累的，前前后后查阅了很多资料，不过还是很值得，加深了我对观察者模式的理解，更重要的是学会了如何在实际中运用反射机制

参考文章：
http://blog.csdn.net/XIAXIA__/article/details/41803473
源码下载地址：
http://download.csdn.net/detail/gdutxiaoxu/9567209