Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects. You dont 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 dont 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. The 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 theres 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 subjects state.
This pattern has been used on the following systems: Smalltalk Model/View/Controller (MVC). The MVCs Model class plays the role of Subject, while View is the base class for observers. (Krasner, G.E. and S.T. Pope. A cookbook for using the model-view-controller user interface paradigm in Smalltalk-80. Journal of Object-Oriented Programming, 1(3):26-49, August/September 1988.) ET++ puts Subject and Observer interfaces in the parent class for all other classes in the system, thus providing a general dependency mechanism. (Weinand, A., E. Gamma, and R. Marty. ET++--An object-oriented application framework in C++. In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pp. 46-57, San Diego, CA, September 1988. ACM Press.) THINK class library put Subject and Observer interfaces in the parent class for all other classes in the system, thus providing a general dependency mechanism. (Symantec Corporation, Cupertino, CA. THINK Class Library Guide, 1993.) The InterViews user interface toolkit defines Observer and Observable (for subjects) classes explicitly. (Linton, M.A., J.M. Vlissides, and P.R. Calder. Composing user interfaces with InterViews. Computer, 22(2):8-22, February 1989.) Unidraw splits graphical editor objects into View (for observers) and Subject parts. (Vlissides, J.M., M.A. Linton. Unidraw: A framework for building domain-specific graphical editors. ACM Transactions on Information Systems, 8(3):237-268, July 1990.)
Mediator and Singleton patterns
notification, Singleton pattern, Mediator pattern, Observer pattern, behavioral patterns, Dependants pattern, object composition, state, communication (distributed), object (one-to-many dependency), synchronize object state
any system requiring synchronizing object state across loosely coupled objectswindowing systems
need to provide abstraction between subsystem and clientneed to reduce the coupling of objectsneed to synchronize the state of cooperating componentsthe number and identities of the cooperating components is not known, nor static
provides support for broadcast communicationprovides weak coupling between clients and subsystems
observers are unaware of each other - causing problems changing state of the subject
Test driver Test.javaSimple implementation of the pattern - Subject class. Subject.javaSimple implementation of the pattern - Observer class. Observer.javaSimple implementation of the pattern - ConcreteSubject class. ConcreteSubject.javaSimple implementation of the pattern - ConcreteObserver class. ConcreteObserver.javaTest driver testobserver.cppSimple implementation of the pattern. observer.h