Observer vs Pub-Sub

Observer and Pub-sub are probably the most famous interaction patterns in the world of interface development and JavaScript. But despite their fame, some developers consider these patterns to be the same, which helped to write this article.





There are quite a few design patterns, for example, a facade, a factory, an adapter, a bridge, etc. It is believed that each developer applies design patterns to simply solve everyday tasks, and perhaps he does not even know about their existence. For example, such patterns as a facade, a factory or an adapter can be applied without even studying them, because they are quite elementary and are a logical conclusion when solving any problems. In my opinion, the best pattern is the presence of the brain in the head and the desire to make a quality product, because the patterns themselves are not the ultimate solution, but provide only a general solution for typical tasks.

But in the world of interfaces and asynchronous JavaScript it is not possible to live without knowledge of observer and pub-sub patterns, since knowing and understanding these patterns makes the life of the developer much easier.

Observer and Pub-sub relate to behavioral patterns (interaction patterns), i.e. apply when it is required to organize interaction between various objects of the system.

Observer

Observer is nothing more than a one-to-many relationship. In a simplified form, this pattern consists of an object of observation (subject) and observers (observers).

The basic scheme of interaction looks like this:

Subject - implements the methods: observe, detach, notify, get, set.

Observer - implements the update method.

The subject also contains links to all observers who listen to it, and observer, in turn, contains a link to the subject to which it is subscribed.

Thus, in this pattern there is a direct connection between objects, i.e. subject knows about all its observers and manually notifies them of changes occurring in itself, calling the update method for each observer. The connection is established by the observe method, broken by the detach method.

Subject stores its state inside itself and all actions with its state must be performed using get / set methods, so that when the state changes, the notify method should be called. A similar scheme is implemented in EmberJs.

Observer can be represented as a pretty good picture (borrowed here ):

An approximate implementation can be found on the Addy Osmani website .

Pub sub

Pub-sub pattern is one of the variations of the Observer pattern. Based on the name, two components Publisher (publisher) and Subscriber (subscriber) are distinguished in the pattern. Unlike Observer, communication between objects is carried out through the Event Channel communication channel (event bus).

Publisher throws its events in the Event Channel, and Subscriber subscribes to the desired event and listens on the bus, which ensures that there is no direct connection between the subscriber and the publisher.

Schematic Pub-sub and the difference from Observer can be represented as follows:


Thus, we can distinguish the main distinguishing features between Pub-sub and Observer:

1. lack of direct communication between objects
2. objects signal each other with events, not with the states of the object
3. the ability to subscribe to various events on the same object with different handlers

One of the most well-known implementations of the pub-sub pattern is Backbone, AmplifyJs, etc. DOM, to some extent also implements the pub-sub model.

Mediator

Based on the pub-sub, the Mediator pattern is built, which allows you to establish communication between the various components of the system. Mediator is a global object in the system, which all components of the system are aware of, while the component can act as a listener of an event or as a publisher of another event, thus establishing communication between the objects of the system.

If we draw an analogy, then Mediator is a city telephone exchange, which receives incoming and outgoing calls from subscribers, and they reach strictly to the desired subscriber. But as we know, the telephone network has a drawback - for the new year, it may be overloaded with a huge number of calls and stop delivering calls to subscribers. The same thing can happen with Mediator, when it does not cope with the flow of events.

Mediator is especially useful when there are multiple unidirectional or bidirectional connections between different components of the system. This pattern is especially useful when the application has embedded system components (for example, child compositional elements), so that there is no need to forward callbacks using the event popup model from the inside out. It is enough to provide Mediator to the internal component that will publish its event, and other components will learn about this event.

The Mediator pattern is quite successfully implemented in Backbone - the global Backbone object itself can be used as a Mediator, or inherited from Backbone.Events .

What? Where? When?

When and where to apply each pattern is everyone’s business, but before you apply it, you should understand their differences and features. For example, an Observer pattern is a direct connection between objects and signals the observer about a change in its state. In my opinion, this pattern is very well suited for the development of various forms with many input fields, when it is necessary to respond to changes in the values ​​of form fields (binding).

The Mediator pattern, as already noted, is especially useful when it is necessary to establish unidirectional or bidirectional communication between disparate components of the system, for example, in complex interfaces with many composite elements, when it is necessary to forward an event from a nested view to the top in order to display any information or perform an action depending on this event.

Read

• Learning Javascript Design Patters, Addy Osmani
• Programming in the large with Design Patterns, Eddie Burris
• Code examples