Intent
The notification pattern is the active object analog of the GOF
Observer pattern. The difference is in the mechanism for communication
between the Subjects and Observers, since all communications between
active objects involve ITC messages.
The biggest difference in the communication comes from the asynchronous
nature of the active object messages contrasted against the very
synchronous nature of function calls. When an active object needs to
send an event, it must obtain sufficient memory for the ITC message.
Indeed, while the request message is being processed by the server,
the client is free to perform other activities.
In keeping with the principles of active object design, the Observer
(client) active object allocates a Notification Request ITC Message and sends
it to the Subject (server), with the understanding that the Subject will
return the ITC message back to the Observer (client) when the server
state changes. The type of state changed is defined as a part of the
interface. Examples include notification upon state change, notification
after a time interval, notification on a threshold crossing, etc.
Commonly, a copy of the expected state is contained within the notification
request message. The Subject will compare this state with its
current state when the request is received and any time its state
changes. When the two do not agree, the Subject will update the
state indication within the message to match its current state, and
then return the message to the client (Observer).
In this way, the client can take action based on the new state of
the Subject.
A short statement that answers the following questions:
What does this design pattern do?
What is its rationale and intent?
What particular design issue or problem does it address?
Also Known As
Other well-known names for the pattern, if any.
Motivation
A scenario that illustrates a design problem and how the class and
object structures in the pattern solve the problem. The scenario will
help you understand the more abstract description of the pattern that
follows.
Applicability
What are the situations in which the design pattern can be applied?
What are examples of poor designs that the pattern can address? How can
you recognize these situations?
Structure
A graphical representation of the classes in the pattern using a
notation based on the Object Modeling Technique. We also use
interaction diagrams to illustrate sequences of requests and
collaborations between objects.
Participants
The classes and/or objects participating in the design pattern and
their responsibilities.
Collaborations
How the participants collaborate to carry out their responsibilities.
Consequences
How does the pattern support its objectives? What are the trade-offs
and results of using the pattern?
What aspect of system
structure does it let you var independently?
Implementation
What pitfalls, hints, or techniques should you be aware of when
implementing the pattern? Are there language-specific issues?
Sample Code
Code fragments that illustrate how you might implement the pattern in
C++ or Smalltalk.
Known Uses
Examples of the pattern found in real systems. We include at least two
examples from different domains.
Related Patterns
What design patterns are closely related to this one? What are the
important differences? With which other patterns should this one be
used?