# Observer

- Purpose
- Structure
- Interaction
- Applications
- Consequences

## Purpose

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

## Structure

- Subject : knows its observers. Any number of Observer objects may observe a subject. provides an interface for attaching and detaching Observer objects.
- Observer : defines an updating interface for objects that should be notified of changes in a subject.
- ConcreteSubject : stores state of interest to ConcreteObserver objects.
- ConcreteObserver : maintains a reference to a ConcreteSubject object. stores state that should stay consistent with the subject's. implements the Observer updating interface to keep its state consistent with the subject's.

## Interaction

1. ConcreteSubject notifies its observers whenever a change occurs that could make its observers' state inconsistent with its own.
2. After being informed of a change in the concrete subject, a ConcreteObserver object may query the subject for information.
3. ConcreteObserver uses this information to reconcile its state with that of the subject.

## Applications

- When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.
- When a change to one object requires changing others, and you don't know how many objects need to be changed.
- When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled.

## Consequences

- Abstract coupling between Subject and Observer. All a subject knows is that it has a list of observers, each conforming to the simple interface of the abstract Observer class. The subject doesn't know the concrete class of any observer. Thus the coupling between subjects and observers is abstract and minimal. Because Subject and Observer aren't tightly coupled, they can belong to different layers of abstraction in a system. A lower-level subject can communicate and inform a higher-level observer, thereby keeping the system's layering intact. If Subject and Observer are lumped together, then the resulting object must either span two layers (and violate the layering), or it must be forced to live in one layer or the other (which might compromise the layering abstraction).
- Support for broadcast communication. Unlike an ordinary request, the notification that a subject sends needn't specify its receiver. The notification is broadcast automatically to all interested objects that subscribed to it. The subject doesn't care how many interested objects exist; its only responsibility is to notify its observers. This gives you the freedom to add and remove observers at any time. It's up to the observer to handle or ignore a notification.