Motivation

想象一下，有一个包含大量相互交互的组件的大型应用程序，并且您想要一种方法使您的组件进行通信，同时保持松散耦合和关注点分离原则，事件总线模式可以很好地解决您的问题。

事件总线的想法实际上与网络（总线拓扑）中研究的总线非常相似。 你有某种管道和连接到它的计算机，每当其中一个发送消息时，它就会被分派给所有其他人。 然后，他们决定是要使用给定的消息还是只是丢弃它。

在组件级别，它非常相似：计算机是您的应用程序组件，消息是您要通信的事件或数据，管道是您的 EventBus 对象。

下面是一种经典的实现方式，因为它依赖于定义您的 EventBus 接口（强制给定的合约），以您想要的方式实现它，并定义一个 Subscribable（另一个合约）来处理 Event（和另一个合约）消费。

定义一个事件接口：

定义事件的监听者即事件消费者：

事件总线的实现：

Subscribable 通过定义 supports 方法声明了一种方法来处理给定类型的对象以及它支持的对象类型。

EventBus 实现持有所有 Subscribables 的列表，并在每次有新事件进入 EventBusdispatch 方法时通知所有订阅者。

选择此解决方案可为您提供编译时间来检查传递的 Subscribables，而且，这是一种更面向对象的方式，不需要反射魔法，而且如您所见，它很容易实现。 缺点是契约强制的事情——你总是需要一个新的类来处理一种类型的事件，一开始这可能不是问题，但随着你的项目的增长，你会发现创建一个有点重复 类只是处理简单的逻辑，例如日志记录或统计信息。