Notification Pattern


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.


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.


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?


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.


The classes and/or objects participating in the design pattern and their responsibilities.


How the participants collaborate to carry out their responsibilities.


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?


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?