OTPattern/Notification

Intent

Define a notification protocol between two entities. The entity triggering the notification does not know about the entity being notified.

Also Known As

Observer. Publisher-Subscriber. View updating.

Motivation

Prevalent in the MVC architecture each view needs to be notified when its model is changed. Such notification should not be implemented explicitely in the model in order to decouple it from its (potentially many) views. Generally all applications of the Observer GoF-Pattern are candidates for the solution presented in this pattern.

Applicability

This pattern requires two separate entities with some kind of semantical dependency. Usually one of these entities can be considered primary, ie., it is used directly within the application. The secondary entity depends on the primary. A usage relation exists from the secondary to the primary but not in the opposite direction. Standard object-oriented solutions usually implement an explicit Observer registry at the Subject (primary) and implement a generic notify-update protocol between them two. In some cases this protocol must exist in multiple variants because different notifications require different data to be passed to the Observer (secondary).

Structure

The OT solution will make the secondary entity a role Secondary of some team Context. The role has a playedBy relation to the primary entity Primary. Notification is defined by individual callin method bindings.

Participants

• Primary: This base class has no specific responsibilities. Some clients external to the pattern will request some functionality (service()) from the Primary.
• Secondary: This role class decorates the Primary.
• Context: This team class contains the Secondary.

Collaborations

The Secondary defines one or more callin bindings to intercept calls to methods of the Primary. The role methods bound in this binding executes what ever action should be taken upon notification. The connection between instances of Primary and Secondary can be established in several ways. The simplest techniques are DecoratorCreation and ObjectRegistration, both of which will usually be a responsibility of the Context team.

Consequences

The Notification pattern by itself does not answer how instance registration is performed, i.e., the choice between applicable mechanisms is left open.

Obviously, the Notification pattern requires Secondary to be a role of some team. If Secondary is to be referenced by a large number of classes, which cannot easily be allocated within the same team, heavy use of externalized roles will be needed and might complicate the application.

Sample Code

The normal implementation in OT/J looks like this:

public team class Context {
  public class Secondary playedBy Primary {
    public void action() {
      // application specific code
    }
    action <- after service;
  }
  void setup () {
    Primary p = ...
    new Secondary(p);
  }
}

The above code uses the DecoratorCreation technique, which has to be used with care. If only one pair or a small fixed number of pairs of entities is involved the following empty registration method (ObjectRegistration), which may be called from outside the team, may suffice:

public team class Context {
  ...
  void setup (Primary as Secondary e) {
    // empty body
  }
}

Known Uses

All OT/J examples with GUI employ this pattern:

• OTExample Stopwatch
• BrowserDemo (outdated)

...

Related Patterns

The idioms DecoratorCreation and ObjectRegistration can be used to establish the connection between Primary and Secondary instances. The pattern IndirectCommunication applies the same concept transferring it to more complex scenarios.