Observer

The Observer design pattern is used when one object needs to observe the state of another. Whenever the state of the observed object (subject) changes, all depending objects (observer) are notified and updated automatically. Therefore the subject should know about all its dependent observers and keep a list of them. The subject has a one-to-many dependency to all observers. Each observer must register with the subject in order to be notified when the subject's state changes.

Typical Usage

• When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects allows the programmer to vary and reuse them independently.
• When a change to one object requires changing others and it is not known in advance how many objects need to be changed.
• When an object should be able to notify others but shouldn't know anything about them

One or more than one component display in a graphical way the state of an object. Changes the state of the object, all components need to be informed. All components know about the object but the object should stay independent from the components. Therefore it should be a loose coupling. In this case you would use the observer pattern.

Example: Results of a measurement are illustrated in a bar chart, line chart and in a table. The measured values are permantly changing. The components should always display those changes but the measured object itself shouldn't need to know anything about the structure of those components.

Structure

From the Gang of Four Book:

Participant Classes

Subject

This abstract class provides an interface for attaching and detaching observer objects and notifying those.

• registerObserver(): adds new observer to the list of observers
• removeObserver(): removes a certain observer from the list of observers
• notifyObserver(): notifies each observer that the state of the subject changed by going through the list of observers

ConcreteSubject

This class returns its own state whenever asked by the observer objects. It also calls up its superclass' notifyObserver() function

• getState(): returns the state of the subject

Observer

This class defines an update interface for all observer objects.

• update(): abstract method.

ConcreteObserver

This class maintains a reference to the observing subject.

• update(): When this function is called by the subject, the observer calls the getState() function to update its information about the subject's state

Recognising the pattern

Classes: Observer, multiple ConcreteObservers, Subject, ConcreteSubject.

• Observer class that implments java.util.Observer in Java.
• Subject class that extends java.util.Observable in Java.

OR

• addObserver(Observer) and removeObserver(Observer) methods in Subject.
• notifyAll() method in Subject.
• abstract update() method in Observer.

Consequences

• Loose coupling between a subject and its observers because a subject doesn't know the concrete classes of its observers.
• One subject can be observed by any number of observers.
• Using the observer pattern can lead to unexpected updates since observers have no knowledge about what other objects are observing the subject so they have no way of knowing what updates will be triggered when the subject changes.

Related Patterns

• Mediator: Observer can facilitate communication between mediator colleagues and the mediator object.
• Singleton: When a change manager is used to facilitate the communication between the subject and its observers, only one instance of the change manager is usually needed so it can be implemented using the Singleton pattern.

See also

• Model-View-Controller
• Java Swing