gof-observer

One-line summary

Define a one-to-many dependency: when one object (the subject) changes state, all its dependents (observers) are notified automatically — without the subject knowing their concrete types.

When to use this skill

• One object holds canonical state and several others must stay synchronized with it (data → multiple views, model → multiple listeners).
• Event-style coupling: "when X happens, do these N things, and the list of things grows over time".
• Decoupling a publisher from a set of subscribers that the publisher should not know about.

When NOT to use this skill

• Only one downstream consumer exists — a direct call is simpler.
• The "notification" must be synchronous and block the subject's progress until subscribers complete — Observer's typical implementation is push-style and assumes subscribers are independent.
• You need event sourcing, replay, or persistence — that's a real event bus / message broker, not the in-process Observer pattern.

Core content

The subject knows only a notify() method on an Observer interface. Concrete observers register and deregister via attach() / detach(). When the subject's state changes, it iterates its observer list and calls notify() on each.