Observer Pattern

Analogy categoryAnalogies

Introduction

The Observer pattern defines a one-to-many dependency between objects so that when one object (the subject) changes state, all its dependents (observers) are notified and updated automatically. It is one of the most widely used behavioral patterns because it decouples the object that generates events from the objects that react to them.

🏏

Cricket analogy: When the third umpire (subject) overturns a decision, every dependent party — the scoreboard, the broadcast commentary, and the players on the field (observers) — is automatically updated and reacts, without the umpire personally walking to inform each one.

Explanation

A subject exposes methods to subscribe (attach) and unsubscribe (detach) observers, and it keeps an internal collection of currently registered observers. Whenever the subject's state changes, it iterates over the collection and calls a notify method on each observer, typically passing the new state or an event object. Observers implement a common interface, usually a single 'update' method, so the subject can treat them polymorphically without knowing their concrete types. This is the same mechanism behind GUI event listeners, DOM 'addEventListener' calls, and publish-subscribe messaging systems: publishers do not need direct knowledge of subscribers' implementations, only that they conform to a callback contract.

🏏

Cricket analogy: The stadium's official scoreboard system lets broadcasters subscribe (attach) and unsubscribe (detach) their feeds, and whenever the score changes it loops through every registered feed calling a common 'update' method, the same way a DOM 'addEventListener' notifies subscribers without knowing their internals.

Example

python

from abc import ABC, abstractmethod


class Observer(ABC):
    @abstractmethod
    def update(self, temperature: float) -> None:
        ...


class WeatherStation:
    """Subject: maintains observers and notifies them of state changes."""

    def __init__(self) -> None:
        self._observers: list[Observer] = []
        self._temperature: float = 0.0

    def subscribe(self, observer: Observer) -> None:
        if observer not in self._observers:
            self._observers.append(observer)

    def unsubscribe(self, observer: Observer) -> None:
        if observer in self._observers:
            self._observers.remove(observer)

    def _notify(self) -> None:
        for observer in self._observers:
            observer.update(self._temperature)

    def set_temperature(self, value: float) -> None:
        self._temperature = value
        self._notify()


class PhoneDisplay(Observer):
    def update(self, temperature: float) -> None:
        print(f"Phone display: {temperature}C")


class DashboardDisplay(Observer):
    def update(self, temperature: float) -> None:
        print(f"Dashboard display: {temperature}C")


station = WeatherStation()
phone = PhoneDisplay()
dashboard = DashboardDisplay()

station.subscribe(phone)
station.subscribe(dashboard)
station.set_temperature(23.5)  # both observers are notified

station.unsubscribe(phone)
station.set_temperature(25.0)  # only dashboard is notified

Analysis

The Observer pattern is classified as behavioral because it is concerned with how objects communicate and delegate responsibility for reacting to events, not with how objects are created or composed. Its main benefit is loose coupling: the subject only depends on the abstract Observer interface, so new observer types can be added without modifying the subject. The trade-off is that notification order and update frequency can become hard to reason about in large systems, and careless implementations can create memory leaks if observers are never unsubscribed. Real-world examples include DOM event listeners, GUI toolkit event handling, reactive programming libraries, and message brokers implementing publish-subscribe.

🏏

Cricket analogy: Observer is behavioral, not about how the scoreboard hardware is built, but about how the umpire communicates events to it; the loose coupling means a new observer like a fan's mobile app can subscribe without changing the umpire's code, though if an app never unsubscribes after the match, it can keep listening and drain resources needlessly.

Key Takeaways

Subject maintains a collection of observers and exposes subscribe/unsubscribe operations.
Notification pushes state changes to all registered observers via a common update interface.
Decouples the event source from event handlers, enabling independent extension of both sides.
Forms the basis of GUI event listeners and publish-subscribe messaging systems.
Failing to unsubscribe observers can lead to memory leaks (the 'lapsed listener' problem).

Practice what you learned

1. What is the primary purpose of the Observer pattern?

2. Which category of design pattern does Observer belong to?

3. In a typical Observer implementation, what interface do all observers share?

4. What is a common real-world example of the Observer pattern?

5. What risk arises if observers are never unsubscribed from a long-lived subject?

Was this page helpful?

Strategy and Command Patterns

Related Study Notes in Software Engineering

Browse all study notes

Software Engineering

Microservices Study Notes

Software Architecture · 30 topics

Software Engineering

Testing & TDD Study Notes

Software Testing · 30 topics

Software Engineering

Design Patterns Study Notes

Software Design · 30 topics

Software Engineering

Git & Version Control Study Notes

Bash · 40 topics

Software Engineering

System Design Study Notes

Architecture · 40 topics

Topics covered

#Python#SoftwareEngineeringStudyNotes#SoftwareEngineering#ObserverPattern#Observer#Pattern#Explanation#Example#StudyNotes#SkillVeris

Introduction

Explanation

Example

Analysis

Key Takeaways

Practice what you learned

You May Also Like

Related Reading

Related Study Notes in Software Engineering

Topics covered