DEV Community

Cover image for Design Pattern #3 - Observer Pattern

Design Pattern #3 - Observer Pattern

Vitor Norton on June 20, 2024

Continuing our quest into trending design patterns for front-end developers, we follow up our first article on the Singleton pattern with a look at...
Collapse
 
mdledoux profile image
Martin Ledoux

Worth mentioning that the RxJS library is built on this pattern, introducing a new type called an Observable, as a multicast alternative to the Promise (though there are similarities too).
It scares away many developers, but powerful when grasped!

Collapse
 
vtnorton profile image
Vitor Norton

Didn't know that, thanks for telling me, I'm gonna search more about it.

Collapse
 
paul_levitt_2eb5cf3fbe227 profile image
Paul Levitt

Great set of articles, especially loving the simple yet concise examples.

However; I’d be remiss if I didn’t point out a couple of misconceptions in the observer and pub-sub articles.

In the observer pattern a subject “streams” a copy of each data value to each subscribed observer using unicast distribution (ie one-to-one). Observers receive a “stream” of values sequentially and synchronously, one at a time, guaranteeing order and immutability.

On the other hand pub/sub is multicast, whereby the original data value is sent to each subscriber - ie not cloned. There’s no guarantee of ordering.

Therefore;

  • Observables are great for any series based or realtime requirements, like tracking changes for an undo/redo feature

  • Pub/Sub architectures are great for event driven requirements, especially distributed, like performing an action on click of a button, or receiving chat messages or system notifications via a socket

Collapse
 
paul_levitt_2eb5cf3fbe227 profile image
Paul Levitt

Also, do checkout RxJS - it has a steep learning curve but well worth the effort, it’s an incredibly powerful toolset and surprising how many solutions RxJS observables can be applied to

Collapse
 
vtnorton profile image
Vitor Norton

Thanks for this complement!

Collapse
 
abranasays profile image
Abdul Basit Rana

Looking forward to next Publisher/Subscriber pattern article

Collapse
 
vtnorton profile image
Vitor Norton

Thanks

Collapse
 
clemo97 profile image
Clemo97

Nice article. I'm currently learning Object Oriented Design, what resources did you use?

Collapse
 
vtnorton profile image
Vitor Norton

To be honest, I came with a strong background with C#, that is a highly orientend object language, so many of the concepts I know came from that. For this article I had experiencies with the IObservableCollection from C#, and in other projects using JavaScript with React or Angular (that also uses a lot of observer).

Collapse
 
dennisnvluken profile image
Dennis Luken

Easily understandable explanations and examples. Please keep going!

Collapse
 
vtnorton profile image
Vitor Norton

Thanks!

Collapse
 
chema profile image
José María CL

Hey! Really easy to understand and brief enought to caugh all my attention :) thank you so much!

In my case, I use to implement this pattern for messaging systems, microservices communication, and notifications mechanisms. It's useful to implement the functionallity, or just to decouple the logic

Collapse
 
d4r1ing profile image
Nguyễn Thế Cuân

Nice article, but i think we can improve a little bit by adding the unsubcription when the customer doesn't want to notify about the store changes anymore. I used this pattern a lot in many real-world scenarios, the Observer act as a store, component subcribes it to receive data and clean up the subscription when unmounts