监听器模式和观察者模式的关系,写点你不知道的

安全 应用安全
通过本篇文章我们知道,监听器模式的本质就是观察者模式,先将回调函数注册到被观察对象,当被观察对象发生变化时,通过回调函数告知观察者/监听者。而Spring中事件管理也是基于观察者模式实现的,算是一个比较经典的案例。

[[404308]]

本文转载自微信公众号「程序新视界」,作者二师兄。转载本文请联系程序新视界公众号。

前言

无论大家在实践中是否自己实现过观察者模式或监听器模式,但肯定间接使用过。比如Spring的事件机制,大多数人肯定都用过,只是没留意而已。

今天这篇文章主要围绕观察者模式、监听器模式,以及它们之间的关系展开。不仅用实例介绍它们的使用,而且也会聊一聊Spring事件机制对观察者模式的实践。

监听器模式和观察者模式怎么看起来是一样的?

先聊聊设计模式

为什么要使用监听模式,直接调用不好吗?这我们就要说说设计模式的好处了。设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。同时,采用设计模式之后,代码能够达到低耦合、低依赖的效果。

也就是说,即便不用设计模式,直接硬编码也能实现。但如果考虑到代码的耦合性、依赖性、扩展性等问题,设计模式便是更好的选择。比如观察者模式就能达到解耦、异步等效果。

观察者模式的定义

观察者模式定义了对象之间的一对多依赖,即一个主题对应多个观察者。当一个主题对象改变状态时,它的所有依赖者(观察者)都会收到通知并自动更新。比如用户订阅某个订阅号或公众号,当发新消息时,会发送给所有订阅者。

观察者模式解决的是对象和对象之间的依赖关系。当多个对象依赖一个对象的关系时,一个主题对象状态改变,需要通知所有观察者对象。

监听器模式并不是一个新的设计模式,它是观察者模式在特定场景下的一种改造和应用。通常,观察者模式的主题在通知观察者时,通知中不包含任何信息。如果这个过程中携带了一些其他信息,那么主题本身就成为了事件源,而携带信息的封装类就成为了事件。此时的观察者模式,也就升级为监听器了。监听器模式是观察者模式的另一种形态。

观察者模式实例

先来看看观察者模式的代码实现,可以直接使用JDK自带的Observer,也可以自定义对应的API。单从JDK自带观察者模式的API,也可以看出该设计模式的分量(虽然在Java被废弃了)。

我们这里采用自定义相关类,主要包括主题和观察者两种对象。

首先定义一个主题对应的接口Subject:

  1. public interface Subject { 
  2.  
  3.     /** 
  4.      * 注册定义 
  5.      */ 
  6.     void registerObserver(Observer observer); 
  7.  
  8.     /** 
  9.      * 发送通知 
  10.      */ 
  11.     void notifyObservers(Object msg); 
  12.  

主题接口中定义了两个方法一个用来注册观察者,一个用来发送通知。定义这个主题的具体实现类ConcreteSubject:

  1. public class ConcreteSubject implements Subject { 
  2.  
  3.     /** 
  4.      * 观察者集合 
  5.      */ 
  6.     private List<Observer> observers = new ArrayList<>(); 
  7.  
  8.     @Override 
  9.     public void registerObserver(Observer observer) { 
  10.         // 添加订阅关系 
  11.         observers.add(observer); 
  12.     } 
  13.  
  14.     @Override 
  15.     public void notifyObservers(Object msg) { 
  16.         // 通知订阅者 
  17.         for (Observer observer : observers) { 
  18.             observer.update(msg); 
  19.         } 
  20.     } 

实现类中存储了,观察者的集合,这样就实现了主题和观察者之间一对多的关系。

创建一个观察者接口Observer,方便管理:

  1. public interface Observer { 
  2.     // 处理业务逻辑 
  3.     void update(Object msg); 

定义观察者接口的具体实现类ConcreteObserver:

  1. public class ConcreteObserver implements Observer { 
  2.  
  3.     @Override 
  4.     public void update(Object msg) { 
  5.         // 业务逻辑实现 
  6.         System.out.println("ConcreteObserver 接收到主题的消息: " + msg); 
  7.     } 

在实现类中,打印一行消息。当然,在实践的过程中,这个实现类可以通过匿名类的形式创建,这样就具体的匿名类就在registerObserver时定义了。

下面来测试一下:

  1. public class ConcreteObserver implements Observer { 
  2.  
  3.     @Override 
  4.     public void update(Object msg) { 
  5.         // 业务逻辑实现 
  6.         System.out.println("ConcreteObserver 接收到主题的消息: " + msg); 
  7.     } 

执行程序,打印结果:

  1. ConcreteObserver 接收到主题的消息: 来自Subject的消息 

说明可以正常接收到主题发布的消息。

在上面的实现中,可以看出已经达到了解耦合的效果,同时减少了依赖关系。每个观察者根本不需要知道发布者处理了什么业务逻辑,也不依赖于发布者的业务模型,只关心自己的逻辑处理即可。

监听模式实例

监听器模式通常包含三个角色:事件源、事件对象、事件监听器。如果观察者模式中的类名和方法对照改一下,并不改变业务逻辑,我们来看看是啥效果。

比如,将Observer改名为Listener,将其update方法改为onClick();将Subject的实现类ConcreteSubject改名为ListenerSupport,将registerObserver方法更名为addListener……

定义一个事件对象Event,用来传递事件信息:

  1. public class Event { 
  2.     private String data; 
  3.     private String type; 
  4.  
  5.     Event(String data, String type) { 
  6.         this.data = data; 
  7.         this.type = type; 
  8.     } 
  9.     // 省略getter/setter 

原来主题的订阅对象Observer改名为Listener之后,成为监听器:

  1. public interface Listener { 
  2.     void onClick(Event event); 

为监听器提供一个实现类,当然在实践中也可以采用匿名类创建的方式:

  1. public class ListenerA implements Listener { 
  2.  
  3.     @Override 
  4.     public void onClick(Event event) { 
  5.         System.out.println("触发事件,type:" + event.getType() + ",data:" + event.getData()); 
  6.     } 

原来的主题ConcreteSubject对照ListenerSupport成为事件管理器:

  1. public class ListenerSupport { 
  2.  
  3.     private List<Listener> listeners = new ArrayList<>(); 
  4.  
  5.     public void addListener(Listener listener) { 
  6.         listeners.add(listener); 
  7.     } 
  8.  
  9.     public void triggerEvent(Event event) { 
  10.         for (Listener listener : listeners) { 
  11.             listener.onClick(event); 
  12.         } 
  13.     } 

对应的测试代码:

  1. public class EventTest { 
  2.  
  3.     public static void main(String[] args) { 
  4.         Listener listener = new ListenerA(); 
  5.         ListenerSupport listenerSupport = new ListenerSupport(); 
  6.         listenerSupport.addListener(listener); 
  7.         listenerSupport.triggerEvent(new Event("dataA""typeA")); 
  8.     } 

执行程序,打印信息如下:

  1. 触发事件,type:typeA,data:dataA 

通过上面的对照代码,我们可以看出,即便业务逻辑不变,经过重命名的观察者模式已经变为监听器模式了。而它们的对照关系是:事件源对照ConcreteSubject(主题)、事件对象对照update方法的Object、事件监听器对照ConcreteObserver(订阅者)。这也再次证明了所说的“监听器模式是观察者模式的另一种形态”。

观察者模式和监听器模式对比

用一张图,来比较观察者模式和监听器模式的联系和区别:

通过对比可以发监听器模式的优势是:在很多场景中,通知中附带了一些必不可少的其他信息,而事件Event可以对这些信息进行封装,使它本身拥有了多态的特性。每个事件对象就可以包含不同的信息。从这个层面来说,事件监听器模式是对观察者模式进行了进一步的抽象。

Spring中的最佳实践

观察者模式的经典应用算是Spring事件驱动模型了,它便是基于观察者模式实现的,同时也是项目中最常见的事件监听器。

Spring中观察者模式包含四个角色:事件、事件监听器、事件源、事件管理。

事件:ApplicationEvent是所有事件对象的父类。ApplicationEvent继承自jdk的EventObject,所有的事件都需要继承ApplicationEvent,并且通过source得到事件源。Spring 提供了很多内置事件,比如:ContextRefreshedEvent、ContextStartedEvent、ContextStoppedEvent、ContextClosedEvent、RequestHandledEvent。

事件监听器:ApplicationListener,也就是观察者,继承自jdk的EventListener,该类中只有一个方法onApplicationEvent,当监听的事件发生后该方法会被执行。

事件源:ApplicationContext,ApplicationContext是Spring的核心容器,在事件监听中ApplicationContext可以作为事件的发布者,也就是事件源。因为ApplicationContext继承自ApplicationEventPublisher。在ApplicationEventPublisher中定义了事件发布的方法:publishEvent(Object event)。

事件管理:ApplicationEventMulticaster,用于事件监听器的注册和事件的广播。监听器的注册就是通过它来实现的,它的作用是把Applicationcontext发布的Event广播给它的监听器列表。

小结

 

通过本篇文章我们知道,监听器模式的本质就是观察者模式,先将回调函数注册到被观察对象,当被观察对象发生变化时,通过回调函数告知观察者/监听者。而Spring中事件管理也是基于观察者模式实现的,算是一个比较经典的案例。

 

责任编辑:武晓燕 来源: 程序新视界
相关推荐

2020-10-26 08:45:39

观察者模式

2022-01-29 22:12:35

前端模式观察者

2021-09-06 10:04:47

观察者模式应用

2013-11-26 17:09:57

Android设计模式

2021-07-08 11:28:43

观察者模式设计

2011-04-29 09:22:22

2021-07-08 07:52:49

容器监听器Event

2022-05-09 10:50:13

观察者模式设计模式

2015-11-25 11:10:45

Javascript设计观察

2024-02-18 12:36:09

2009-03-30 09:39:04

观察者思想换位设计模式

2012-08-27 10:52:20

.NET架构观察者模式

2021-03-29 07:14:28

Spring观察者模式

2022-11-15 07:35:50

Spring事件观察者模式

2021-01-25 05:38:04

设计原理VueSubject

2020-07-28 08:26:34

WebSocket浏览器

2020-06-12 09:20:33

前端Blob字符串

2021-11-08 11:32:01

观察

2022-04-08 09:01:14

数字货币区块链

2021-10-22 09:41:26

桥接模式设计
点赞
收藏

51CTO技术栈公众号