Observer Pattern

1The problem it solves#

Start with the pain, because the pattern only makes sense against the thing it kills.

• Say you are building a stock ticker. A Stock object holds the current price.
• When the price moves, three things have to react: a price chart redraws, an alert service checks if someone wanted a ping at $150, and a logger writes the change to disk.

The naive version looks like this:

class Stock {
    void setPrice(double price) {
        this.price = price;
        chart.redraw(price);
        alertService.check(this.symbol, price);
        logger.log(this.symbol, price);
    }
}

This works right up until it does not.

• Marketing wants an email when a stock crosses a threshold. So you open Stock and add a line.
• Then someone wants a mobile push. Open Stock again.
• The Stock class now imports chart libraries, email clients, and push SDKs. It knows about everyone.
• Every new reaction means editing the one class that should only care about price.

The smell, named precisely.

• A subject that owns a piece of state is also responsible for knowing every party interested in that state. Those are two different jobs.
• Weld them together and you touch core code for every peripheral feature.
• It breaks the Single Responsibility Principle: Stock now has two reasons to change, the pricing rules and the list of reactors.
• It breaks the Open-Closed Principle: adding a reaction forces a modification instead of an extension.

2The idea (mental model)#

Flip the relationship so the subject stops reaching out and starts being subscribed to.

• Instead of the Stock calling each interested party by name, interested parties register themselves with the stock.
• The stock keeps a list of "things that asked to be told."
• When its state changes, it loops over that list and says "something changed."
• It does not know or care who is in the list or what they do with the news.

The group-chat analogy.

• The sender posts once. Everyone subscribed gets the message.
• People join and leave the chat freely.
• The sender never maintains a personal contact list for each announcement.

Two roles, and that is the whole cast.

• Subject (also Observable or Publisher): owns the state, holds the list of observers, notifies them on change.
• Observer (Subscriber or Listener): implements a known method the subject can call, like update(...).

The trick is a single indirection.

• The subject depends on an interface, not on concrete observers.
• The subject says "I will call update() on whatever is in my list," and the list can hold a chart, a logger, an email sender, anything that honors the interface.
• This is the Dependency Inversion Principle in one move: the high-level Stock and the low-level EmailNotifier both depend on the Observer abstraction, not on each other.

3Structure#

Four moving pieces, and the arrows between them are the real content.

• A Subject interface with register, unregister, and notify.
• A concrete subject that holds state and the observer list.
• An Observer interface with an update method.
• Concrete observers that do the actual work.

Dependency direction, which is worth pointing at on the board.

• The concrete subject points at the Observer interface.
• The concrete observers point at the Observer interface too (they implement it).
• Nobody points at a concrete observer class.
• That is what keeps the subject open to new listeners without edits. Draw that arrow correctly and you have basically answered the question.

One detail a strong candidate calls out: the aggregation.

• Note the aggregation (o--) between Stock and Observer. The observers live independently of the stock.
• The stock just holds references to them. It does not own their lifecycle and does not create or destroy them.
• That is the correct relationship here (aggregation, not composition): a chart or an alert service outlives any single stock it happens to watch.

4Implementation in Java#

Clean, no framework, shows the design. This is the version to write at the board.

// The contract every listener honors.
interface StockObserver {
    void update(String symbol, double price);
}

// The thing observers can register with.
interface Subject {
    void registerObserver(StockObserver o);
    void removeObserver(StockObserver o);
    void notifyObservers();
}

class Stock implements Subject {
    private final String symbol;
    private double price;
    private final List<StockObserver> observers = new CopyOnWriteArrayList<>();

    public Stock(String symbol) {
        this.symbol = symbol;
    }

    @Override
    public void registerObserver(StockObserver o) {
        observers.add(o);
    }

    @Override
    public void removeObserver(StockObserver o) {
        observers.remove(o);
    }

    @Override
    public void notifyObservers() {
        for (StockObserver o : observers) {
            o.update(symbol, price);
        }
    }

    public void setPrice(double price) {
        this.price = price;
        notifyObservers();   // state changed, tell everyone
    }
}

Now the observers. Each one does its own thing and knows nothing about the others.

class PriceChart implements StockObserver {
    @Override
    public void update(String symbol, double price) {
        System.out.println("Chart: redraw " + symbol + " at " + price);
    }
}

class AlertService implements StockObserver {
    private final double threshold;

    public AlertService(double threshold) {
        this.threshold = threshold;
    }

    @Override
    public void update(String symbol, double price) {
        if (price >= threshold) {
            System.out.println("Alert: " + symbol + " hit " + price);
        }
    }
}

And wiring it together:

Stock apple = new Stock("AAPL");
apple.registerObserver(new PriceChart());
apple.registerObserver(new AlertService(150.0));

apple.setPrice(148.0);   // chart redraws, no alert
apple.setPrice(152.0);   // chart redraws, alert fires

The payoff, stated plainly.

• Adding an email notifier later means writing one new class that implements StockObserver and calling registerObserver.
• You never reopen Stock.
• That is the Open-Closed Principle paying rent.

Two deliberate choices worth saying out loud.

• The CopyOnWriteArrayList is not an accident. If an observer removes itself (or another observer) during a notification, a plain ArrayList throws ConcurrentModificationException. Copy-on-write sidesteps that because iteration runs over a snapshot. It also fits observer lists exactly: you read (notify) often and write (register, remove) rarely, which is the workload it is tuned for.
• The data goes into update(symbol, price), which is the push model. The alternative is the pull model, where update() just signals "something changed" and the observer calls back into the subject to read what it needs.

5A real-world example#

You have used this pattern whether you named it or not.

• UI event listeners. Every button click handler is Observer. The button is the subject, your onClick is the observer. The button does not know what your handler does, it just calls it.
• Model-View architectures. The model is the subject, views are observers. Change the data once and every view showing it refreshes. This is the backbone of a lot of frontend state management.
• Java's own libraries. PropertyChangeListener in Swing and the listener interfaces all over the JDK. Reactive libraries (the Flowable and Observable types in RxJava) are Observer with backpressure and operators bolted on.

One versioning note a careful candidate mentions.

• The old java.util.Observer and java.util.Observable were deprecated in Java 9.
• If you reference the JDK, reference the newer listener interfaces or reactive streams, not the deprecated pair.

Pub/sub and message queues are Observer scaled across machines, with one real difference.

• Kafka, Redis pub/sub, and the like keep the same shape in a bigger box: publishers do not know their subscribers, and the broker holds the subscription list.
• The difference to name: an in-process Observer call is synchronous and in-memory.
• A message broker adds durability, async delivery, and retries, so it survives a subscriber being offline. An in-memory observer list does not.

6When to use it, and when not to#

Reach for it when:

• One change needs to fan out to many independent reactions.
• The set of reactions is not fixed. Things subscribe and unsubscribe at runtime.
• You want the source of the change decoupled from the things reacting to it.

Skip it when:

• There is exactly one reaction and it will always be one. A direct method call is clearer. Do not add a listener interface to feel clever.
• The relationships form a web where A notifies B notifies C notifies A. Observer makes cascading updates easy, which is the rope you hang yourself with. Cycles are brutal to debug because the stack trace is a loop and nothing tells you which hop re-triggered the first.
• Order of notification matters and you need guarantees. The pattern says nothing about order. If observer B must run after observer A, you are fighting the pattern and probably want an explicit pipeline or a mediator.

Observer versus a full event bus, since interviewers probe the line.

• Plain Observer is a direct, in-process, synchronous call from one subject to its own list of listeners.
• An event bus adds a middleman: publishers and subscribers never see each other, events are typed and routed, and delivery can be async or buffered.
• Use plain Observer when one subject has a known handful of listeners. Use a bus when many unrelated producers and consumers need to meet without any of them holding a reference to the others.

7Common mistakes#

Modifying the list mid-notify (re-entrancy).

• If update() triggers a register or remove on the same subject while you are looping, a plain list blows up with ConcurrentModificationException.
• Fix: copy-on-write, or iterate over a defensive snapshot.

Order dependence sneaking in.

• People write observers that quietly assume another observer already ran.
• Works today because of insertion order, breaks the day someone registers in a different sequence.
• If you feel this creeping in, the pattern is the wrong tool.

Doing heavy work synchronously in update().

• If one observer makes a slow network call inside update(), it blocks the subject and every observer after it in the loop.
• One observer that takes 2 seconds stalls the entire notify.
• In a real system, hand slow work to a queue or an executor so update() just enqueues and returns. Say this out loud, it shows you think past the toy example.

Swallowing or propagating exceptions wrong.

• If one observer throws inside the loop, do the rest still get notified? Decide on purpose.
• Usually you catch per observer, log it, and keep going, so one bad listener does not blind the others.
• An interviewer who asks "what if observer 3 throws?" is checking whether you thought about this.

Leaking too much state.

• In push mode, do not dump the subject's entire internal state into update(). Pass what observers actually need.
• Over-sharing couples observers to the subject's internals and defeats half the point.

8Where it shows up in interviews#

Interviewers love Observer because it is a clean test of whether you understand dependency direction. Expect prompts shaped like:

• "Design a notification system." The user is the subject; email, SMS, and push channels are observers.
• "Design a stock price tracker" or "a weather station with multiple displays." Textbook subject with many views.
• "Design a chat room, auction, or live-score app." Members or bidders observe a shared subject.

What a grader is listening for when running these.

1. Do you introduce an Observer interface, or hard-code the concrete listeners into the subject? The interface is the whole answer.
2. Can you add a new observer type without touching the subject? If yes, you nailed the Open-Closed Principle without being asked.
3. Do you mention push versus pull, and justify your choice?
4. Do you catch the lifecycle issue (unregister, leaks) and the concurrency issue (modifying during notify)? Strong signal.
5. Can you say where it breaks (cycles, ordering, one slow or throwing observer) instead of selling it as a cure-all?

Code the skeleton in two minutes, then talk through those trade-offs, and you have shown exactly what a Medium pattern question is meant to surface. The candidates who pass the loop volunteer the failure modes before anyone asks.

Next, look at the Publish-Subscribe and Mediator patterns (close cousins when the wiring gets busy), and the "Design a Notification Service" and "Design an Auction System" LLD problems where Observer is the load-bearing piece.