A Pattern Language appeared in 1977. Alexander and his collaborators collected 253 patterns spanning towns, buildings, and construction, with the aim of helping people shape their own environments.[1] The Timeless Way of Building followed in 1979 and developed the underlying theory.[2]

A pattern connects a recurring problem with a solution that makes sense under particular constraints. A pattern language adds relationships: one design decision creates the context for others.[3]

For our dashboard, start with the user’s task: compare the same sales data in a table and a chart. The important tension is shared information with independently changing views. That is a problem description you can carry between implementations.

Kent Beck and Ward Cunningham’s 1987 paper, Using Pattern Languages for Object-Oriented Programs, documented an early adaptation. Its five window-interface patterns included Window Per Task and Few Panes Per Window. Their order guided decisions from the overall task down to panes and actions.[3]

Viewed through that lens, your dashboard’s table and chart belong together because they support one task. You decide how the person uses the window before deciding how its objects communicate.

Your table and chart can register with the data model, receive updates, and unregister when no longer needed. The model can work through a common update contract instead of knowing each view’s rendering details. Norvig later used a closely related spreadsheet-and-bar-chart example to explain Observer.[9]

For a fixed two-view screen, direct calls may be enough. Registration becomes useful when views come and go. Either way, decide what happens when a view closes or its update fails. Naming Observer helps you discuss that responsibility; it does not implement the policy.

The Hillside Group grew from a 1993 gathering. The first Pattern Languages of Programs conference took place in 1994 near Monticello, Illinois.[5] In March 1995, Cunningham opened the collaborative People, Projects & Patterns area of the Portland Pattern Repository, part of the early WikiWikiWeb story.[6]

For your dashboard, a useful pattern account would explain why views subscribe, how they detach, and what failures cost. Another developer can then challenge the assumptions instead of copying an unexplained diagram.

Pattern-Oriented Software Architecture began in 1996, spanning architecture, design patterns, and implementation idioms.[12] Martin Fowler’s Patterns of Enterprise Application Architecture followed in 2002, addressing concerns such as domain logic and persistence.[7] Gregor Hohpe and Bobby Woolf’s Enterprise Integration Patterns documented 65 messaging patterns in 2003.[8]

Now move the dashboard’s chart into another service. A publish-subscribe channel offers a related one-to-many communication structure, but you must also choose delivery, retry, and failure behavior.[8] Replacing local calls with messages changes the engineering problem.

Do not mistake later popularity for invention. Garcia-Molina and Salem’s 1987 Sagas work already described splitting long transactions and using compensating transactions after partial execution.[10] The histories overlap; they are not a single ladder from GoF to microservices.

In his 1996 talk, Peter Norvig argued that 16 of the 23 GoF patterns had substantially simpler implementations in Lisp or Dylan than in C++, for at least some uses. His slides described them as “invisible or simpler.” This was a qualified language comparison, not a universal obsolescence score.[9]

Here is an illustrative JavaScript notification core for our dashboard. A view supplies a function rather than an instance of an observer class. The returned function lets that view unsubscribe.

const subscribers = new Set();

function subscribe(updateView) {
  subscribers.add(updateView);
  return () => subscribers.delete(updateView);
}

function publish(snapshot) {
  for (const updateView of [...subscribers]) {
    updateView(snapshot);
  }
}

This example chooses synchronous dispatch over a snapshot of the subscriber list. If a callback throws, later callbacks are not called. Removing a callback during dispatch does not remove it from that already-copied list. Those are concrete semantics you must accept or change.

The example is our adaptation, not Norvig’s implementation. His Observer example uses method combination. The general lesson is to examine what your language can express before reproducing an older class structure.[9]

Updating the dashboard after a notification does not imply Event Sourcing. Making an event history authoritative is a separate decision. CQRS separates read and write models and can be used without events.[11] These names should narrow the discussion, not merge distinct choices.