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 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 simply by solving everyday tasks, and he may not even be aware of their existence. For example, such patterns as a facade, a factory or an adapter can be used without even studying them, since they are quite elementary and are a logical conclusion in 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 final 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 the knowledge of observer and pub-sub patterns, since knowledge and understanding of these patterns makes life much easier for developers.
Observer and Pub-sub refer to behavioral patterns (interaction patterns), i.e. they are used when it is necessary to organize interaction between various objects of the system
An 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 schematic diagram of the interaction looks like this:
Subject - implements the methods: observe, detach, notify, get, set.
Observer - implements the update method.
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 the objects, i.e. The subject knows about all its observers and manually notifies them about changes taking place in itself, calling the update method on each observer. The connection is established by the method of observe, broken by the method of detach.
Subject stores its state inside itself and all actions with its state must be performed using get / set methods to call the notify method when state changes. A similar scheme is implemented in EmberJs.
Observer can be represented as a pretty good picture (borrowed here ):
An example implementation can be found on the Addy Osmani website.
Pub-sub pattern is one of the variations of the Observer pattern. Based on the name in the pattern, there are two components Publisher (publisher) and Subscriber (subscriber). Unlike Observer, communication between objects is carried out via the Event Channel (event bus) communication channel.
Publisher throws its events in the Event Channel, and Subscriber subscribes to the desired event and listens to it on the bus, which ensures that there is no direct connection between the subscriber and the publisher.
Schematically, Pub-sub and difference from Observer, can be represented as follows:
Thus it is possible to identify the main distinctive features between the Pub-sub and Observer:
One of the most well-known implementations of the pub-sub pattern is Backbone, AmplifyJs, and others. The DOM, to some extent, also implements the pub-sub model.
On the basis of the pub-sub, the work of 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 both an event listener and the publisher of another event, thus facilitating communication between system objects.
If we draw an analogy, then Mediator is a city PBX, which receives incoming and outgoing calls from subscribers, and they strictly reach the desired subscriber. But as we know, the telephone network has a drawback - for the new year it can be overloaded with a huge number of calls and stop delivering the call to subscribers. The same can happen with Mediator, when he does not cope with the flow of events.
Mediator is especially useful in cases where there are multiple unidirectional or bidirectional connections between the various components of the system. The pattern is especially useful when the application has nested components of the system (for example, child composition elements) so that it is not necessary to forward callbacks using the event ascent model from the inside to the outside. It is enough to provide Mediator to an internal component that publishes 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 .
When and where each pattern should be applied is everyone’s business, but before applying it, one should understand their differences and peculiarities. For example, the Observer pattern is a direct connection between objects and signals the observer about a change in their state. In my opinion, this pattern is very well suited for the development of various forms with a variety of input fields when it is necessary to respond to changes in the field values of the form (binding).
The Mediator pattern, as already noted, is especially useful when it is necessary to establish unidirectional or bidirectional communication between separate 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 dependent on this event.
')
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 simply by solving everyday tasks, and he may not even be aware of their existence. For example, such patterns as a facade, a factory or an adapter can be used without even studying them, since they are quite elementary and are a logical conclusion in 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 final 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 the knowledge of observer and pub-sub patterns, since knowledge and understanding of these patterns makes life much easier for developers.
Observer and Pub-sub refer to behavioral patterns (interaction patterns), i.e. they are used when it is necessary to organize interaction between various objects of the system
Observer
An 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 schematic diagram of the interaction looks like this:
Subject - implements the methods: observe, detach, notify, get, set.
Observer - implements the update method.
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 the objects, i.e. The subject knows about all its observers and manually notifies them about changes taking place in itself, calling the update method on each observer. The connection is established by the method of observe, broken by the method of detach.
Subject stores its state inside itself and all actions with its state must be performed using get / set methods to call the notify method when state changes. A similar scheme is implemented in EmberJs.
Observer can be represented as a pretty good picture (borrowed here ):
An example 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 in the pattern, there are two components Publisher (publisher) and Subscriber (subscriber). Unlike Observer, communication between objects is carried out via the Event Channel (event bus) communication channel.
Publisher throws its events in the Event Channel, and Subscriber subscribes to the desired event and listens to it on the bus, which ensures that there is no direct connection between the subscriber and the publisher.
Schematically, Pub-sub and difference from Observer, can be represented as follows:
Thus it is possible to identify the main distinctive features between the Pub-sub and Observer:
- no direct connection between objects
- objects signal each other by events, not by object states
- the ability to subscribe to different events on the same object with different handlers
One of the most well-known implementations of the pub-sub pattern is Backbone, AmplifyJs, and others. The DOM, to some extent, also implements the pub-sub model.
Mediator
On the basis of the pub-sub, the work of 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 both an event listener and the publisher of another event, thus facilitating communication between system objects.
If we draw an analogy, then Mediator is a city PBX, which receives incoming and outgoing calls from subscribers, and they strictly reach the desired subscriber. But as we know, the telephone network has a drawback - for the new year it can be overloaded with a huge number of calls and stop delivering the call to subscribers. The same can happen with Mediator, when he does not cope with the flow of events.
Mediator is especially useful in cases where there are multiple unidirectional or bidirectional connections between the various components of the system. The pattern is especially useful when the application has nested components of the system (for example, child composition elements) so that it is not necessary to forward callbacks using the event ascent model from the inside to the outside. It is enough to provide Mediator to an internal component that publishes 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 each pattern should be applied is everyone’s business, but before applying it, one should understand their differences and peculiarities. For example, the Observer pattern is a direct connection between objects and signals the observer about a change in their state. In my opinion, this pattern is very well suited for the development of various forms with a variety of input fields when it is necessary to respond to changes in the field values of the form (binding).
The Mediator pattern, as already noted, is especially useful when it is necessary to establish unidirectional or bidirectional communication between separate 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 dependent on this event.
Read
- Learning Javascript Design Patters, Addy Osmani
- Programming in Eddie Burris
- Code examples
Source: https://habr.com/ru/post/270339/
All Articles