17

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?

jaco0646
  • 15,303
  • 7
  • 59
  • 83
Stefan
  • 14,826
  • 17
  • 80
  • 143

5 Answers5

19

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.

Cliff L. Biffle
  • 538
  • 5
  • 9
12

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.

skipy
  • 4,032
  • 2
  • 23
  • 19
7

I'd say that a typical event bus utilises both of these patterns:

  • event bus essentially encapsulates how other objects communicate, so it is a mediator
  • objects that register as event handlers/listeners are observers (and the subjects of their observations are event types and/or objects that produce these events, not the bus itself), so as wikipedia says observer pattern "is mainly used to implement distributed event handling systems" (emphasis mine), but an event bus is not an observer per se.
morgwai
  • 2,513
  • 4
  • 25
  • 31
  • 4
    Just stumbled upon this and wanted to upvote, and expand the answer with a comment - in fact, going back to the Go4 book, they say (under Implementation) that the Mediator object in the Mediator pattern can be implemented as an Observer. So patterns have a way of mixing together. As always, the distinction is in the purpose/intent: Mediator is used to treat the interaction logic as a *separate concern*, and just needs to define some type of communication interface for the Colleague objects. Observer's purpose is support for publish-subscribe interaction (events). – Filip Milovanović Mar 16 '18 at 10:23
5

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.

jhegedus
  • 20,244
  • 16
  • 99
  • 167
  • Not sure I completely follow the line about needing N˟N observers. If N objects all need to communicate with each other, then every object is both a publisher and a subscriber. So you have N subscribers (observers) each with N subscriptions. A subscription is merely a method call that registers one object with another; it does not create a new observer, hence the total number of observers is still N. You may need N˟N method calls, if producers require one subscription at a time; but in a modern application all of that initial wiring would likely be performed by a DI container anyway. – jaco0646 Jan 17 '19 at 17:02
  • 2
    Event Bus is not a design pattern but the mix of 3 design patterns: Singleton, Observer and Mediator. It's a Singleton because you only want 1 instance of the bus. It's an Observer because you have publishers-subscribers It's a Mediator because you have an object that encapsulates how a set o objects interact (the bus). So an event bus is not a pattern but an specific implementation of 3 patterns. – Jorge Rivera May 27 '19 at 20:07
  • This should be the correct answer. – Arialdo Martini Jan 03 '22 at 08:50
0

Since the foreword says "a [...] publish/subscribe API", I'd go for Observer.

Simone
  • 11,655
  • 1
  • 30
  • 43
  • seems alright, but I also noticed, that observer and mediator are very similar patterns. – Stefan May 12 '11 at 08:25
  • 1
    Yes, they are. The difference is that in the Observer the subject knows the list of observers and manages it. Nonetheless, Wikipedia[http://en.wikipedia.org/wiki/Observer_pattern] suggests that publish/subscribe is a pattern in itself, so I guess the matter is debatable. – Simone May 12 '11 at 08:34