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 the Facade pattern in this second piece. Now we will dive into the observer pattern.
Observer pattern
The Observer pattern is an easy-to-understand, and widely used messaging design where an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes. This promotes a loose coupling between related objects and allows for efficient communication between them.
Real case scenario
Consider a Customer and a Store. The customer wants a new iPhone model not yet available in the store. They could check daily, but most trips would be unnecessary. Alternatively, the store could spam all customers whenever a new product arrives, saving him them from pointless trips but annoying others. This creates a dilemma: either the customer wastes time or the store wastes resources.
The observer pattern solution
In the example above, the Customer is the observer while the Store is the subject. The Customer may want to receive updates on a specific category of products, or not, giving it the possibility of choosing what it wants to observe.
In that case, the the Store (i.e., the subject) knows who is interested in its updates (the Customer, or observer), and there can be many Customers. Various Customers can sign up for updates from the same Store, and all will receive notifications whenever a new product is added.
This communication can occur every time a new product is created, updated, or removed in the Store.
Even though the Store knows who its Customers are in the Observer pattern, it doesn't concern itself with or know what each Customer will do with the updates received. Each Customer has complete control over what to do with the updates they receive.
Another pattern that looks really similar to the observer is the Publisher/Subscriber pattern, that I will cover on the next post of the series.
Code example
If you are like me, you want to see the code, it makes it simpler to understand, so here's a simple JavaScript code example illustrating the Observer pattern:
// Define a class for the Provider
class Store {
constructor() {
this.observers = [];
}
// Add an observer to the list
add(observer) {
this.observers.push(observer);
}
// Notify all observers about new product
notify(product) {
this.observers.forEach(observer => observer.update(product));
}
}
// Define a class for the Observer
class Customer {
update(product) {
console.log(`New product added: ${product}`);
}
}
// Usage
const store = new Store();
const customer = new Customer();
store.add(customer); // Add a customer to the store's observers
store.notify('iPhone 15'); // Notify all observers about a new product
In the code above, the Observer pattern is exemplified through the creation of two classes, Store and Customer.
The Store class represents the provider (some people may call it the subject). It has an array observers that stores all the observers (Customer instances) that are interested in updates from the Store. It also has an add method to add a new observer and a notify method to notify all the observers about a new product.
While the Customer class represents the observer, it has an update method that do some action when it receives the update, in this case it logs on the console.
All set, let’s use it. So we create aStore and a Customer object. The Customer is added to the Store's observers using the add method.
Then, the Store notifies all its observers (in this case, just one Customer) about a new product ('iPhone 15') using the notify method. The customer.update() method is called, and it logs the new product to the console.
That’s it! Now you have one more design pattern on your skill arsenal. Stay tuned for more exploration into different design patterns in this series, and let me know in the comments what design pattern you would like to see next!
Top comments (13)
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!
Didn't know that, thanks for telling me, I'm gonna search more about it.
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
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
Thanks for this complement!
Looking forward to next Publisher/Subscriber pattern article
Thanks
Nice article. I'm currently learning Object Oriented Design, what resources did you use?
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).
Easily understandable explanations and examples. Please keep going!
Thanks!
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
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