Java事件总线编程初探Why?观察者模式Guava EventBus——监听者模式的优雅实现

在平时写代码的过程中，我们需要实现这样一种功能：当执行某个逻辑时，希望能够进行其他逻辑的处理。最粗暴的方法是直接依赖其他模块，调用该模块的相应函数或者方法。但是，这样做带来一些问题。

模块间相互依赖，耦合度高。以下订单为例，订单提交后需要进行支付以及进行一些其他处理，如发邮件等操作。相关的代码可能是这样。可以看到：订单模块依赖了支付服务以及用户服务。

维护困难。由于模块间相互依赖，当需要修改订单逻辑时则需要修改submitorder方法的源代码，而某些时候可能无法修改。再者，如果有多个这种逻辑，修改时可能涉及到多处操作。

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

通过观察者模式来进行解耦，当对象发生变化时，通知其观察者，由观察者进行相应的处理。体现在订单逻辑中时即为,定义多个观察者观察下订单这个主题，当下订单的动作发生时，通知其所有观察者。再由每个观察者进行处理。依据观察者模式的实现，以上逻辑可改为如下代码：

可以看到，首先定义了orderlistener接口，接口中有一个onsubmitorder方法。原始的实现中的payservice和userservice实现了该接口。orderpage中维护了一个orderlistener列表，当提交订单时调用所有监听者的onsubmitorder方法。可以看到此实现的订单逻辑没有直接依赖付款模块和用户模块。 主程序通过添加监听器来使其得到通知.

虽然监听者模式对源代码进行了解耦，但是还是有一些不足。

相关模块需要实现相应接口；

需要主动调用相关的addlistener方法设置监听器。

一个监听器智能监听一种操作.

eventbus是guava对于监听者模式的实现，其使用非常简单。使用eventbus来实现监听者模式，只需要三步操作。

通过注解@subscribe来声明事件回调方法；

调用eventbus的register方法来注册监听器；

通过post方法来触发事件；

订单逻辑通过eventbus事件总线来实现，大概是以下这个样子。

要实现监听者模式，时需要调用eventbus的register方法进行注册，在需要处理事件的方法上使用@subscribe注解。最后通过eventbus发布事件即可。使用事件总线，不需要定义特定的接口，不需要主动添加监听器；

eventbus通过register方法来注册处理相应事件的类，

其核心是findallsubscribers，找到实例中所有有subscribe注解的方法并保存。返回的是一个multimap < class<?>,eventsubscriber>类型，其中class是事件类型，eventsubsciber包含了类实例和具体处理事件的方法。multimap保证了一种事件可以有多个监听者来处理。

eventbus通过post方法来发布事件，首先通过事件类型找到需要处理的事件：事件本身以及其父类。根据事件类型从事件订阅的缓存中取出处理该事件的订阅者，并将其入队。最后处理该队列中的数据。