Mediator pattern vs Publish/Subscribe

Question

Can someone point out the main differences between the two?

It seems that, at least conceptually, the two are very closely related. If I were to hazard a guess, I would say that the publish/subscribe method is a subset of the mediator pattern (since the mediator need not necessarily be used in the publish/subscribe manner, but the latter seems to require a sort of mediator object). Is that anywhere near close to it?

Answer 1

How I would describe the difference is that in mediator you probably care if the end application receives the message. So you use this to guarantee who is receiving the message. Whereas with pub/sub you just publish your message. If there are any subscribers they will get it but you don't care.

Answer 2

According to this page, the publish-subscribe model is an implementation of the mediator pattern.

Edit

I should note that the design patterns are called "patterns" precisely because there are going to be differences among every implementation. They aren't so much a set of decreed, canonical forms as they are a collection of observations on how people already write software. So there really isn't any way for a design to "strictly" adhere to a design pattern.

Answer 3

The implementation could be the same, but logically they are different (The difference is simple, but it is hard to see). I'll explain it in a simple way below.

Pratically, in the implementation of the Publish/Subscribe pattern you will have at least an object with the methods "publish" and "subscribe". But you can have also more of them, so the communication between components is not centralized by definition.

In the implementation of the Mediator pattern you will have JUST ONE object with methods "publish" and "subscribe". So the communication is "centralized" by definition.

Answer 4

In the GoF book, publish/subscribe is known as the Observer Pattern. The Mediator Pattern can be implemented using the Observer Pattern; but that is not the only way to implement a Mediator. The book describes this on page 278.

Colleague-Mediator communication. Colleagues have to communicate with their mediator when an event of interest occurs. One approach is to implement the Mediator as an Observer using the Observer pattern. Colleague classes act as Subjects, sending notifications to the mediator whenever they change state. The mediator responds by propagating the effects of the change to other colleagues.

Another approach defines a specialized notification interface in Mediator that lets colleagues be more direct in their communication... When communicating with the mediator, a colleague passes itself as an argument, allowing the mediator to identify the sender.

Note that even when implementing a Mediator as an Observer, it is described as communicating only among its colleagues whereas an Observer in general would likely communicate with other objects as well.

Answer 5

I think one main point of difference is the context of the problem.

Although a problem could be solved with either pattern, the real concerns are:

1: "How much change to bring about by the events are dependent on the general context ?"

2: "How frequently are the listeners expected to change?"

The classical case for the mediator pattern best illustrates this where you have a complex UI with a lot of components and the updation on each has a complex inter-dependency on the state of other similar components.

Although you can solve this problem with the pub/sub pattern; wherein your components listen for events and contain the logic necessary to update, the context object (along with the event) carry all necessary information. Here the advantage is obviously the proper encapsulation of logic pertaining to a component within itself. The downside is that if such components are supposed to change often then you have to replicate this logic fully in each new component you bring in.

To use a mediator is to introduce another layer and further abstract from the components. These components become thinner as they only deal with representation (UI look and feel) thus, become very easy to change. The only problem I have with this approach is that the updation logic now seems to spill to other components and any updation of the system would require one to change the component and the mediator if the component behavior is also to change.

That to me is the major dilemma/trade-off we need to solve. Please correct me if I haven't got anything correctly.