Behavioral
Observer Pattern
Notify dependents automatically when one object changes state. A foundational behavioral pattern — the backbone of event-driven systems, pub/sub architectures, and reactive programming.
Overview · Behavioral · Singleton · Factory Method · Abstract Factory · Builder · Prototype · Adapter · Bridge · Composite · Decorator · Facade · Flyweight · Proxy · Observer · Strategy · Command · Template Method · Chain of Resp. · State · Mediator · Iterator · Visitor · Memento · Interpreter
01
Section One · The Problem
Why Observer Exists
You are building a stock trading platform. A StockPrice object holds the current price of a ticker symbol. Multiple parts of the system care about price changes: a charting widget needs to redraw, a portfolio tracker needs to recalculate totals, an alert service needs to check thresholds, and a logging service needs to record the history. The naive approach: the StockPrice class directly calls each dependent.
Naive approach — hard-coded notifications
// ✗ StockPrice knows every consumer by name class StockPrice {
private double price;
private ChartWidget chart; // hard dep #1 private PortfolioTracker portfolio; // hard dep #2 private AlertService alerts; // hard dep #3 private PriceLogger logger; // hard dep #4 public void setPrice(double p) {
this.price = p;
chart.redraw(price); // ← must know Chart API
portfolio.recalculate(price); // ← must know Portfolio API
alerts.checkThresholds(price); // ← must know Alert API
logger.log(price); // ← must know Logger API
}
}
// Add a 5th consumer? Edit StockPrice. Remove one? Edit StockPrice.
What goes wrong:
- Tight coupling —
StockPricedepends on every consumer class; changing any consumer’s API forces edits toStockPrice - Open/Closed violation — adding or removing a consumer means editing
setPrice(); the class is never closed for modification - No runtime flexibility — you can’t subscribe or unsubscribe a consumer at runtime (e.g. user closes the chart widget)
- Untestable — testing
StockPricerequires instantiating Chart, Portfolio, Alert, and Logger; mocking is painful
Without Observer — subject hard-wired to every consumer
This is the problem Observer solves — define a one-to-many dependency so that when the subject (StockPrice) changes state, all registered observers are notified automatically, without the subject knowing who they are or what they do.
02
Section Two · The Pattern
What Is Observer?
Observer is a behavioral pattern that defines a one-to-many dependency between objects: when one object (the subject) changes state, all its dependents (the observers) are notified and updated automatically. The subject maintains a list of observers and calls a common update() method on each one whenever something interesting happens. Observers can subscribe and unsubscribe at runtime — the subject doesn’t know or care what the observers do with the notification.
GoF Intent: “Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.”
— Gamma, Helm, Johnson, Vlissides (1994)
— Gamma, Helm, Johnson, Vlissides (1994)
Analogy — newspaper subscription: A newspaper publisher (the subject) doesn’t hand-deliver papers to random people. Instead, readers subscribe. When a new edition is printed, every subscriber receives a copy automatically. The publisher doesn’t know what each subscriber does with the paper — one reads the sports section, another clips coupons, a third lines a bird cage. A reader can unsubscribe at any time, and the publisher simply stops delivering. New subscribers join without the publisher changing its printing process. This is Observer: the publisher only knows that subscribers exist; it never depends on what they do.
Key insight: Observer inverts the dependency. Without the pattern, the subject calls each consumer by name (tight coupling). With Observer, the subject calls a generic interface (Observer.update()) and has no idea who is listening. The observers depend on the subject — not the other way around. This is why Observer is the foundation of every event system: DOM events, Java Swing listeners, RxJava, React state, Kafka consumers, and message queues all trace back to this pattern.
Subject holds a
List<Observer> — not a list of concrete classes▶
Adding a new observer type requires zero changes to the subject — Open/Closed Principle
subscribe() and unsubscribe() allow runtime registration▶
Observers come and go dynamically — user closes a widget, it unsubscribes; user opens a new chart, it subscribes
When state changes, subject loops through the list and calls
observer.update(data)▶
Every observer reacts independently — one redraws a chart, another sends an alert, another writes a log. The subject doesn’t know or care.
Observer depends on the subject (subscribes to it); subject depends only on the Observer interface
▶
Loose coupling — subject and observers can be developed, tested, and deployed independently
03
Section Three · Anatomy
Participants & Structure
| Participant | Role | In the Analogy |
|---|---|---|
| Subject (Publisher) | Holds the state of interest and a list of observers. Provides subscribe(), unsubscribe(), and notifyObservers() methods. When state changes, iterates the list and calls update() on each observer. | The newspaper publisher — maintains a subscriber list and distributes each new edition. |
| Observer (Subscriber) | An interface with a single method: update(data). Every concrete observer implements this to react to state changes in its own way. | The subscription contract — “you will receive a paper.” |
| Concrete Subject | A specific implementation that holds domain state (e.g. stock price). Calls notifyObservers() whenever that state changes. | The New York Times — a specific publisher with specific content. |
| Concrete Observer | Implements update() with domain-specific logic. Knows nothing about other observers. Can subscribe/unsubscribe at any time. | Individual subscribers — one reads sports, another clips coupons, a third wraps fish. |
Observer — UML Class Diagram
Push vs. Pull model:
- In the push model, the subject sends the changed data inside
update(data)— observers get everything they need in one call. - In the pull model,
update()passes only a reference to the subject — observers then query the specific fields they care about. - Push is simpler; Pull avoids sending data observers don’t need. Both are valid Observer implementations.
04
Section Four · How It Works
The Pattern In Motion
Scenario: A stock price feed for AAPL. Three observers subscribe: a chart widget, a portfolio tracker, and an alert service. When the price changes, all three are notified automatically.
Step 1 — Create the subject:
StockPriceFeed feed = new StockPriceFeed("AAPL")▶
The feed has an empty
List<Observer>. No one is listening yet.Step 2 — Observers subscribe:
feed.subscribe(chart), feed.subscribe(portfolio), feed.subscribe(alert)▶
The feed’s observer list now has 3 entries. The feed knows nothing about these objects except that they implement
Observer.Step 3 — State changes:
feed.setPrice(182.50)▶
setPrice() stores the new price, then calls notifyObservers(), which loops through the list and calls observer.update("AAPL", 182.50) on each.Step 4 — Each observer reacts independently
▶
ChartWidget redraws the candlestick. PortfolioTracker recalculates the total value. AlertService checks if the price crossed a threshold. None knows about the others.Step 5 — User closes the chart:
feed.unsubscribe(chart)▶
The chart is removed from the list. Next
setPrice() notifies only portfolio and alert. No code changes — just a runtime call.Observer — Notification Sequence
The pattern in pseudocode
// ── Setup ── StockPriceFeed feed = new StockPriceFeed("AAPL");
feed.subscribe(new ChartWidget());
feed.subscribe(new PortfolioTracker());
feed.subscribe(new AlertService(180.0));
// ── Price changes → all 3 observers notified automatically ──
feed.setPrice(182.50);
// Output: // 📈 Chart: AAPL → $182.50 // 💼 Portfolio: AAPL now $182.50 // 🔔 Alert: AAPL crossed $180.00! Now $182.50
Behavioral patterns need both static UML and dynamic sequence:
- The UML (S03) shows who participates. The sequence diagram above shows who calls whom in what order.
- For Observer, the key runtime insight is:
setPrice()triggersnotifyObservers(), which iterates the list and dispatchesupdate()to each observer sequentially.
05
Section Five · Java Stdlib
You Already Use This
Observer is arguably the most pervasive pattern in the JDK. Every event listener, every property change notification, and every reactive stream is an Observer under the hood.
IN JAVA
Example 1
java.util.EventListener — the root marker interface for all AWT/Swing listeners. ActionListener, MouseListener, KeyListener are all Observer interfaces. A JButton (subject) holds a list of ActionListeners and calls actionPerformed(e) on each when clicked. Example 2
java.beans.PropertyChangeListener — a generic Observer for JavaBeans. Call addPropertyChangeListener() on any bean; when a property changes, propertyChange(PropertyChangeEvent) fires on all listeners. Used heavily in Swing models and Spring framework internals. Example 3
java.util.concurrent.Flow (Java 9+) — the reactive streams API built into the JDK. Flow.Publisher is the subject; Flow.Subscriber is the observer. Supports backpressure via request(n). This is Observer scaled for async, non-blocking systems. Deprecated
java.util.Observable / java.util.Observer — the original JDK Observer from Java 1.0. Deprecated since Java 9 because Observable is a class (not an interface), forcing single inheritance, and it isn’t thread-safe. Use PropertyChangeListener or Flow instead. Stdlib usage — Swing ActionListener
// JButton = Subject, ActionListener = Observer JButton button = new JButton("Click me");
// Subscribe observer #1
button.addActionListener(e ->
System.out.println("Observer 1: button clicked!"));
// Subscribe observer #2
button.addActionListener(e ->
System.out.println("Observer 2: logging click event"));
// When user clicks → both listeners fire automatically
Stdlib usage — PropertyChangeListener
// Generic Observer for any bean property PropertyChangeSupport pcs = new PropertyChangeSupport(this);
pcs.addPropertyChangeListener(evt ->
System.out.println(evt.getPropertyName() + ": "
+ evt.getOldValue() + " → " + evt.getNewValue()));
// Fire notification
pcs.firePropertyChange("price", 150.0, 182.5);
// Output: price: 150.0 → 182.5
Why
java.util.Observable is deprecated: - It’s a class, not an interface — your subject can’t extend anything else.
- It’s not thread-safe. Its
setChanged()/notifyObservers()API is clunky. - Modern alternatives:
PropertyChangeSupportfor synchronous bean events,Flow.Publisherfor reactive streams, or simply roll your ownList<Observer>(it’s ~10 lines of code).
06
Section Six · Implementation
Build It Once
Domain: Stock Price Feed. A StockPriceFeed subject notifies subscribed observers (chart, portfolio, alert) whenever the price changes. Observers subscribe/unsubscribe at runtime.
Java — Observer Pattern Stock Feed (core)
// ── Observer interface ── interface PriceObserver {
void update(String ticker, double price);
}
// ── Subject ── class StockPriceFeed {
private final String ticker;
private double price;
private final List<PriceObserver> observers = new ArrayList<>();
public void subscribe(PriceObserver o) { observers.add(o); }
public void unsubscribe(PriceObserver o) { observers.remove(o); }
public void setPrice(double p) {
this.price = p;
for (PriceObserver o : observers) o.update(ticker, price);
}
}
Observer — Full Implementation
Java — Complete Observer + 3 Observers + Driver
import java.util.*;
// ═══ Observer Interface ═══ interface PriceObserver {
void update(String ticker, double price);
}
// ═══ Subject: StockPriceFeed ═══ class StockPriceFeed {
private final String ticker;
private double price;
private final List<PriceObserver> observers = new ArrayList<>();
public StockPriceFeed(String ticker, double initialPrice) {
this.ticker = ticker;
this.price = initialPrice;
}
public void subscribe(PriceObserver o) { observers.add(o); }
public void unsubscribe(PriceObserver o) { observers.remove(o); }
public void setPrice(double newPrice) {
this.price = newPrice;
notifyObservers();
}
private void notifyObservers() {
// iterate over a copy to allow unsubscribe during notification for (PriceObserver o : new ArrayList<>(observers)) {
o.update(ticker, price);
}
}
}
// ═══ Concrete Observer: ChartWidget ═══ class ChartWidget implements PriceObserver {
@Override
public void update(String ticker, double price) {
System.out.printf(" 📈 Chart: %s → $%.2f (redrawing candle)%n", ticker, price);
}
}
// ═══ Concrete Observer: PortfolioTracker ═══ class PortfolioTracker implements PriceObserver {
private final int shares;
public PortfolioTracker(int shares) { this.shares = shares; }
@Override
public void update(String ticker, double price) {
System.out.printf(" 💼 Portfolio: %d shares of %s = $%.2f%n",
shares, ticker, shares * price);
}
}
// ═══ Concrete Observer: AlertService ═══ class AlertService implements PriceObserver {
private final double threshold;
public AlertService(double threshold) { this.threshold = threshold; }
@Override
public void update(String ticker, double price) {
if (price >= threshold) {
System.out.printf(" 🔔 Alert: %s crossed $%.2f! Now $%.2f%n",
ticker, threshold, price);
} else {
System.out.printf(" 🔕 Alert: %s at $%.2f (below $%.2f)%n",
ticker, price, threshold);
}
}
}
// ═══ Driver ═══ public class ObserverDemo {
public static void main(String[] args) {
StockPriceFeed feed = new StockPriceFeed("AAPL", 175.00);
// 1. Subscribe three observers ChartWidget chart = new ChartWidget();
PortfolioTracker portfolio = new PortfolioTracker(10);
AlertService alert = new AlertService(180.00);
feed.subscribe(chart);
feed.subscribe(portfolio);
feed.subscribe(alert);
// 2. Price changes → all 3 notified
System.out.println("=== Price update: $182.50 ===");
feed.setPrice(182.50);
// 3. Price drops below threshold
System.out.println("\n=== Price update: $178.00 ===");
feed.setPrice(178.00);
// 4. Unsubscribe chart, then update
feed.unsubscribe(chart);
System.out.println("\n=== Price update: $185.00 (chart unsubscribed) ===");
feed.setPrice(185.00);
}
}
/* Output:
=== Price update: $182.50 ===
📈 Chart: AAPL → $182.50 (redrawing candle)
💼 Portfolio: 10 shares of AAPL = $1825.00
🔔 Alert: AAPL crossed $180.00! Now $182.50
=== Price update: $178.00 ===
📈 Chart: AAPL → $178.00 (redrawing candle)
💼 Portfolio: 10 shares of AAPL = $1780.00
🔕 Alert: AAPL at $178.00 (below $180.00)
=== Price update: $185.00 (chart unsubscribed) ===
💼 Portfolio: 10 shares of AAPL = $1850.00
🔔 Alert: AAPL crossed $180.00! Now $185.00
*/
Python — Observer Pattern Stock Feed
from abc import ABC, abstractmethod
# ═══ Observer Interface ═══ class PriceObserver(ABC):
@abstractmethod
def update(self, ticker: str, price: float): ...
# ═══ Subject ═══ class StockPriceFeed:
def __init__(self, ticker: str, initial: float):
self.ticker = ticker
self.price = initial
self._observers: list[PriceObserver] = []
def subscribe(self, o): self._observers.append(o)
def unsubscribe(self, o): self._observers.remove(o)
def set_price(self, new_price: float):
self.price = new_price
for o in list(self._observers):
o.update(self.ticker, self.price)
# ═══ Concrete Observers ═══ class ChartWidget(PriceObserver):
def update(self, ticker, price):
print(f" 📈 Chart: {ticker} → ${price:.2f}")
class PortfolioTracker(PriceObserver):
def __init__(self, shares: int):
self.shares = shares
def update(self, ticker, price):
print(f" 💼 Portfolio: {self.shares} × {ticker} = ${self.shares * price:.2f}")
class AlertService(PriceObserver):
def __init__(self, threshold: float):
self.threshold = threshold
def update(self, ticker, price):
if price >= self.threshold:
print(f" 🔔 Alert: {ticker} crossed ${self.threshold:.2f}! Now ${price:.2f}")
else:
print(f" 🔕 Alert: {ticker} at ${price:.2f} (below ${self.threshold:.2f})")
# ═══ Driver ═══
feed = StockPriceFeed("AAPL", 175.0)
chart = ChartWidget()
portfolio = PortfolioTracker(10)
alert = AlertService(180.0)
feed.subscribe(chart)
feed.subscribe(portfolio)
feed.subscribe(alert)
print("=== Price: $182.50 ===")
feed.set_price(182.50)
print("\n=== Price: $178.00 ===")
feed.set_price(178.00)
feed.unsubscribe(chart)
print("\n=== Price: $185.00 (chart gone) ===")
feed.set_price(185.00)
ConcurrentModificationException trap:
- Notice the
notifyObservers()method iterates overnew ArrayList<>(observers)— a copy of the list. - If you iterate the original list and an observer unsubscribes during notification, you get a
ConcurrentModificationException. - Always iterate a snapshot when observers might unsubscribe in response to an event.
07
Section Seven · Watch Out
Common Mistakes
Mistake #1 — Memory leak from forgotten subscriptions: An observer subscribes but never unsubscribes. The subject holds a strong reference to it, preventing garbage collection even if the observer is no longer needed. In long-running systems (servers, desktop apps), this is the classic “lapsed listener” memory leak. Fix: Always pair
subscribe() with unsubscribe() in a lifecycle callback (e.g. onClose(), dispose()). Or use WeakReference<Observer> so the GC can reclaim unused observers.
✗ Wrong — observer leaks
// ✗ Chart subscribes but never unsubscribes — leaked forever void openChart() {
ChartWidget chart = new ChartWidget();
feed.subscribe(chart);
// user closes chart window... but chart is still in the list
}
✔ Correct — unsubscribe on close
// ✓ Unsubscribe when the observer is no longer needed void openChart() {
ChartWidget chart = new ChartWidget();
feed.subscribe(chart);
chart.onClose(() -> feed.unsubscribe(chart));
}
Mistake #2 — Modifying the observer list during iteration:
- If an observer calls
unsubscribe(this)inside its ownupdate(), and the subject iterates the original list, you get aConcurrentModificationException. - Fix: Iterate a snapshot:
for (Observer o : new ArrayList<>(observers)), or useCopyOnWriteArrayList.
Mistake #3 — Notifying in an inconsistent state:
- If the subject fires
notifyObservers()in the middle of a multi-step state change, observers see a half-updated state. - Fix: Complete all state changes before calling
notifyObservers(). Set all fields first, then notify once.
Mistake #4 — Heavy work inside
update(): - If an observer does expensive I/O (database write, HTTP call) inside
update(), it blocks all subsequent observers. - The subject’s
setPrice()hangs until the slowest observer finishes. - Fix: Keep
update()lightweight — enqueue work to a background thread, or use an async Observer pattern.
08
Section Eight · Decision Guide
When To Use Observer
Use Observer When
- A change in one object must trigger updates in multiple other objects, and you don’t know how many or which ones at compile time
- You need loose coupling — the subject should not depend on the concrete observer classes
- Observers need to subscribe and unsubscribe at runtime (e.g. UI widgets opening and closing)
- You are building an event-driven system — GUI events, message queues, reactive streams, webhooks
- You want to follow the Open/Closed Principle — add new observers without modifying the subject
Avoid Observer When
- There is only one dependent — a direct method call is simpler than setting up subscribe/notify machinery
- Observer ordering matters — Observer doesn’t guarantee notification order; use Chain of Responsibility or a pipeline instead
- You need bidirectional communication — if objects need to talk to each other (not just listen), use Mediator
- Notifications cascade — Observer A updates, which triggers Observer B, which triggers Observer A again — infinite loop; restructure with Mediator or event bus with deduplication
Observer vs. Confused Patterns
| Pattern | Communication | Coupling | When to pick it |
|---|---|---|---|
| Observer ← this | One-to-many broadcast | Subject → Observer interface only | Fan-out notifications: one event, many listeners |
| Mediator | Many-to-many via hub | All objects → Mediator | Complex inter-object communication (chat rooms, UI forms) |
| Command | Request encapsulated as object | Invoker → Command interface | Undo/redo, queuing, logging requests |
| Chain of Responsibility | One request, one handler in a chain | Handler → next Handler | Request must be handled by exactly one of many handlers |
Decision Flowchart
09
Section Nine · Practice
Problems To Solve
Observer problems test whether you can decouple a subject from its dependents, manage subscribe/unsubscribe lifecycles, and handle edge cases like notification ordering and concurrent modification.
| Difficulty | Problem | Key Insight |
|---|---|---|
| Easy | Weather Station Build a WeatherStation subject that holds temperature, humidity, and pressure. Three displays subscribe: CurrentConditions, Statistics (running average), and Forecast (rising/falling pressure). When setMeasurements() is called, all displays update. | Tests the basic subscribe/notify loop. The interesting part: Statistics must maintain state across updates (running average), proving that each observer can have its own internal logic. Use push model — pass all 3 values in update(). |
| Medium | Event Bus with Topic Filtering Build an EventBus where observers subscribe to specific topics (e.g. "order.created", "order.shipped") instead of receiving all events. Publishing an event with topic "order.created" notifies only subscribers of that topic. | The subject holds a Map<String, List<Observer>> instead of a flat list. subscribe(topic, observer) registers per-topic. publish(topic, data) notifies only matching observers. This is how real event buses (Guava EventBus, Spring ApplicationEvent) work under the hood. |
| Medium | Reactive Spreadsheet Cell Build a spreadsheet where cells observe other cells. Cell A1 holds a value. Cell B1 = A1 * 2. Cell C1 = A1 + B1. When A1 changes, B1 recalculates, which triggers C1 to recalculate. Prevent infinite loops if cells form a cycle. | Tests cascading notifications. Each cell is both a subject (notifies dependents) and an observer (recalculates when dependencies change). The hard part: cycle detection. Use a “dirty” flag or topological sort to prevent infinite re-evaluation. |
| Hard | Thread-Safe Observer with Backpressure Build a multi-threaded stock feed where prices arrive on a producer thread and observers run on consumer threads. If an observer is slow, the subject must not block. Implement request(n) backpressure: an observer tells the subject how many updates it can handle. | Tests async Observer + reactive streams. Use ConcurrentLinkedQueue or BlockingQueue per observer. The subject enqueues updates; each observer dequeues at its own pace. request(n) controls queue depth. This is exactly java.util.concurrent.Flow — implementing it from scratch teaches the reactive streams spec. |
Interview Tip:
- When asked about Observer, the interviewer wants to see: (1) a
Subjectwithsubscribe(),unsubscribe(), andnotifyObservers(); (2) anObserverinterface withupdate(); (3) loose coupling — the subject depends only on the observer interface; (4) runtime flexibility — observers come and go dynamically. - Stand-out answers mention:
ConcurrentModificationExceptionduring notification (iterate a copy), memory leaks from lapsed listeners, the push vs. pull tradeoff, and howjava.util.Observablewas deprecated in favor ofFlow.Publisher.