Pub/Sub vs Observer, which one to use?

Pub/Sub (Publish and Subscribe) and Observer, both are design patterns and they solve quite a few problems when it comes to communication among components or different parts of the application.

This blog will discuss the theoretical and the observed differences of both patterns.

Differences Between The Observer And Publish/Subscribe Pattern

Some might say both patterns are same and its correct in a certain way because both patterns deliver the same result (sort of). However, these patterns vary in the implementation, usage and dependency.

What does it mean?

Observer Pattern:

Requires the implementation of:

• Subject: maintains a list of observers, facilitates adding or removing observers.
• Observer: provides an update interface for objects that need to be notified of a Subject’s changes of state (kind of like an abstract class or an interface).
• ConcreteSubject: broadcasts notifications to observers on changes of state, stores the state of ConcreteObservers.
• ConcreteObserver: stores a reference to the ConcreteSubject, implements an update interface for the Observer to ensure state is consistent with the Subject’s.

Gotchas:

• Observer pattern creates dependency among Subjects and Observers.
• Subject has to call the update method of other objects in order to notify observers, this results in tight coupling of objects.

To understand the code logic behind Observer pattern, check out this article later, but keep reading this blog to get familiar with the differences.

Keep Reading

Pub/Sub Pattern:

The Pub/Sub pattern works a bit different as it allows any subscriber to subscribe to a topic/event and get notified when someone publishes (fires) that topic/event.

Its more like a communication/message channel between objects (the subscribers) wishing to receive notifications and the object (the publisher) broadcasting the topic.

Advantages:

• Publisher has no impact on Subscribers and Subscribers have no relation with Publisher except their interest in topic and the data with that topic.
• No dependencies between the subscriber and the publisher.
• Pub/Sub promotes loose coupling by not having to call any internal methods of Subscribers.

Awesome!!

Pub/Sub Example:

I have created a simple Pub/Sub library in JavaScript called yaps.js implementing basic Pub/Sub features.

shahnawaz/yaps.js

Quick and Easy

• via npm: npm i yaps.js -s
• (or) use minified file directly from cdn: https://cdn.jsdelivr.net/npm/yaps.js/yaps.min.js

Interfaces

• Subscribe — Returns: unique identifier/token of handler

let handlerIdentifier = yaps.subscribe(topic, handlerFunc);

• Unsubscribe — Returns: yaps object

yaps.unsubscribe(handlerIdentifier);

• Publish — Returns: yaps object

yaps.publish(topic, argument1, argument2, ...);

To learn more about the usage of yaps.js, check out these examples.

So which one to use?

Both patterns are great but Pub/Sub has more advantages in terms of loose coupling, dependency free and usage.

• If your system requires application level (or platform level) events/messages communication while keeping the components independent, select Pub/Sub pattern.
• If your components are tightly linked with each other and there is no need for application level events except within few components, then Observer pattern could be an option.