Observer Pattern

What problem does it solve?

The Observer pattern defines a one-to-many dependency between objects: when one object — the subject (also called the observable) — changes state, every object that depends on it — its observers — is notified and updated automatically through a common update() callback. The subject keeps a list of observers and, on each state change, walks that list and invokes update() on each one, so observers stay in sync without the subject ever knowing their concrete types. That is the whole point: loose coupling.

Picture a weather station that feeds several displays: a current-conditions panel, a statistics panel, and a forecast panel. Each must refresh whenever new measurements arrive. The naive design wires every display directly into the station, so adding a fourth display means editing the station's code. That tight coupling makes the system rigid and hard to extend. The Observer pattern breaks that coupling: the station publishes updates, and any display that has subscribed receives them — with the station blind to the concrete display types.

Structure

The pattern is built from four roles. Two define contracts (interfaces), two are the concrete classes that implement them.

1. Subject (Observable) — an interface declaring registerObserver(o), removeObserver(o), and notifyObservers(). It owns the subscription list.
2. Concrete Subject — holds the real state. When that state changes it calls notifyObservers(), walking its list and invoking each observer's update().
3. Observer — an interface declaring a single update(...) method that the subject calls.
4. Concrete Observer — implements update() to react to the change, often keeping a copy of the relevant state in sync with the subject.

The key property: the concrete subject depends only on the Observer interface, never on the concrete observer classes. That is what lets you add new observers without touching the subject.

Implementation walkthrough

The subject keeps a list of observers and three operations over it: register, remove, and notify. Whenever its measured state changes it calls notifyObservers(), which iterates the list and pushes the new values into each observer's update(). Each concrete display registers itself with the subject in its constructor, so subscription is automatic at construction time.

interface Observer {
  void update(float temperature, float humidity, float pressure);
}

interface Subject {
  void registerObserver(Observer o);
  void removeObserver(Observer o);
  void notifyObservers();
}

class WeatherStation implements Subject {
  private List<Observer> observers = new ArrayList<>();
  private float temperature, humidity, pressure;

  public void registerObserver(Observer o) { observers.add(o); }
  public void removeObserver(Observer o)   { observers.remove(o); }

  public void notifyObservers() {
    for (Observer o : observers)
      o.update(temperature, humidity, pressure);
  }

  public void setMeasurements(float t, float h, float p) {
    this.temperature = t; this.humidity = h; this.pressure = p;
    notifyObservers();          // state changed -> fan out
  }
}

class CurrentConditionsDisplay implements Observer {
  CurrentConditionsDisplay(Subject s) { s.registerObserver(this); }
  public void update(float t, float h, float p) {
    System.out.println("Current conditions: " + t + "F, " + h + "% humidity");
  }
}

The same shape in Go uses a slice of an Observer interface instead of a List:

type Observer interface {
    Update(temp, humidity, pressure float64)
}

type WeatherStation struct {
    observers                     []Observer
    temperature, humidity, pressure float64
}

func (w *WeatherStation) Register(o Observer) { w.observers = append(w.observers, o) }

func (w *WeatherStation) Notify() {
    for _, o := range w.observers {
        o.Update(w.temperature, w.humidity, w.pressure)
    }
}

func (w *WeatherStation) SetMeasurements(t, h, p float64) {
    w.temperature, w.humidity, w.pressure = t, h, p
    w.Notify()
}

Tracing one state change

Say all three displays have registered, in this order: [current, statistics, forecast]. A sensor reading arrives and the app calls station.setMeasurements(80f, 65f, 30.4f). Follow the control flow:

The subject issued one call. Three independent reactors ran, in registration order, and the subject never referenced any of their concrete classes. Add a fourth display tomorrow and steps 1–2 and 6 are byte-for-byte identical — only the loop visits one more entry.

Push vs. pull — and the closest alternative

There are two ways the subject can deliver a change, and the choice is the main design tension inside the pattern.

• Push model (used above): the subject sends the changed data as arguments to update(temperature, humidity, pressure). Observers get everything immediately, but the signature is fixed — if a new field appears, every observer's update() changes. It also pushes data observers may not care about.
• Pull model: the subject calls a bare update(subject) and each observer reaches back via getters for only the fields it needs. This decouples observers from the full payload and tolerates new state gracefully, at the cost of extra calls back into the subject and a subject that must expose enough getters.

The closest structural alternative is a plain event bus / publish-subscribe broker. Compared to Observer, a pub-sub bus inserts a third party between publisher and subscriber, so the two never hold references to each other at all — better for cross-process or cross-service decoupling, but you lose the direct, synchronous, in-process update guarantee that Observer gives you and you take on broker infrastructure. Observer is the right tool when subject and observers live in the same process and you want a simple, synchronous, in-memory notification with no broker.

Pitfalls — the ones interviewers probe

1. Concurrent modification during notify (the #1 gotcha)

A very common requirement: an observer unsubscribes itself the moment it receives a terminal event. It calls removeObserver(this) from inside its own update(). But update() was invoked by the subject while the subject is still iterating the observer list — so the observer is mutating the very collection being walked.

// A one-shot alert that unsubscribes itself after it fires.
class HeatAlert implements Observer {
  private final Subject station;
  HeatAlert(Subject s) { this.station = s; s.registerObserver(this); }

  public void update(float t, float h, float p) {
    if (t > 100) {
      System.out.println("Heat alert!");
      station.removeObserver(this);   // BUG: mutates the list mid-iteration
    }
  }
}

With the naive for (Observer o : observers) loop, this throws ConcurrentModificationException. Why: the enhanced-for uses ArrayList's iterator, which snapshots a modCount when it is created and compares it against the list's live modCount on every next(). The self-removal bumps the live modCount; the next next() sees the mismatch and fails fast. (This is fail-fast detection, "best effort" — it is not guaranteed to fire, so a silently skipped observer is the even nastier version of the same bug.) The same thing happens if an observer registers a new observer during update().

The three standard fixes — and their trade-offs

(a) Iterate over a snapshot (copy) inside notify. Copy the list before walking it, so the iterator you traverse is disconnected from the list that update() mutates:

public void notifyObservers() {
  for (Observer o : new ArrayList<>(observers))   // walk a copy
    o.update(temperature, humidity, pressure);
}

Simplest and correct for self-removal on the notifying thread. Cost: an O(n) allocation-and-copy on every notification. Also note the copy itself iterates observers, so it does not make you thread-safe against another thread mutating during the copy — that still needs a lock. Semantics: the observer that removed itself still receives this round's notification (it was already in the snapshot).

(b) Use CopyOnWriteArrayList as the backing store.

private final List<Observer> observers = new CopyOnWriteArrayList<>();
// notifyObservers() body is unchanged — the iterator walks an immutable snapshot

Its iterator traverses an immutable snapshot of the array taken when the iterator was created, so a registration or removal during notify never throws and is simply invisible to the in-flight pass. Reads/iteration are lock-free; each write (register/remove) copies the whole backing array — O(n) per write. That trade — cheap reads, expensive writes — is exactly right for a listener list, which is notified constantly but subscribed to rarely. It is also inherently thread-safe. This is the standard production choice.

(c) Defer mutations until the loop finishes. Set a "notifying" flag; while it is set, register/remove enqueue their intent instead of touching the live list, and you drain the queue after the loop:

private boolean notifying = false;
private final List<Observer> pending = new ArrayList<>();

public void removeObserver(Observer o) {
  if (notifying) pending.add(o);       // defer — don't touch the live list
  else observers.remove(o);
}

public void notifyObservers() {
  notifying = true;
  try {
    for (Observer o : observers)
      o.update(temperature, humidity, pressure);
  } finally {
    notifying = false;
    observers.removeAll(pending);       // apply deferred removals now
    pending.clear();
  }
}

(registerObserver mirrors this with its own pending list.) No per-notify copy and no per-write array copy — the cheapest option when both notifications and subscription churn are hot and n is large. Cost: more code, and, like the other two, the mutation is invisible until the current notify completes. Not thread-safe on its own — cross-thread use still needs a lock.

2. Thread-safety of the list itself

Even without self-removal, calling registerObserver/removeObserver from one thread while another thread runs notifyObservers() races on a plain ArrayList — you get torn reads, lost updates, or a ConcurrentModificationException. Guard all three methods with the same lock, or use CopyOnWriteArrayList, which makes each operation atomic and each iteration snapshot-consistent with no lock on the read path. (Separately: if update() touches shared state, that state needs its own synchronization — a thread-safe observer list does not make the observers' work thread-safe.)

3. Re-entrant / cyclic notification

If A observes B and B observes A, a change to A notifies B, whose update() changes B, which notifies A, which notifies B… — unbounded recursion ending in StackOverflowError. Break the cycle with a "already notifying" guard that ignores re-entrant notifications, or coalesce changes so a burst produces one notification.

4. Undefined ordering & mid-notify visibility

A List-backed subject happens to fire in registration order, but the pattern guarantees no order — observers must never assume they run before or after another observer. And a subscription made mid-notify may or may not be seen this pass (with a snapshot or COW list it will not be), so observers must not rely on seeing their own or others' mid-notify changes.

5. Lapsed-listener memory leak

The subject holds strong references to its observers, so an observer that forgets to unregister can never be garbage-collected (the subject keeps it alive) and keeps receiving updates it no longer wants. Fix with an explicit removeObserver in the observer's lifecycle/close hook, or hold observers via WeakReference so the GC can reclaim one nothing else references — at the cost of having to prune expired references and losing the guarantee that the subject keeps the observer alive.

6. Update storms & heavy work in update()

notifyObservers() runs every observer's update() synchronously on the subject's thread, in sequence: one slow or blocking observer stalls the whole fan-out and the subject. And a change whose update() mutates another subject can cascade into an update storm. Keep update() fast; offload heavy or blocking work to a queue/executor, and coalesce or batch high-frequency updates rather than fanning out on every mutation.

Applications, pros, and cons

Observer shows up wherever one state change must fan out to many reactors: GUI event handling (clicks, keypresses), data monitoring (stock tickers, dashboards), the model-to-view link in MVC, and notification services in social and news apps.

When to use it — and when not to

Reach for Observer when

• One object's state change must notify a varying, open-ended set of dependents, and you do not want the subject to know their concrete types (so you can add new reactors without editing the source).
• The subject and its observers live in the same process and you want simple, synchronous, in-memory notification with no broker or queue.
• The set of dependents must be configured at runtime — subscribers come and go (UI panels opening/closing, clients connecting).
• You are wiring a model to its views, as in MVC, where views must stay in sync with model state.

Prefer something else when

• There is exactly one, fixed dependent. A direct method call is simpler and traceable — the Observer indirection only adds ceremony and obscures control flow when the fan-out is one.
• Objects must coordinate in complex many-to-many ways (A affects B affects C, with rules). That is the Mediator pattern's job: centralize the interaction logic in one mediator rather than scattering it across mutual subscriptions, which with Observer degenerates into a hard-to-follow web of callbacks (and invites the cyclic-notification trap above).
• Producer and consumers must be decoupled across processes, services, or time (durability, retries, fan-out to unknown subscribers). Use a publish-subscribe message bus / broker (e.g. a topic queue like Kafka) instead — it removes the direct reference Observer still requires and survives restarts, at the cost of broker infrastructure.
• You are composing streams of asynchronous events with filtering, mapping, buffering, backpressure, or completion/error semantics. Reach for reactive streams — the JDK-native java.util.concurrent.Flow SPI (a Publisher notifies Subscribers, but with first-class onError/onComplete and, crucially, Subscription.request(n) backpressure), or a library like RxJava / Reactor (Go's equivalent is channels with a pipeline). Hand-rolled Observer has no backpressure and no error/complete signals, so a fast subject can overwhelm a slow observer and those concerns leak into every update(). Flow is essentially "Observer done right for async streams."
• Updates are extremely frequent and the observer set is large, making per-change broadcast a hotspot. Consider batching, coalescing, or a pull-based polling design rather than synchronous fan-out on every mutation.

Rule of thumb: Observer is the lightweight, in-process, one-to-many notifier. The moment you need cross-boundary decoupling, durability, complex coordination, or stream operators with backpressure, graduate to a bus, a mediator, or reactive streams (Flow) respectively — and for a single fixed listener, just call the method.

Takeaways

• Mechanism: a subject holds a list of observers and, on each state change, calls a common update() on every one — staying blind to their concrete types. That is the loose coupling that lets you add reactors without touching the subject.
• The #1 gotcha: an observer that mutates the list from inside update() (typically self-unsubscribe) throws ConcurrentModificationException because notify is iterating the very list being mutated. Fix by iterating a snapshot, backing the list with CopyOnWriteArrayList (the standard production choice — cheap reads, snapshot iteration), or deferring mutations until after the loop.
• A plain ArrayList is not thread-safe. Register/remove/notify across threads race; synchronize all three or use CopyOnWriteArrayList. Watch too for cyclic notification (StackOverflowError) and the lapsed-listener memory leak.
• Know when to graduate: a pub-sub bus for cross-process/durable decoupling, a Mediator for complex many-to-many coordination, reactive streams (java.util.concurrent.Flow) for async streams with backpressure — and a plain method call for a single fixed listener.

Putting a number on the abstraction tax

Every pattern decision above was argued qualitatively — "cheap reads, expensive writes", "an O(n) copy per write". That is how pattern choices are usually made, and it is how they go wrong: every abstraction costs indirection, but you cannot manage a cost you never measure. So attach an actual number. The discipline is the same for any pattern: write the per-operation cost as a formula, plug in your real n and your real read/write ratio, and let the arithmetic — not the aesthetic — pick the structure.

The COW crossover, in numbers

Recall the "standard production choice": back the observer list with CopyOnWriteArrayList. Its cost model is exact — each mutating call (register/remove) allocates a fresh array and copies all n current elements, so one subscribe or unsubscribe = one O(n) allocation + copy; iteration/notify is a lock-free read of an existing snapshot, ~O(1) to start. So the total copy work COW imposes is writes × n element-copies. Put that against the alternatives:

The crossover is not about n alone and not about write-rate alone — it is the product writes × n. COW is engineered for the top rows (read/iterate-heavy, write-rare); the bottom row is exactly the workload it is wrong for.

The named trade-off, priced

Three structures, same decision, now with cost attached rather than adjectives:

Now the choice is arithmetic: notify-per-sec × copy-cost vs. write-per-sec × copy-cost. Snapshot-list moves the O(n) tax onto notify; COW moves it onto writes; the concurrent set refuses to pay a bulk copy on either path, spending instead a small per-entry overhead and giving up snapshot-consistent iteration (a mutation mid-walk may or may not be seen — acceptable for a listener list, as the pitfalls section already established).

Two more, so the habit sticks

• Decorator — the tax is stack depth. Wrapping a target in k decorators is k extra heap allocations at construction, and every call to a wrapped method walks k extra stack frames before reaching the real object. A new BufferedReader(new InputStreamReader(new FileInputStream(f))) is 3 frames per read(); a 20-deep decorator chain on a hot path is 20 frames × call-frequency — measurable, and the reason you flatten deep chains on hot code.
• Flyweight — the tax is negative (that is the point), and it is computable: naive cost = objects × per-object bytes; flyweight cost = uniqueFlyweights × per-object bytes + objects × referenceBytes. For 1,000,000 glyphs sharing 96 distinct Character flyweights at ~40 bytes each, with 8-byte references: naive ≈ 40 MB; flyweight ≈ 96×40 + 1,000,000×8 ≈ 8 MB. The saving is real only when objects ≫ uniqueFlyweights — if every object is unique the reference overhead makes it a net loss, and only the formula tells you which regime you are in.

The lesson is not these three numbers; it is the move: convert "this abstraction costs indirection" into a cost expressed in your real n and access ratio, then compare it to the named alternative's cost the same way. Measure the tax before you agree to pay it.

Adapted and expanded from the Knowledge Guide lesson "Observer Pattern" (OO & Low-Level Design › Behavioral), carrying forward its weather-station example and structure/implementation breakdown; the concurrent-modification analysis and fixes synthesized from the JDK ArrayList/CopyOnWriteArrayList fail-fast semantics and Java Concurrency in Practice (Goetz), push-vs-pull and alternatives from the Gang of Four Design Patterns, and the reactive comparison from the java.util.concurrent.Flow / Reactive Streams specification. Re-authored/Deepened for this guide.