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:
1// Define a class for the Provider2class Store {3constructor() {4this.observers = [];5}67// Add an observer to the list8add(observer) {9this.observers.push(observer);10}1112// Notify all observers about new product13notify(product) {14this.observers.forEach(observer => observer.update(product));15}16}1718// Define a class for the Observer19class Customer {20update(product) {21console.log('New product added:' + product);22}23}2425// Usage26const store = new Store();27const customer = new Customer();28store.add(customer); // Add a customer to the store's observers29store.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 a Store
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!