Reseller / Publishing / Subscription Scheme

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 am at risk of speculation, I would say that the publish / subscribe method is a subset of the mediator template (since the mediator does not have to be used in publishing / subscribing, but the latter seems to require some kind of mediator object). Is it somewhere near him?

Answer 1

As I would describe the difference in the fact that in the mediator you will probably be wondering if the final application will receive a message. This way you use this to ensure who receives the message. If in pub / sub you just post your post. If there are any subscribers, they will receive it, but you do not care.

Answer 2

According to this page , the publication-subscription model is an implementation of the mediator template.

Edit

It should be noted that design patterns are called “patterns” precisely because there will be differences between each implementation. This is not so much a set of declared canonical forms as a collection of observations about how people already write software. Therefore, there is no way for a design to adhere strictly to a design pattern.

Answer 3

The implementation may be the same, but logically they are different (the difference is simple, but hard to see). I will explain this in a simple way below.

As a rule, when implementing a publication / subscription template, you will have at least an object with the methods "publish" and "subscribe". But you can also have more of them, so the connection between the components is by definition not centralized.

In the implementation of the broker template, you will have a JUST ONE object with the methods "publish" and "subscribe". Thus, a message is “centralized” by definition.

Answer 4

I believe that one of the main differences is the context of the problem.

Despite the fact that the problem can be solved using any template, the real problems are:

1: "How many changes caused by events depend on the general context?"

2: "How often are listeners expected to change?"

The classic case for the pick pattern best illustrates this when you have a complex user interface with many components, and updating each of them has a complex relationship with the state of other similar components.

Although you can solve this problem with the pub / sub pattern; in which your components listen for events and contain the logic necessary for updating, the context object (together with the event) carries all the necessary information. Here the advantage, obviously, is the correct encapsulation of the logic related to the component within itself. The downside is that if such components need to change frequently, then you need to completely replicate this logic in every new component that you introduce.

To use the pick, you need to enter another layer and get an additional abstraction from the components. These components become thinner as they deal only with the presentation (the appearance of the user interface), so they are very easy to change. The only problem I encounter with this approach is that the update logic now seems to extend to other components, and for any system upgrade, you will need to change the component and the intermediary if the behavior of the component also changes.

This is for me the main dilemma / compromise that we need to solve. Please correct me if I fail.