Pattern observation

SVG plug-in required to display this diagram

Description This pattern implements the observes relationship as the separate abstract asset AbstractObservation. The observe operation causes assets of this type to register with the observable. The observable will use the tell operation to notify the AbstractObservation asset about state changes. The AbstractObservation asset will in turn notify all AbstractObserver assets that have registered with it via operation dispatch. The concrete assets Observable, Observation, and Observer, inherit their features from their abstract counterparts and must be bound to actual model assets when applying this pattern to a model.
Default Namespace
Namespace Prefixes o=
Scope Definitions {none}
Default Type System {none}
Type System Prefixes {none}
Default Constraint Language {none}
Constraint Language Prefixes {none}
Default Operation Vocabulary ##local
Operation Vocabulary Prefixes {none}
Design Patterns {none}
Included Models {none}

Pattern Info

Category generic/oo
Keywords event
Alias names PublishSubscribe
Purpose The purpose of this pattern is to establish an n-ary 1..n relationship between entities so that a state change within the one entity leads to the notification and update of the depending entities.

Synchronizing a system of interacting entities can lead to unmanageable systems when this synchronization is implemented in a tightly coupled way: It also will inhibit re-use. However, synchronization between entities is a common problem.

The Observer pattern describes how this relationship can be established. All observers are notified when the Observable changes its state. The observers can then update their state.

Applicability Use this pattern in the following situations:
  • If an abstraction has two interdependent aspects. Encapsulating these aspects into separate assets allows you to modify them and to reuse them.
  • If changes in one entity cause changes in an unknown number of other entities
  • If an entity needs to notify an audience of other entities about state changes but the audience is not known upfront and may change over time.

This pattern allows you to vary observables and observers independently from each other. You may also re-use the observable without its observers, and vice versa.

Both observers and observables are only loosely coupled. All that the observable knows, is that it is observed, even the observers (and the concrete observation type) are unknown to the observable. All what the observation knows is that there is abstract observable and abstract observers, the concrete assets are not known to the observation. Notifications issued by the observable are automatically broadcast to all observers that have registered with the observation.

Since the observable does not know its obsevers, it is also ignorant about the costs of updating and about possible notification avalanches. Badly managed observation relationships can lead to unnecessary and unwanted notifications. Since the notification does not include details about the nature of the state change, observers may find it difficult to find out what has actually changed.

Known Applications
  • Model/View/Controller (MVC) concept.
  • Other class libraries for user interfaces.
Related Patterns {none}
Level 2 Structures o:AbstractObservation
Assets {none}
Annotations {none}
Errors {none}
Warnings {none}
Infos {none}
Status Pattern contains 0 errors, 0 warnings, and 0 infos

Graphics Index