apply-observer-pattern

name	apply-observer-pattern
description	Use when a change in one object must automatically notify and update an open-ended set of dependent objects — without the subject knowing which specific objects depend on it.
source	Gamma, Helm, Johnson, Vlissides, "Design Patterns: Elements of Reusable Object-Oriented Software" (1994) pp. 293–303; Java EventListener; Python asyncio events; React useState/useEffect; RxJS (Reactive Extensions)
tags	["design-patterns","behavioral","observer","oop","developer","event-driven","publish-subscribe","loose-coupling"]
related	["apply-mediator-pattern","apply-event-driven-architecture","apply-solid-principles"]

Apply Observer Pattern

Define a one-to-many dependency between objects so that when one changes state, all its dependents are notified and updated automatically.

Why This Is Best Practice

Adopted by: Java's event model (every EventListener in AWT, Swing, and JavaFX is an Observer — the foundation of all Java UI), Python's asyncio event system, React's hooks model (useState/useEffect — 100M+ npm downloads/week), RxJS (Reactive Extensions — the core of Angular, used in millions of applications), and all publish-subscribe message brokers (Redis Pub/Sub, MQTT). GoF documents that without Observer, the subject must know all its dependents explicitly — coupling that scales as O(M×N) with M subjects and N observers. React's adoption of the Observer model for state updates is cited as the primary reason UI components can re-render independently on state change without centralized routing logic. Polling — the alternative — requires every dependent to periodically check the subject for changes. This wastes CPU and introduces latency. Direct coupling (subject calls each dependent's specific method) requires the subject to know all dependents. Observer decouples both: push notification, open-ended subscriber list.