Observer

The two roles

Observer has exactly two participants, connected by one tiny interface:

• Subject (the channel) — owns the state everyone cares about and a private list of observers. It exposes three doors: subscribe(observer) adds to the list, unsubscribe(observer) removes from it, and notify() — usually called internally right after state changes — walks the list and calls each observer.
• Observer (the subscriber) — anyone who implements one small interface with a single method: update(...). That method is literally the subject calling you back. Concrete observers (a viewer, a UI panel, a logger) each do their own thing inside it.
• The one-to-many trick — the subject stores observers by interface only. It can notify a viewer, a chart, and an email sender without knowing any of those classes exist. New observer types plug in without a single line changing in the subject.

interface Subscriber {
  update(video: string): void;          // the channel calls THIS
}

class Channel {
  private subscribers: Subscriber[] = [];   // the one-to-many list

  subscribe(s: Subscriber)   { this.subscribers.push(s); }               // 🔔
  unsubscribe(s: Subscriber) { this.subscribers = this.subscribers.filter(x => x !== s); } // 🔕

  upload(title: string) {
    // 1. the subject's state changes...
    for (const s of this.subscribers) {  // 2. ...so it walks its list
      s.update(title);                   // 3. and pushes the news to each one
    }
  }
}

That for loop inside upload() is the entire engine. The channel never asks who is on the list or what they'll do with the news — it fires update() at each entry and moves on. Subscribe four viewers and the loop runs four times; unsubscribe three of them and the very next upload notifies exactly one. The set of listeners is a runtime decision, not a compile-time one.

No more polling

The alternative to Observer is polling: every dependent repeatedly asks the subject "changed yet? changed yet?" on a timer. That's how you'd check a channel with no subscribe button — reload the page every minute. Polling wastes work when nothing changed and reacts late when something did (up to one full interval late). Observer inverts the direction: dependents register once, then the subject pushes at the exact moment of change. Zero wasted checks, zero built-in lag.

Push vs pull: what does update() carry?

• Push style — the subject sends the data along: update(video). The observer gets everything it needs in the call. Simple and fast, but the subject has to guess what every observer wants, and may end up shipping data most of them ignore.
• Pull style — the subject sends only "something changed", typically passing itself: update(this). Each observer then reads exactly the state it cares about off the subject. More flexible when observers need different slices of state, at the cost of an extra round trip and a tighter grip on the subject.

Where you meet it in the wild

• DOM events — addEventListener / removeEventListener are subscribe/unsubscribe on a subject (the element).
• React and friends — state changes notify the framework, which re-renders the dependent UI. Model→view data binding in MVC/MVVM is the original GoF motivation.
• RxJS / reactive streams — Observables generalise the pattern into composable event pipelines.
• Webhooks — the same idea across the network: you register a URL with a service (subscribe), it POSTs to you when something happens (notify).

Observer vs pub/sub — close cousins, not twins

In Observer, the subject holds the list itself and calls its observers directly — the two sides share at least the update() interface and the observer knows which subject it signed up with. Pub/sub adds a broker in the middle (an event bus or message queue): publishers emit to the broker, subscribers register with the broker, and the two sides never know each other exists — not even by interface — and can even live in different processes. If you find yourself building a middleman object whose whole job is deciding who talks to whom, you're heading toward [[mediator]].

Reach for Observer when...

• One object's changes must reach a varying set of dependents — you can't hard-code the receivers because they come and go at runtime (viewers subscribing, panels opening and closing, plugins registering).
• You're building event-driven UI — clicks, keystrokes, model-changed-so-redraw-the-view. Virtually every UI framework is Observer at its core.
• You want the producer decoupled from its consumers — the subject ships one notify(), and brand-new consumer types plug in later without touching the subject's code.

Skip it when...

• There's exactly one fixed, known dependent — just call it directly. A subscription list for a single permanent listener is ceremony with no payoff.
• Update cascades are getting hard to follow — when observers mutate state that notifies other observers, control flow turns into invisible spaghetti. Centralise the choreography in a [[mediator]] or an explicit event bus instead.
• Strict ordering or transactional delivery matters — plain Observer promises neither; if receivers must run in a fixed order or all-or-nothing, you need a more explicit orchestration.