Observer Pattern

Description

Observer is the behavioral pattern for "when this happens, tell whoever cares": a subject keeps a list of observers and notifies each one when something changes, without knowing what they do. It's the idea behind UI event listeners, framework events, signals, reactive streams and - between services - publish/subscribe messaging. This skill covers the pattern, push versus pull, and the lifecycle and failure problems every real event system runs into.

When an order is placed, several things must happen: send a confirmation email, update inventory, record analytics. The quick version calls each of them directly:

class OrderService {
    void placeOrder(Order order) {
        save(order);
        emailService.sendConfirmation(order);
        inventoryService.reserve(order);
        analytics.track("order_placed", order);
        // next month: loyalty points... then fraud checks...
    }
}

class OrderService:
    def place_order(self, order: Order) -> None:
        self._save(order)
        self._email_service.send_confirmation(order)
        self._inventory_service.reserve(order)
        self._analytics.track("order_placed", order)
        # next month: loyalty points... then fraud checks...

OrderService now knows about every part of the system that cares about orders. Each new reaction means editing it, and a bug in analytics can break checkout.

We'll go from simple to more technical:

1. The pattern: a subject, an observer interface, subscribe and notify.
2. How notification works, step by step - including push versus pull.
3. Where you'll see observers, from button listeners to Kafka.
4. Leaks, changes during notification, failing observers - and choosing among the behavioral patterns.

The pattern

Observer lets an object (the subject, or publisher) keep a list of observers (subscribers) and notify all of them when something happens. The subject only knows the observer interface - never the concrete classes.

interface OrderListener {
    void onOrderPlaced(Order order);
}

class OrderService {
    private final List<OrderListener> listeners = new CopyOnWriteArrayList<>();

    void subscribe(OrderListener l)   { listeners.add(l); }
    void unsubscribe(OrderListener l) { listeners.remove(l); }

    void placeOrder(Order order) {
        save(order);
        for (OrderListener l : listeners) l.onOrderPlaced(order);
    }
}

orderService.subscribe(order -> emailService.sendConfirmation(order));
orderService.subscribe(inventoryService::reserve);

from collections.abc import Callable

type OrderListener = Callable[[Order], None]


class OrderService:
    def __init__(self):
        self._listeners: list[OrderListener] = []

    def subscribe(self, listener: OrderListener) -> None:
        self._listeners.append(listener)

    def unsubscribe(self, listener: OrderListener) -> None:
        self._listeners.remove(listener)

    def place_order(self, order: Order) -> None:
        self._save(order)
        for listener in list(self._listeners):    # a snapshot: safe if one unsubscribes
            listener(order)


order_service.subscribe(email_service.send_confirmation)
order_service.subscribe(inventory_service.reserve)

Adding loyalty points later is one new subscribe(...) call. OrderService never changes.

In Python an observer is usually just a callable - a function or a bound method like email_service.send_confirmation - so the "interface" is Callable[[Order], None] and there is no class to implement.

How it works, step by step

1. Define an observer interface with one method per kind of event.
2. The subject keeps a list of observers and offers subscribe / unsubscribe.
3. When the event happens, the subject loops over the list and calls each observer.
4. Observers decide for themselves what to do; the subject doesn't care.
5. Push vs. pull: either send the data with the notification (onOrderPlaced(order)), or just say "something changed" and let observers ask for what they need.

Where you'll see it

• UI event listeners: button.addActionListener(...), element.addEventListener("click", ...).
• Spring's ApplicationEventPublisher with @EventListener methods.
• In Python, Django's signals (post_save.connect(handler)) and Qt's signals and slots.
• Reactive libraries (java.util.concurrent.Flow, RxJava, Reactor) are Observer with extra features.
• At system scale, publish/subscribe messaging (Kafka topics, SNS/SQS) is the same idea between services.

Choosing among the behavioral patterns

Common mistakes

Check yourself

Try to answer before opening each one - recalling beats re-reading.

1. Why does the subject know only the observer interface, never the concrete classes?

2. A dialog subscribes to a long-lived service and never unsubscribes. What happens after many dialogs are opened and closed?

3. Name two ways to make notification safe when observers subscribe or unsubscribe during delivery.

Key takeaways

• The subject notifies observers through an interface - it never knows the concrete classes.
• New reactions are new subscribers; the publisher doesn't change.
• Always give observers a way to unsubscribe, or they leak.
• Iterate over a snapshot and isolate each observer's exceptions.
• Between services, the same idea becomes publish/subscribe messaging.