Guava - EventBus(事件总线)

Guava在guava-libraries中为我们提供了事件总线EventBus库,它是事件发布订阅模式的实现,让我们能在领域驱动设计(DDD)中以事件的弱引用本质对我们的模块和领域边界很好的解耦设计。

不再多的废话,直奔Guava EventBus主题。首先Guava为我们提供了同步事件EventBus和异步实现AsyncEventBus两个事件总线,他们都不是单例的,官方理由是并不想我们我们的使用方式。当然如果我们想其为单例,我们可以很容易封装它,一个单例模式保证只创建一个实例就对了。

下面将以EventBus为例,AsyncEventBus使用方式与其一致的。

订阅

首先EventBus为我们提供了register方法来订阅事件,Guava在这里的实现很友好,我们不需要实现任何的额外接口或者base类,只需要在订阅方法上标注上@Subscribe和保证只有一个输入参数的方法就可以搞定。这样对于简单的某些事件,我们甚至可以直接

new Object() {

    @Subscribe
    public void lister(Integer integer) {
        System.out.printf("%d from int%n", integer);
    }
}

Guava发布的事件默认不会处理线程安全的,但我们可以标注@AllowConcurrentEvents来保证其线程安全

发布

对于事件源,则可以通过post方法发布事件。 正在这里对于Guava对于事件的发布,是依据上例中订阅方法的方法参数类型决定的,换而言之就是post传入的类型和其基类类型可以收到此事件。例如下例:

final EventBus eventBus = new EventBus();
eventBus.register(new Object() {

    @Subscribe
    public void lister(Integer integer) {
        System.out.printf("%s from int%n", integer);
    }

    @Subscribe
    public void lister(Number integer) {
        System.out.printf("%s from Number%n", integer);
    }

    @Subscribe
    public void lister(Long integer) {
        System.out.printf("%s from long%n", integer);
    }
});

eventBus.post(1);
eventBus.post(1L);

在这里有 Integer,Long,与它们基类Number。我们发送一个整数数据的时候,或者Integer和Number的方法接收,而Long类型则Long类型和Number类型接受。

所以博主建议对于每类时间封装一个特定的事件类型是必要的。

DeadEvent

DeadEvent暂时不清楚怎么翻译更合意,它描述的是死亡事件,即没有没任何订阅者关心,没有被处理,以DeadEvent类型参数的方法表示.例如在上例中我们post一个Object类型,如下:

final EventBus eventBus = new EventBus();
eventBus.register(new Object() {

    @Subscribe
    public void lister(DeadEvent event) {
        System.out.printf("%s=%s from dead events%n", event.getSource().getClass(), event.getEvent());
    }
});

eventBus.post(new Object());

更多Guava博文:

  1. Guava – 并行编程Futures
  2. Guava – EventBus(事件总线)
时间: 2024-10-06 11:24:15

Guava - EventBus(事件总线)的相关文章

EventBus 事件总线 简介 案例

简介 地址:https://github.com/greenrobot/EventBus EventBus是一款针对Android优化的发布/订阅事件总线.主要功能是替代Intent,Handler,BroadCast在Fragment,Activity,Service,线程之间传递消息. 优点是开销小,代码更优雅,以及将发送者和接收者解耦. 包含4个成分:发布者,订阅者,事件,总线. 这四者的关系:订阅者订阅事件到总线,发送者发布事件:订阅者可以订阅多个事件,发送者可以发布任何事件,发布者同时

EventBus事件总线分发库

本文围绕以下六个部分展开: 一.事件总线管理 二.EventBus 三.EventBus与BroadcastReceiver的区别 案例一 案例二:一处点击发送数据,另一处或多处注册点可以及时获取更新传输过来的数据 案例三:Activity和Service之间互相发布与接收事件 一.事件总线管理 将事件放入队列里,用于管理和分发. (1)保证应用的各个部分之间高效的通信及数据.事件分发. (2)模块间解耦:通过事件的分发,可以让各个模块间关联程序变小. 当在开发一些庞大的的项目时,模块比较多,这

Android EventBus事件总线剖析

概述 EventBus是一款针对Android优化的发布/订阅事件总线.主要功能是替代Intent,Handler,BroadCast在Fragment,Activity,Service,线程之间传递消息. 它是一个基于观察者模式的事件发布/订阅框架,开发者可以通过极少的代码去实现多个模块之间的通信,而不需要以层层传递接口的形式去单独构建通信桥梁.从而降低因多重回调导致的模块间强耦合,同时避免产生大量内部类.它拥有使用方便,性能高,接入成本低和支持多线程的优点,实乃模块解耦.代码重构必备良药.

Orchard EventBus 事件总线及 IEventHandler作用

事件总线接口定义: public interface IEventBus : IDependency { IEnumerable Notify(string messageName, IDictionary<string, object> eventData); } messageName 参数说明 : _eventBus.Notify(interfaceName + "." + methodName, data/*接口方法参数*/); 事件总线作用: 当调用Notify时

EventBus 事件总线 原理

原理 一句话描述:register会把当前类中匹配的方法,存入一个map,而post会根据实参去map查找进行反射调用 撇开专业术语,其实EventBus就是在内部[存储]了一堆onEvent开头的方法,然后post的时候,根据post传入的[参数],去找到匹配的方法,[反射]调用之. 另外,它内部使用了[Map]进行存储,[键就是参数的Class类型].知道是这个类型,那么你觉得根据post传入的参数进行查找还是个事么? 其实不用发布者,订阅者,事件,总线这几个词或许更好理解,以后大家问了Ev

EventBus 事件总线模式实例(发布/订阅事件)

在我们公司经常用到总线,具体的总线是什么让我理解我也不清楚,但是在这几个月下来,我已经知道总线如何使用,现在加上示例讲解总线如何使用. 1. 首先我们的新建一个类,这个类其实是用于总线传递的模型 using System; namespace PurchaseDevices.Model.CommonModel{/// <summary>/// 事件传递参数/// </summary>/// <typeparam name="T"></typep

EventBus事件总线框架(发布者/订阅者模式,观察者模式)

一. android应用内消息传递的方式: 1. handler方式-----------------不同线程间传递消息. 2. Interface接口回调方式-------任意两个对象. 3. Intent进行组件间通信,广播方式. 二.单例比较好的写法: private static volatile EventBus defaultInstance; 构造函数应当是private,不应该是public 1 public static EventBus getDefault() { 2 if

android事件总线(eventbus)设计与实现

1. 功能介绍 AndroidEventBus是一个Android平台的事件总线库, 它简化了Activity.Fragment.Service等组件或者对象之间的交互,很大程度上降低了它们之间的耦合,使得我们的代码更加简洁,耦合性更低,提升我们的代码质量. AndroidEventBus吸收了greenrobot的EventBus以及square的otto的优点,并在此基础上做出了相应的改进,使得事件总线框架更适合用户的使用习惯,也使得事件的投递更加的精准.灵活. 与EventBus.otto

Java事件总线

在平时写代码的过程中,我们需要实现这样一种功能:当执行某个逻辑时,希望能够进行其他逻辑的处理.最粗暴的方法是直接依赖其他模块,调用该模块的相应函数或者方法.但是,这样做带来一些问题. 模块间相互依赖,耦合度高.以下订单为例,订单提交后需要进行支付以及进行一些其他处理,如发邮件等操作.相关的代码可能是这样.可以看到:订单模块依赖了支付服务以及用户服务. 维护困难.由于模块间相互依赖,当需要修改订单逻辑时则需要修改submitOrder方法的源代码,而某些时候可能无法修改.再者,如果有多个这种逻辑,