特点:
-
被观察者持有监听的观察者的引用
-
被观察者支持增加和删除观察者
-
被观察者主题状态改变,通知观察者
-
下面开始模拟观察者设计模式
-
版本1:
-
版本1模拟的观察者设计模式,是采用了观察者持有被观察者的实例的方式。该方式存在的问题,也是比较明显: 观察者需要不断的执行,监听被观察者的状态。性能耗费比较大。
-
版本2:
-
版本2模拟的观察者设计模式,是采用了被观察者持有观察者的实例的方式。该方式存在的问题,也是比较明显: 被观察者强制依赖了观察者,耦合度比较高。
-
版本3:
-
版本3模拟的观察者设计模式,有了几个方面的提升: 被观察者持有监听的观察者的引用 被观察者支持增加观察者 观察者已通过MovieListener接口抽象,与被观察者的耦合性降低了。
观察者设计模式的特点: 被观察者持有监听的观察者的引用 被观察者支持增加和删除观察者 被观察者主题状态改变,通知观察者
总结: 观察者设计模式 用 “订阅”和“发布“”来理解更好 为什么呢?因为监听器这个名词听起来是一个主动的,可实际监听器是一个被动的玩意 比如我们事件源发布一个事件,然后监听器订阅了这个事件就能做出动作。 里面涉及到三个对象,事件源,事件、监听器,好好理解一下。
-
JDK的观察者设计实现:
-
JDK中观察者的实现: java.util.Observable 这是一个类,继承,被观察者 java.util.Observer 这是一个接口,实现,观察者 观察者impl Observer重写update方法: 当被观察者发生变化,收到通知进行具体的管理 可以随时取消
-
Spring中实现:
-
Spring中的Events
事件通过org.springframework.context.ApplicationEvent实例来表示。这个抽象类继承扩展了java.util.EventObject,可以使用EventObject中的getSource方法,我们可以很容易地获得所发生的给定事件的对象。这里,事件存在两种类型
-
与应用程序上下文相关联
-
所有这种类型的事件都继承自org.springframework.context.event.ApplicationContextEvent类。 它们应用于由org.springframework.context.ApplicationContext引发的事件(其构造函数传入的是ApplicationContext类型的参数)。
-
这样,我们就可以直接通过应用程序上下文的生命周期来得到所发生的事件:
-
在上下文启动时被启动ContextStartedEvent,
-
当它停止时启动ContextStoppedEvent,
-
当上下文被刷新时产生ContextRefreshedEvent,
-
最后在上下文关闭时产生ContextClosedEvent
-
与request 请求相关联 由org.springframework.web.context.support.RequestHandledEvent实例来表示,当在ApplicationContext中处理请求时,它们被引发。
Spring如何将事件分配给专门的监听器?
这个过程由事件广播器来实现,由org.springframework.context.event.ApplicationEventMulticaster接口的实现表示。此接口定义了3种方法
(1)addApplicationListener():添加新的监听器 定义了两种方法来添加新的监听器:addApplicationListener(ApplicationListener<?> listener)和addApplicationListenerBean(String listenerBeanName) 当监听器对象已知时,可以应用第一个。如果使用第二个,我们需要将bean name 得到listener对象(依赖查找DL),然后再将其添加到listener列表中
(2)removeApplicationListenerBean(String listenerBeanName):删除监听器 通过传递对象来删除一个监听器(removeApplicationListener(ApplicationListener<?> listener)或通过传递bean名称。 第三种方法,removeAllListeners()用来删除所有已注册的监听器。
(3)multicastEvent(ApplicationEvent event):将事件发送到已注册的监听器