Eventbus 是中介者模式还是观察者模式？
Eventbus 更像是中介者还是观察者？据谷歌称， “eventbus mediator”获得 2.430 次点击， “eventbus观察者”获得 3.850 次点击。
从描述来看，它们都符合我想要做的事情（调解器甚至更多）。 那么 eventbus 是否实现了特定的模式，还是由我来决定？
Is Eventbus more a Mediator or an Observer? According to Google,
"eventbus mediator" gets 2.430 hits and
"eventbus observer" gets 3.850 hits.
From the description, they would both match what I was trying to do (the mediator even a little more).
So does eventbus implement a specific pattern or is it up to me which I say it is?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
通常，一段给定的代码本质上并不是一种模式或另一种模式的示例。这就是为什么它们被称为“模式”（而不是“实现技术”）。很多软件看起来有点像一种模式，但也类似于另一种模式——这很好。最好不要为了模式而遵循模式，而是将它们用作讨论架构的共享词汇。
EventBus 就是这样的工具之一。我在编写它时考虑了类似观察者的情况，但如果您适当地构建应用程序，它可以发挥类似中介者的作用。
Often, a given piece of code isn't intrinsically an example of one pattern or another. This is why they're called "patterns" (rather than, say, "implementation techniques"). A lot of software kinda looks like one pattern, but also resembles another -- this is good. It's best not to adhere to patterns for patterns' sake, but to use them as a shared vocabulary for discussing architecture.
EventBus is one such tool. I wrote it with Observer-like situations in mind, but if you structure your application appropriately it can play a Mediator-like role.
EventBus 的一般用法是触发事件。使用“观察者”这个词更适合这一点。观察者模式使用事件或消息来通知有关正在观察（更改）的对象的感兴趣对象的更改。
Mediator 还尝试将这两个实现解耦，但在某种意义上比 Observer 更具体，它可以了解这两个对象/接口的所有信息，并充当使这两个对象/接口工作的粘合剂。
观察者并不声称了解内部结构，甚至界面。它所知道或关心的是当事件发生时，它需要通知感兴趣的对象。
中介者可能是特定于场景的设置，而观察者可能更通用。
EventBus 在应用程序范围内几乎总是一个单例，我肯定会将 EventBus 归类为使用观察者，因为在大多数情况下，它的真正目的是促进运行时内的各个模块/对象之间的全局消息传递。
The general usage of EventBus is to fire events. Use of the word Observer is better fit for that. Observer pattern uses events or messages to notify of a change to objects of interest about the object being observed(changed).
Mediator also tries to de-couple the two implementations but is more concrete than Observer in the sense, it can know all about the two objects/interfaces and works as a glue to make those two work.
Observer doesn't claim to know about the internals or even the interface. All it knows or cares about is when the event occurs, it needs to notify the objects who are interested.
Mediator could be a scenario specific setup whereas the Observer could be more generic.
EventBus being almost always a singleton within the scope of the application, I would definitely categorise EventBus as using Observer as its real intent in most cases is to facilitate messaging globally amongst the various modules/objects within your runtime.
我想说，典型的事件总线利用了这两种模式：
I'd say that a typical event bus utilises both of these patterns:
维基百科：Mediator 模式的本质是“定义一个对象来封装一组对象如何交互”，
EventBus 不这样做。
EventBus 也不是观察者模式，因为如果你有 N 个对象，并且想要在所有对象之间进行通信，那么如果你使用观察者模式，则需要 N*N 个观察者，但只有一个全局 EventBus 就足以完成相同的工作。
所以EventBus 就是EventBus 模式。
wikipedia: The essence of the Mediator Pattern is to "Define an object that encapsulates how a set of objects interact"
EventBus does not do this.
EventBus is also not observer pattern because if you have N objects and you want to communicate between all of them you need N*N observers if you use the observer pattern but only one global EventBus is enough to do the same job.
So EventBus is THE EventBus pattern.
由于前言说“一个 [...] 发布/订阅 API”，我会选择 Observer。
Since the foreword says "a [...] publish/subscribe API", I'd go for Observer.