The Observer Design Pattern
The Observer pattern defines a one-to-many dependency between a subject and multiple observers, allowing the observers to be notified of state changes in the subject.
Use the Observer pattern when a subject needs to notify multiple observers about state changes, or when you want to avoid tight coupling between the subject and its observers.
- TypeBehavioral
- Time ComplexityO(n) Linear Time – The time taken grows linearly with the size of the input. Examples include simple search algorithms.
- Efficiency6
-
Learning Effort
- Average5
- Conceptual5
- Debug and Maintain5
- Implementation4
- Prerequisites4
- Versatility6
Things you should know before you start
- Event Handling Understanding of event handling is beneficial, as the Observer pattern is often used to implement event systems.
Minimal Example
Implementing a weather station that notifies multiple displays when the weather data changes.
class WeatherStation implements Subject {
addObserver(observer: Observer): void { /* ... */ }
removeObserver(observer: Observer): void { /* ... */ }
notifyObservers(): void { /* ... */ }
}
const weatherStation = new WeatherStation();
const display1 = new WeatherDisplay();
const display2 = new AnotherDisplay();
weatherStation.addObserver(display1);
weatherStation.addObserver(display2);
weatherStation.notifyObservers();
What’s happening in thie example
In this example, the `WeatherStation` serves as the Subject, and `WeatherDisplay` and `AnotherDisplay` are Observers. The `clientCode` shows how to add observers to the subject and notify them when the weather changes.
How the Observer Works
The Observer pattern is commonly used to implement distributed event handling systems.
It helps maintain consistency between related objects without making classes tightly coupled.
Entities in the Observer Design Pattern
-
SubjectThe Subject maintains a list of observers and notifies them of state changes.
- Subject has a one-to-many notifies relationship with Observer
What to watch out for when using or considering this design pattern.
Avoid using the Observer pattern if you have only a few simple interactions between objects, or if you need to notify observers in a specific sequence, as the Observer pattern doesn’t guarantee a particular order of notification.
Design patterns often confused with the Observer Design Pattern
The following design patterns are often confused with the Observer
for various resons.
If you’re exploring solutions, have a look through this list and see if
one of these might be a better fit for your problem.
-
Mediator – The Mediator pattern defines an object that encapsulates how a set of objects interact.
The Mediator pattern is similar to the Observer in the following ways.
- Both are behavioral design patterns.
- Both deal with object communication.
- Observer is more decentralized, allowing multiple observers to listen to a subject, while Mediator centralizes communication.
- Observers are generally not aware of each other, whereas in Mediator, the mediator object knows all the colleagues.
-
Strategy – The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.
The Strategy pattern is similar to the Observer in the following ways.
- Both patterns aim to make the system more modular and extensible.
- Both are behavioral design patterns.
- Observer is about maintaining consistency between related objects, while Strategy is about changing the behavior of a single object.