Observations on the Observer Pattern

A quick overview of the Observer pattern, and then other related stuff

The observer pattern is one of the twenty-three classic software design patterns by the famous Gang of Four (GoF). It is a behavioural pattern that defines the communication between objects. According to GoF, the observer pattern is to

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Why is this useful? Suppose you own an e-commerce website and you host periodic sales. Customers could just keep checking your website until there is a sale (polling), or you could make it more convenient for your customers and allow them to register their interest by leaving their emails, so that your website can notify them with an email blast when a sale happens. Notice that such a scenario is event-driven, where the customers are observing for the sale event.

The observer pattern abstracts this idea with four participants as shown in the class diagram below. The ConcreteSubject corresponds to the website, and the ConcreteObserver corresponds to the customer.

UML class diagram for the Observer pattern

Let’s take a closer look at the participants:

• Subject is an abstract class that defines the methods to attach, detach and notify observers. The observers are stored in the observers list, and notify() simply calls o.update() for each observer o in observers.
• ConcreteSubject inherits from Subject and stores the state of the object. It calls notify() when the state changes.
• Observer is an interface that defines the update method, which is called by the Subject to notify it.
• ConcreteObserver implements Observer and defines the concrete update method.

Observers can attach themselves to the subject if they want to be notified of an event, and when the event is trigged, the subject will notify the observers by calling their update method, allowing them to be updated independently. By abstracting with the Subject abstract class and Observer interface, we can reduce coupling between the subject and observers since they do not need to know any information about each other. Such a design also follows the Dependency Inversion Principle (DIP), since both the (high-level) subject and (low-level) observers now depend on abstractions.

The observer pattern is a very common pattern in event-driven architecture and we shall take a look at some applications.

Model-View-Controller (MVC) Architecture

The MVC architecture is a common software architecture design pattern in developing web and mobile applications. It decouples the input (Controller), output (View) and processing (Model) parts of the application, and defines the interactions between them as shown in the diagram below. In particular, step 5 implements the observer pattern in its change propagation mechanism, where the Model is a ConcreteSubject and the View is a ConcreteObserver. The View is attached to the Model so that it can be notified of changes in the application state, which is handled by the Model. It can then pull the updated state and refresh its display to the user.

MVC architecture

Data Binding

Data binding allows two information sources to automatically synchronise their data, such that changes in one source would also update the other. One application of this is in the MVVM architecture, which allows UI elements in the display to automatically synchronise with the application state. Data binding can be implemented using the observer pattern, with both information sources as both the ConcreteSubject and ConcreteObserver and attached to each other. As a result, changes in state to one source would trigger an event that notifies the other of the change.

Webhooks

Webhooks (also commonly known as reverse APIs) are “user-defined HTTP callbacks” that are triggered by events. Clients can register a URL to their applications with the webhook and when the event is triggered, a HTTP request is made to that URL to notify them. One application of this is in developing Telegram Bots, where we can use webhooks to request for incoming messages instead of continuously polling for messages. If we observe, we can see that the observer pattern is implemented, with the webhook source site as the ConcreteSubject and the clients as the ConcreteObservers.

Conclusion

The observer pattern is so common that you might have unknowingly used it before. This post serves as an introduction to the formal design pattern along with some applications of it. As design patterns are designed to solve common software design problems, it would be useful to be familiar with some (if not all) of them for your next software project.