UML Weekend Crash Course™ - To Parent Directory

134
Saturday Afternoon
designed to help developers communicate common solutions to common problems. In fact,
because communication and problem solving are parts of nearly every occupation, you can
find patterns in almost every discipline of software development. There are analysis level
patterns, business patterns, architectural patterns, and many more, all developed to facilitate
communication about solutions that are used consistently to solve similar recurring
problems in each area of endeavor.
One software design pattern, called the observer design pattern, addresses the problem
where one object needs to know when something happens to another object so that it
can respond immediately to the change. The example in Table 12-2 uses the Order and the
Shipment from the Inventory Control case study to illustrate the pattern. Using the four
elements from Table 12-1 as a guide, Table 12-2 describes how the observer design pattern
allows you to immediately update the Order when the Shipment leaves the building.
Table 12-2
The Observer Design Pattern Example
Pattern Element
A problem to solve
The resources to solve it
The set of rules about how
the resources could be
used to solve the problem
Guidelines to know when
the pattern works well
and when it does not
Element Description for Observer Pattern
The Order needs to be updated to a status of “shipped” when
the Shipment has left the premises. The “shipped” status is the
condition that kicks off the Accounts Receivable and tracking
processes.
The observer pattern identifies two resources, an observer
object and an observable (observed) object. The observable
object is responsible for notifying the observers. This eliminates
the need for the observer to constantly ask the observable
(observed) object what is happening.
The rules for the observer pattern dictate two roles: The
Shipment object that is being observed assumes the role of
the observable object, and the Order takes on the role of the
observer. The Order tells the Shipment object that it wants to
be notified when something happens. The Shipment places the
Order on its list of observers to be notified. When the
Shipment is shipped, the Shipment sends a standard notification
to all the observers in the list. When the Order receives
the notification, it can then respond as it needs to.
The observer pattern can be overused, causing performance
problems that result from the volume of notifications sent to
all observers for every change in the observable object. It
works best when a few very specific immediate responses are
essential to the application, as in a user interface, embedded
application, or automation.