330 | Chapter 8: Observer Pattern
Summary
The real test for a design pattern is its flexibility. As you saw in the examples in this
chapter, very little was changed in theSubjectorObserverclasses. When the task of
a design pattern is to distribute state changes to a number of different subscribed
observers, you can see that many different kinds of specific applications can use this
pattern. Because of this feature, its flexibility, and relative simplicity, the Observer
design pattern is seen in many different applications.
Equally important, the Observer shows how to program to an interface and not an
implementation. Example 8-1 and Example 8-11 clearly illustrate this process. Each
concrete observer is typed as the supertype (interface)Observer. However, also note
that in some cases where the Observer pattern is put to work, you can’t type an
implementation to a supertype, as you may have noted in Example 8-19. This
doesn’t mean that the example’s invalid; it simply shows that in some designs using
the Observer, when you attempt to program to the interface, you run into problems
because of the characteristics of the interface and its implementation. As a result,
such cases require you to create instances by typing them as implementations.
When thinking about where you can use the Observer pattern, consider situations
where you have some key states that must be sent to different instances. The most
useful implementation is where the exact same information needs to be sent to differ-
ent data display or interpretations. In this way, the application ensures that the exact
same state information is sent without having to generate separate data sources.