The publisher/subscriber

Events are yet another solution to communicate when asynchronous callbacks finish execution. An object can become emitter and publish events that other objects can listen to. This is one of the finest examples of the observer pattern.

The nature of this method is similar to "event listener", but much better than the latter because we can view the "message center" in order to find out how much signal is present and the number of subscribers for each signal, which runs the monitoring program.

A brief account of the observer pattern

The observer provides very loose coupling between objects. This provides the ability to broadcast changes to those who are listening to it. This broadcast may be for the single observer or a group of observers who are waiting to listen. The subject maintains a list of observers to whom it has to broadcast the updates. The subject also provides an interface for objects to register themselves. If they are not in the list, the subject doesn't care who or what is listening to it. This is the way how the subject is decoupled from the observers, allowing easy replacement of one observer for another observer or even one subject, as long as it maintains the same series of events.

A formal definition of observer

The following is the definition of observer:

The source of this definition is page 20 of Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional.

The push and pull model

When you create a subject/observer relationship, you would want to send information to the subject; sometimes, this information can be brief, or sometimes, it can be additional information. This can also happen that your observer sends a little chunk of information, and in return, your subject queries more information in response.

When you're sending a lot of information, it's referred to as the push model, and when the observers query for more information, it's referred to as the pull model.

The source of this definition is page 320, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional.

The advent of observer/push-pub

This observer/push-pub pattern provides a way of thinking on how to maintain relationship between different parts of an application. This also gives us an idea of what part of our application should be replaced with observers and subjects in order to achieve maximum performance and maintainability. Here are some points to bear in mind when using this pattern in JavaScript in particular, and for other languages in general:

• Using this pattern, it can break down an application into smaller, more loosely coupled blocks to improve code management and potential for reuse
• The observer pattern is best when there is a need to maintain consistency between related objects, without making classes tightly coupled
• Due to the dynamic relationship that exists between observers and subjects, it provides great flexibility, which may not be as easy to implement when disparate parts of our application are tightly coupled

The drawbacks of observer/push-pub

Since every pattern has its own price, it is the same with this pattern. The most common one is due to its loosely coupled nature, it's sometimes hard to maintain the states of objects and track the path of information flow, resulting in getting irrelevant information to subjects by those who have not subscribed for this information.

The more common drawbacks are as follows:

• By decoupling publishers from subscribers, it can sometimes become difficult to obtain guarantees that particular parts of our application are functioning as we may expect
• Another drawback of this pattern is that subscribers are unaware of the existence of each other and are blind to the cost of switching between publishers
• Due to the dynamic relationship between subscribers and publishers, the update dependency can be difficult to track