Observer pattern

The pattern separates a state-producing object from the objects that react to its changes. A subject exposes operations for attaching and detaching observers and sends a notification when relevant state changes; each observer implements an update operation or an equivalent callback. The classic formulation appears among the behavioral patterns catalogued by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.¹

Notifications can carry the new value, a change description, or only an indication that the observer should query the subject. The last arrangement, sometimes called a pull model, keeps event payloads small but gives observers more responsibility. A push model supplies data directly and can reduce follow-up queries. In either form, the subject generally depends on an observer interface rather than on concrete observer classes.

The pattern is commonly implemented through interfaces, callbacks, event members, or framework-specific dispatch objects. In Java, the older Observable and Observer APIs embodied the idea but were deprecated because of design limitations; application code commonly uses more explicit interfaces or event libraries instead.² In .NET, events provide a conventional publisher-subscriber mechanism in which a publisher raises an event and handlers receive it.³

Typical uses include updating graphical views when a model changes, refreshing caches, recording audit information, propagating configuration changes, and coordinating components in user interfaces. Frameworks often provide richer variants: Qt's signals and slots support type-checked connections and queued delivery across threads, while Apple's NotificationCenter offers named notifications within an application process.⁴⁵

The pattern improves extensibility because new observers can be added without changing the subject, but it shifts complexity into notification management. A subject may not know which observers are expensive, reentrant, or faulty, and a long observer chain can make control flow difficult to trace. Synchronous delivery means the subject may be blocked by an observer; asynchronous delivery avoids that coupling at the cost of queues, scheduling, and less immediate consistency.

Lifecycle management is a central engineering issue. An observer that remains registered after it is no longer needed can cause memory retention, duplicate reactions, or attempts to update a destroyed object. Implementations therefore use explicit unsubscribe operations, scoped connections, weak references, or ownership-aware registration. Ordering should be specified only when required: relying on incidental registration order makes behavior fragile. Thread safety, exception handling, event coalescing, and whether notifications represent every intermediate state or only the latest state also require deliberate contracts.

The Observer pattern does not require a separate observer interface or even object-oriented inheritance; a function, closure, signal, or event handler can serve as the observer. This makes the pattern a conceptual relationship rather than a fixed class diagram. Modern reactive libraries extend the same idea into observable sequences, where observers receive a stream of values plus explicit completion or error signals.

Several edge cases distinguish a robust implementation from a simple notification list. A subject may snapshot its registrations before notifying so that an observer can safely unsubscribe during delivery. It may batch or coalesce changes to prevent notification storms, especially in interfaces and telemetry systems. Distributed publish-subscribe systems resemble the pattern but add brokers, serialization, delivery guarantees, and network failure; they should not be treated as merely remote method calls. The pattern's original strength remains local decoupling, not guaranteed reliability or transactional consistency.

Subject

The state-holding or event-producing object that manages observer registrations and issues notifications.

Observer

A dependent object, callback, or handler that receives notification and reacts to a subject's change.

Push model

A notification style in which the subject sends changed data or event details directly to observers.

Pull model

A notification style in which observers are told that a change occurred and query the subject for details.

Notification storm

An excessive burst of updates that can consume resources or trigger redundant work.