spring boot 源码解析准备二(观察者模式)

举例场景说明;一个人一直在看电影,当电影播放到4秒的时候,这个人要去上厕所。

图1

图2

首先设置一个标记来标记是否已经到了需要上厕所的时间。如果到了把他改为true;

图3

这个人一直在看电影直到电影那边返回true他才要去上厕所。

run方法以下面的为准。

通过上面的例子我们发现,这个人一直在看电影,一直在while循环中,这样cpu消耗很大。我们能不能改成这样比如电影在播出4秒后主动通知这个人呢,这样这个人就可以做其他事情,没有必要一直在while循环中。

这个就是所谓的观察者模式。

图4

被观察者持有观察者的引用。下面是修改后的

图5

图6

改成这样但是问题又来了,如果这个电影有温情的片段,应该有落泪的动作,有搞笑的片段,应该笑等动作,而不单单只是上厕所这么一个动作。那么 我们可以把温情的片段,搞笑的片段抽取为一个事件。这个事件可以根据不同的片段场景来做不同的动作。

图7

 

这个是事件类。source是事件源;为什么要有事件源呢,举例,吃饭可能对应多个事件源,人,饭,筷子,等事件源。

图8

图9

图10

执行结果。问题来了。如果不是一个人看电影,多个人看电影咋办。多个人看电影的同一个场景有可能有不同的动作。例如a 看到温情会调眼泪,b看到温情会大笑。

图11

 不可能在这个里面在传入一个b人的参数吧,如果多个人,难道要传n个参数吗, 于是就有了监听器的概念(监听器里抽象出一个公共的动作方法接口,每一个人均要实现他这个方法,来执行不同的动作),监听器是一个包含多个人的list也可以说是包含多个观察者的list, 对外提供一个add方法。当有一个人的时候,add进去一个人,多个人的时候add多个人,。在事件片段发生的时刻,依次遍历调用每一人的动作方法。

图12

监听器。

图13

 

图14

图15

 

图16

 

 

图17

 

jdk的观察者模式。

图18

被观察者。

图18-0

图18-2 

图19

 

观察者

图20

观察者。 Observable为被观察者。

传说中观察者的设计模式可以取消,咋取消啊。图21

图21

结果确实不打印了。这种观察者模式的好处时解耦。

图22

任何一步出现问题,这个订单就下载失败,这个是没有办法接受的。

图23

监听模式是这样,多个监听器来监听,一旦订单生成。第一个监听器负责发红包,第二个负责发短信。如果我们这个是做活动。一旦不需要可以灵活去掉,采用从监听器中移除。这个是jdk的观察者模式,在spring中是什么样的呢,

图24

Spring中观察者模式。

图25

 

 图26

对应的子事件。这几个事件的事件源都是ApplicationContext

图27

 图27-1   

 自定义事件,继承ApplicationEvent 

图27-2

自定义监听器。 

图27-3

,触发事件,赋值事件源。

图27-4

执行结果。 

图28

 

spring中有个事件委派器,当event1发生事件后通过ApplicationEvenMulticater 委派给listener1. 

发布了23 篇原创文章 · 获赞 0 · 访问量 690
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览