From HaFrWiki
Jump to: navigation, search

<<Back to Patterns

This article is fully based on Gamma's Design Patterns, Elements of Reusable Object-Oriented Software [1].


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


A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects. You don't want to achieve consistency by making the classes tightly coupled, because that reduces their reusability.

For example, many graphical user interface toolkits separate the presentational aspects of the user interface from the underlying application data. Classes defining application data and presentations can be reused independently. They can work together, too. Both a spreadsheet object and bar chart object can depict information in the same application data object using different presentations. The spreadsheet and the bar chart don't know about each other, thereby letting you reuse only the one you need. But they behave as though they do. When the user changes the information in the spreadsheet, the bar chart reflects the changes immediately, and vice versa.


This behavior implies that the spreadsheet and bar chart are dependent on the data object and therefore should be notified of any change in its state. And there's no reason to limit the number of dependent objects to two; there may be any number of different user interfaces to the same data.

The Observer pattern describes how to establish these relationships. The key objects in this pattern are subject and observer. A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change in state. In response, each observer will query the subject to synchronize its state with the subject's state.

This kind of interaction is also known as publish-subscribe. The subject is the publisher of notifications. It sends out these notifications without having to know who its observers are. Any number of observers can subscribe to receive notifications.


Use the Observer pattern in any of the following situations:

  • 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.



Subject Observer ConcreteSubject ConcreteObserver
  • knows its observers. Any number of Observer objects may observe a subject.
  • provides an interface for attaching and detaching Observer objects.
  • defines an updating interface for objects that should be notified of changes in a subject.
  • stores state of interest to ConcreteObserver objects.
  • sends a notification to its observers when its state changes.
  • 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.




The Observer pattern lets you vary subjects and observers independently. You can reuse subjects without reusing their observers, and vice versa. It lets you add observers without modifying the subject or other observers. Further benefits and liabilities of the Observer pattern include the following:

  • 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 theconcrete 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.
  • Unexpected updates. Because observers have no knowledge of each other's presence, they can be blind to the ultimate cost of changing the subject. A seemingly innocuous operation on the subject may cause a cascade of updates to observers and their dependent objects. Moreover, dependency criteria that aren't well-defined or maintained usually lead to spurious updates, which can be hard to track down.

Know Usage[edit]

The first and perhaps best-known example of the Observer pattern appears in Smalltalk Model/View/Controller (MVC), the user interface framework in the Smalltalk environment.

Related Patterns[edit]

  • Mediator, By encapsulating complex update semantics, the ChangeManager acts as mediator between subjects and observers.
  • Singleton, The ChangeManager may use the Singleton pattern to make it unique and globally accessible.

See also[edit]




  1. Design Pattern, Elements of Reusable Object-Oriented Software, Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides, First Published: October 21, 1994