Observer pattern
The Observer pattern (English observer pattern, also listener pattern ) is a design pattern in the field of software development. It belongs to the category of behavior ( behavioral patterns ) and underpins the transmission of changes to an object dependent on this object structures. The pattern is one of the so-called GoF patterns ( Gang of Four, see Gang of Four ).
This design pattern is also known under the name of publish- subscribe, freely translated " publish and subscribe ".
In addition to publish- subscribe the observer pattern experiences with the signal - slot concept another expression.
- 2.1 actors
Use
Common use situations
General find observer pattern applies when an abstraction has several aspects that depend on another aspect of the same abstraction, the change of an object implies changes to other objects by himself or an object to notify other objects without having to know these in detail.
Example of use
One or more components also provide the status of an object graphically Represent know the entire interface of the object. If the state of the object, the components must be informed about it. On the other hand, should the object but remain independent of the components, so do not know their interface.
Example: Measurement results are displayed simultaneously in a bar chart, a line chart and a table. Measured values are constantly changing. The components of the diagrams to represent these changes permanent, but the measured object is intended to no knowledge of the structure of these components possess.
Solution
The observed object provides a mechanism to observers and to report to inform them of changes. It knows all his observers only on the ( manageable ) interface observers. It reports any change completely non-specifically to each registered observer, so does not need to know the structure of these additional components.
Observers implement itself can be a (specific ) method to react to the change. In general, the relevant parts of the component for a state can be queried.
UML diagram
The following class diagram shows the roles involved in the design pattern. The subject may have multiple observers, which can belong to different concrete classes.
Actors
A subject ( observable object in English publisher, so " poster ", called ) has a list of observers, without knowing its concrete type. It provides an interface for registration and deregistration of observers and an interface to notify observers of changes. A specific subject ( concrete, observable object) stores the relevant state and notifies all observers as conditions change on the updating interface. It has an interface for requests of the current state.
The observer (in English also subscriber, or " Subscriber", called ) define an update interface.
Manage KonkreteBeobachter the reference to a specific subject whose condition they observe and store its state consistent. Implement an update interface using the query interface of the concrete subject.
Benefits
Subjects and observers can be varied independently. Subject and observer are coupled in an abstract and minimal way loose. The observed object needs no knowledge of the structure of its own to an observer, but it knows only the observer interface. A dependent object receives the changes automatically. Multicasts are supported.
Disadvantages
Changes to the object result in a large number of observers to the high cost of change. On the one hand subject each informs the observer, even if it does not need the change information. In addition, the changes may lead to further changes after and so have an unexpectedly high expense.
Gets an observer during the processing of a reported change in turn change the subject methods, as it can lead to infinite loops.
The mechanism does not provide information about what has changed. The resulting independence of the components can, however, also turn out to be an advantage.
In the just -conducted observational state of an object, it may be necessary to guarantee a consistent state subject. This can be ensured by synchronous calls to the Notifizierungsmethode of the observer. In a multithreaded system, possibly locking mechanisms or threads with queuing for the Observer - notification is required.
Related design patterns
A mediator can mediate between subjects and observers.