OTPattern/PeerNotification

Intent

Implement a notification between peer objects, i.e., objects belonging to the same architectural layer.

Motivation

Generally, OT/J programs implement Notification between objects using simple callin bindings (OTJLD §4). However, this is easy only in cases where the observer resides in a higher architectural layer than the subject it observes. In those situations the observer can easily be realized as a role of the subject.

By contrast, this pattern deals with the situation that subject and observer belong to the same architectural layer, i.e., they are peers. In this case it is unlikely that the observer is a role of the subject. In particular, both participants might be roles of the same team. Yet, notification should be implemented in a way that combines the power of the classical Observer pattern with the simplicity of callin bindings.

Structure

Introduce one level of nesting to support a playedBy relation pointing to the subject.

class SubjectPeer { }
team class ObserverPeer {
    protected class ObserverRole playedBy SubjectPeer { }
}

Participants

In addition to the given SubjectPeer and ObserverPeer participants, an inner participant ObserverPeer.ObserverRole is introduced, whose purpose is to receive notification from the SubjectPeer and invoke methods of the ObserverPeer.

Collaborations

The ObserverRole is solely responsible for implementing the collaboration. It does this by one or more callin bindings intercepting events at SubjectPeer and invoking corresponding actions on ObserverPeer. For example:

team class ObserverPeer {
    void update() { ... }
    protected class ObserverRole playedBy SubjectPeer {
        notify <- after edit;
        void notify() {
            ObserverPeer.this.update(); // `update()` would suffice -- using qualification for clarity.
        }
    }
}

Applicability

This solution is only applicable, if ObserverPeer can be implemented as a team class. Since Trac ticket #144 (fixed for OTDT 1.4.0M3 / 0.7.0M1) this shouldn't be a restriction any more.

On the other hand, it doesn't matter whether SubjectPeer and ObserverPeer are toplevel classes or roles.

Implementation

The team ObserverPeer should perhaps call activate(..) (OTJLD §5.2.b) in all its constructors including the lifting constructor if it is a bound role, too.

Consequences

Notification is localized in one class: role ObserverRole. Introducing a new level of nesting could be considered as artificial complexity.

Regarding registration of subjects for observation and starting/stopping the notification protocol the same considerations apply as for regular base-to-role notification.

Using multiple inner roles, one (team) object can easily observe multiple other objects even of unrelated types.

Known Uses

This pattern was first used for a class-room exercise, where a role Student should take notes of everything that a peer role Teacher would say in class.

Related Patterns

• This pattern is a variation of the more general Notification.