Page 207 -

190 Chapter 7 Design and implementation

Pattern name: Observer
Description: Separates the display of the state of an object from the object itself and allows alternative displays
to be provided. When the object state changes, all displays are automatically notified and updated to reflect
the change.
Problem description: In many situations, you have to provide multiple displays of state information,
such as a graphical display and a tabular display. Not all of these may be known when the information is
specified. All alternative presentations should support interaction and, when the state is changed, all displays
must be updated.
This pattern may be used in all situations where more than one display format for state information is
required and where it is not necessary for the object that maintains the state information to know about the
specific display formats used.
Solution description: This involves two abstract objects, Subject and Observer, and two concrete objects,
ConcreteSubject and ConcreteObject, which inherit the attributes of the related abstract objects. The abstract
objects include general operations that are applicable in all situations. The state to be displayed is
maintained in ConcreteSubject, which inherits operations from Subject allowing it to add and remove
Observers (each observer corresponds to a display) and to issue a notification when the state has changed.
The ConcreteObserver maintains a copy of the state of ConcreteSubject and implements the Update()
interface of Observer that allows these copies to be kept in step. The ConcreteObserver automatically
displays the state and reflects changes whenever the state is updated.
The UML model of the pattern is shown in Figure 7.12.
Consequences: The subject only knows the abstract Observer and does not know details of the concrete class.
Therefore there is minimal coupling between these objects. Because of this lack of knowledge, optimizations
that enhance display performance are impractical. Changes to the subject may cause a set of linked updates
to observers to be generated, some of which may not be necessary.

different settings. The pattern is not a detailed specification. Rather, you can think of it
Figure 7.10 The
Observer pattern as a description of accumulated wisdom and experience, a well-tried solution to a com-
mon problem.
A quote from the Hillside Group web site (http://hillside.net), which is dedicated
to maintaining information about patterns, encapsulates their role in reuse:

Patterns and Pattern Languages are ways to describe best practices, good
designs, and capture experience in a way that it is possible for others to reuse
this experience.

Patterns have made a huge impact on object-oriented software design. As well as
being tested solutions to common problems, they have become a vocabulary for talk-
ing about a design. You can therefore explain your design by describing the patterns
that you have used. This is particularly true for the best-known design patterns that
were originally described by the ‘Gang of Four’ in their patterns book, (Gamma et al.,
1995). Other particularly important pattern descriptions are those published in a series
of books by authors from Siemens, a large European technology company
(Buschmann et al., 1996; Buschmann et al., 2007a; Buschmann et al., 2007b; Kircher
and Jain, 2004; Schmidt et al., 2000).
Design patterns are usually associated with object-oriented design. Published
patterns often rely on object characteristics such as inheritance and polymorphism to
provide generality. However, the general principle of encapsulating experience in a