1

I am very unfamiliar with the Mediator Pattern in practice, but it seems that the core is decoupling events from handlers ("Colleagues"). The benefit being "lose coupling" in the sense that you can change code in a "colleague" without breaking the caller and vice-versa.

In that sense, this seems like what an in-memory queue would solve, minus dead-letter queue handling and other more advanced queue features.

Am I thinking about this wrong, does the mediator pattern have any advantage over a queue other than potentially simplicity?

P.S. I am also coming at this from a perspective of NEVER seeing a use-case for the mediator pattern.

2 Answers 2

6
  1. No, the mediator pattern does not solve the same problem as a queue.
  2. No, a queue doesn't solve the same problem as a mediator.
  3. Yes, a distributed queue happens to also provide something that mediators do.

Let's tackle these in order.

1
A queue inherently contain the ability to defer execution of the queued items, i.e. the act of putting it on the queue is not inherently tied to the act of processing items off the queue.

A mediator is a connected process, whereby the act of calling the mediator also entails the act of the handler handling the request (and possibly sending a return value).

A mediator can also implement a queue, at which point it obviously sports queue-like behavior, but the mediator part of that solution isn't the part that's working like a queue.

2
Mediators solve the issue of disconnecting the sender of the request from who handles the request; as opposed to queues which disconnect when the handler handles the request.

A mediator can also implement a queue, at which point it obviously sports queue-like behavior, but the mediator part of that solution isn't the part that's working like a queue.

3
If you're specifically talking about a distributed queue, such as a service bus or an event hub, this means that the handler(s) connect to said queue via the network. This means that the queue itself doesn't really know who its handlers are, and therefore there is a disconnect between the queue and who its handler(s) is (are); which is not unlike what a mediator provides for you.

However, generally speaking a mediator pattern refers to an in-runtime disconnect between sender and handler, rather than a network-based one (where we just refer to it as pubsub); so it's arguable whether you consider the behavior of a distributed queue to be "mediator-like".

I am also coming at this from a perspective of NEVER seeing a use-case for the mediator pattern.

Imagine how much harder it would be to get an answer to your question if StackExchange forced you to send your question to specific people. You would have to track or look up who knows what in order to know who could answer your question for you.

It would be a lot easier if you could post your message to a central location where everyone can observe it, and people can decide for themselves whether they can answer that question or not. People who can't answer it don't have to be involved, and people who do can decide for themselves whether they can and want to contribute or not.

That's essentially the mediator pattern. The sender of the request does not get to decide (nor does it need to figure out) who can respond to its request. Instead, there is a middle man (literally a mediator) who takes in all manner of requests and distributes it to all manner of handlers.

4
  • 2
    Tbh, your SE analogy reads more like your description of a distributed queue than your description of mediator, esp since one major point is the synchronous/in-runtime nature.
    – sfiss
    Commented Feb 16 at 6:00
  • A better example of the Mediator pattern at work would be a color-picker widget, with different ways of selecting a color (RGB inputs, HSV inputs, click on a displayed gradient, etc.) and when you change one, the others immediately update to reflect the same color. Commented Feb 16 at 7:44
  • @sfiss: You can definitely make an argument here based on the chronological sorting of the homepage, but the homepage design isn't what I was focusing on, rather that posting a question is done without any idea of who might be providing an answer.
    – Flater
    Commented Feb 19 at 22:35
  • @Flater: yes, but an asker will also have no idea when an answer will be provided (if ever). (Still +1 from me here).
    – Doc Brown
    Commented Feb 20 at 15:06
2

Yes in practice you can use an in memory pub sub queue for the same purpose as a mediator.

Mediator solves:

  • Object A can be instanced without setting a relationship to all the other objects which might fire events object A wants to react to.

Queue solves:

  • Logic can be run without waiting for a return.

"Fan out" or "pub sub" queues are essentially a queue plus a mediator plus more queues

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.