This lesson follows Memento. It also connects to the event coordination in Mediator.

Observer defines a subscription mechanism so a publisher can notify several interested objects. Subscribers can join and leave. The publisher depends on their notification contract. The cost is managing connections and the work triggered by an event.

Notify interested listeners

An editor updates a preview and an audit panel when text changes. Hard-coding both panels into the editor couples core editing to optional features. A subscriber list lets the client decide which features observe the editor.

type Changed = Readonly<{ text: string }>;
type Listener = (event: Changed) => void;
class ChangePublisher {
  private listeners = new Set<Listener>();
  subscribe(listener: Listener): () => void {
    this.listeners.add(listener);
    return () => { this.listeners.delete(listener); };
  }
  publish(text: string): void {
    const event = Object.freeze({ text });
    const recipients = [...this.listeners];
    for (const listener of recipients) listener(event);
  }
}

const changes = new ChangePublisher();
const unsubscribe = changes.subscribe(event => {
  console.log("preview:", event.text);
});
changes.publish("draft");
unsubscribe();
changes.publish("revised"); // preview no longer receives events

This implementation calls listeners synchronously in registration order. Re-registering the same function is deduplicated by Set. It snapshots recipients at publish start, so changes to subscriptions apply to the next event. Other implementations can choose different rules. State them.

Change the subscription list

Define delivery instead of assuming it

Decision	Why it matters
Synchronous or asynchronous	decides whether publisher work waits for listener work
Order and reentrant publication	prevents hidden dependencies and notification loops
Unsubscribe during an event	decides whether an already captured recipient still runs
Failure and cleanup	decides who misses a notification and what stays retained

An event broker can implement a wider publish-subscribe design, but a broker adds its own delivery guarantees. Mediator owns cooperation policy. Observer owns the changing notification links. They can work together.

Map the roles

Role	In this example	Job
Publisher	ChangePublisher	Issues events when its state changes or it performs some behavior. Holds the subscription list and lets subscribers join and leave.
Subscriber	the Listener function type	Declares the notification interface. Usually one update method, or here one callback, with parameters for event details.
Concrete subscribers	the preview and audit callbacks	React to notifications. They all follow the same interface, so the publisher is not coupled to their classes.
Client	the code that calls subscribe()	Creates publishers and subscribers separately, then registers subscribers for updates

Reach for it when a change must reach an open-ended set of objects

• a change to one object's state may require changing other objects, and that set of objects is unknown in advance or changes at runtime. Graphical interfaces hit this constantly. A custom button class must let clients hook their own code to its click event without knowing that code ahead of time.
• some objects must observe others, but only for a limited time or in specific cases. The subscription list is dynamic, so subscribers can join and leave whenever they need to.

Implement it in seven steps

Refactor existing code toward the pattern in this order:

1. Split your business logic in two: the core functionality, independent of other code, becomes the publisher, and the rest becomes subscriber classes.
2. Declare the subscriber interface. At minimum it declares a single update method.
3. Declare the publisher interface with methods to add and remove subscribers. Publishers must work with subscribers only through the subscriber interface.
4. Decide where the real subscription list and the subscribe methods live. Usually they go in an abstract class that concrete publishers extend. For an existing class hierarchy, use composition instead: put the subscription logic in a separate object that every real publisher uses, as ChangePublisher does here.
5. Create the concrete publishers. Each time something important happens, a publisher notifies all its subscribers.
6. Implement the notification method in the concrete subscribers. Most need context data, which the publisher can pass as an argument. Alternatively, the publisher passes itself and the subscriber reads what it needs. A less flexible option links a subscriber to one publisher permanently through its constructor.
7. Have the client create all the subscribers and register them with the right publishers.

Name what it costs

You gain	You pay
New subscriber classes without changing the publisher, and new publishers too if there is a publisher interface (open/closed)	Subscribers are notified in an order the design does not guarantee
Relations between objects can be set up at runtime	Callbacks create indirect dependencies that are hard to trace
Features connect only while they need updates	A forgotten unsubscribe keeps work and memory alive
One event can trigger multiple reactions	Failures and cascades of notifications need rules

Do not confuse it with its neighbors

Pattern	How it relates
Chain of Responsibility, Command, Mediator	All four connect senders and receivers differently. Observer lets receivers dynamically subscribe to and unsubscribe from receiving requests.
Mediator	Mediator removes mutual dependencies among components, which all depend on one mediator. Observer builds dynamic one-way connections, where some objects act as subordinates of others. A common Mediator implementation uses Observer: the mediator publishes, and components subscribe.

Retrieve and apply

State the delivery and cleanup rules for one observer in an application. Continue to State for behavior that changes with an object's lifecycle.