设计模式之观察者模式

  首先我们给出观察者模式的定义：

       观察者模式（又被称为发布-订阅（Publish/Subscribe）模式，属于行为型模式的一种，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时，会通知所有的观察者对象，使他们能够自动更新自己。

       概念很清晰，我们举个例子来理解一下观察者模式的含义，我们都在新浪微博中关注过某一位明星，每当这位明星发布一条动态时候，他的粉丝就都会知道。我们使用一张图来表示一下他们的关系。

 

上面这位明星在新浪微博上发了一条动态，说他会唱、跳rap等等。然后他的粉丝就都知道了。从这个例子中我们可以看到，这里包含了两种人，第一种是明星，第二个是粉丝。转化为设计模式中的语言就是主题和观察者。

        我们的明星的微博就相当于与一个主题，粉丝就是观察者，随时观察明星的动态。不过明星有权利让你关注，也有权利把你拉黑。现在我们从类图的角度来看一下：

（1）Subject：抽象主题，他把所有观察者对象保存在一个集合里，可以有任意数量的观察者，抽象主题提供一个接口，可以增加和删除观察者对象。意思就是明星把所有的粉丝都保存在一个账号里面，粉丝数量不限，可以新增粉丝也可以拉黑粉丝。

（2）ConcreteSubject：具体主题，该角色将有关状态存入具体观察者对象，在具体主题的内部状态发生改变时，给所有注册过的观察者发送通知。意思是我们的明星一有动态，就会把消息给粉丝。

（3）Observer：抽象观察者，是观察者者的抽象类，它定义了一个更新接口，使得在得到主题更改通知时更新自己。这就是我们所有粉丝的抽象。

（4）ConcrereObserver：具体观察者，实现抽象观察者定义的更新接口，以便在得到主题更改通知时更新自身的状态。具体每一个粉丝。

观察者模式还是比较简单的。现在代码来实现一下:

定义抽象主题(Subject)：抽象明星

具体主题（ConcreteSubject）：具体的明星 

 

 抽象观察者（Observer）：抽象的粉丝

观察者（concreteObserver）：具体的粉丝 

测试 

 执行结果：

 

优点：

• 观察者和被观察者是抽象耦合的。
• 建立一套触发机制。

缺点：

• 如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
• 如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
• 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。

使用场景：

• 一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。
• 一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，可以降低对象之间的耦合度。
• 一个对象必须通知其他对象，而并不知道这些对象是谁。
• 需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。

注意事项：

JAVA 中已经有了对观察者模式的支持类。
避免循环引用。
如果顺序执行，某一观察者错误会导致系统卡壳，一般采用异步方式。

Spring事件监听-观察者模式

事件机制(Event)是spring的重要功能之一。虽然是Spring的重要功能之一，但在大部分人的日常开发中，却很少直接应用该功能。一句话概括用法场景：一个地方发出个通知，很多其他地方能收到通知并作出相应的动作。

在事件机制中有以下几个重要概念：

• 事件
• 事件发布者（一个）
• 事件监听者（多个）

spring事件驱动模型的结构.

 首先明确几个spring提供的类的概念

1.ApplicationEvent

　ApplicationEvent继承自jdk的EventObject,所有的事件都需要继承ApplicationEvent,并且通过source得到事件源.该类的实现类ApplicationContextEvent表示ApplicaitonContext的容器事件. 

2.ApplicationListener

 

ApplicationListener继承自jdk的EventListener,所有的监听器都要实现这个接口,这个接口只有一个onApplicationEvent()方法,该方法接受一个ApplicationEvent或其子类对象作为参数,在方法体中,可以通过不同对Event类的判断来进行相应的处理.当事件触发时所有的监听器都会收到消息,如果你需要对监听器的接收顺序有要求,可是实现该接口的一个实现SmartApplicationListener,通过这个接口可以指定监听器接收事件的顺序.

3.ApplicationContext

       事件机制的实现需要三个部分,事件源,事件,事件监听器,在上面介绍的ApplicationEvent就相当于事件,ApplicationListener相当于事件监听器,这里的事件源说的就是applicaitonContext.

　   ApplicationContext是spring中的全局容器,翻译过来是"应用上下文"的意思,它用来负责读取bean的配置文档,管理bean的加载,维护bean之间的依赖关系,可以说是负责bean的整个生命周期,再通俗一点就是我们平时所说的IOC容器.　

      Application作为一个事件源,需要显示的调用publishEvent方法,传入一个ApplicationEvent的实现类对象作为参数,每当ApplicationContext发布ApplicationEvent时,所有的ApplicationListener就会被自动的触发.

　  ApplicationContext接口实现了ApplicationEventPublisher接口,后者有一个很重要的方法:

 我们常用的ApplicationContext都继承了AbstractApplicationContext,像我们平时常见的ClassPathXmlApplicationContext、XmlWebApplicationContex也都是继承了它,AbstractApplicationcontext是ApplicationContext接口的抽象实现类,在该类中实现了publishEvent方法

   在这个方法中,我们看到了一个getApplicationEventMulticaster().这就要牵扯到另一个类ApplicationEventMulticaster.

4.ApplicationEventMulticaster

        属于事件广播器,它的作用是把Applicationcontext发布的Event广播给所有的监听器.

 

 

 　在AbstractApplicationcontext中有一个applicationEventMulticaster的成员变量,提供了监听器Listener的注册方法.

简单的事件监听

       定义事件

 

 监听类实现ApplicationListener

 发布这个事件

注解驱动 @EventListener

事件监听不在用ApplicationListener接口，而是基于注解@EventListener驱动

 

如果在方法内没有使用事件对象，方法上也可以去掉它，但是要指定这个方法监听的是哪个事件类。如： 

 

条件事件

在一些时候可能只要满足某些条件才进行对事件监听，这时就可以用@EventListener#condition属性来指定条件，条件是一个SpEL表达式，关于SpEL请参考baeldung SpEL 或官网SpEL

只有当id为“333”时才会进入监听事件

 

异步事件

结合@Async注解实现异步事件，使用很简单，只需要在相关方法或类上添加@Async注解，使用在方法上只针对这一个方法异步调用，使用在类上所有的方法都是异步调用；必须使用注解@EnableAsync开启异步功能

事物事件@TransactionalEventListener

从Spring4.2开始提供了一个新的事件监听注解@TransactionalEventListener，它是@EventListener的扩展，允许将事件的监听绑定到事物的一个阶段。有以下四个阶段：

• AFTER_COMMIT（默认值）事务成功提交时触发事件
• AFTER_ROLLBACK - 事务回滚
• AFTER_COMPLETION - 事务已完成（AFTER_COMMIT 或 AFTER_ROLLBACK）
• BEFORE_COMMIT 在事务提交之前触发事件

 

仅当存在事件生成器正在运行且即将提交的事务时，才会调用此侦听器。

并且，如果没有正在运行的事务，则根本不发送事件，除非我们通过将fallbackExecution 属性设置为true来覆盖它 ，即@TransactionalEventListener(fallbackExecution = true)。

新事件继续传播

当我们监听一个事件处理完成时，还需要发布另一个事件，一般我们想到的是调用ApplicationEventPublisher#publishEvent发布事件方法，但Spring提供了另一种更加灵活的新的事件继续传播机制，监听方法返回一个事件，也就是方法的返回值就是一个事件对象。