Pattern Hatching

Multicast - Observer = Typed Message

John Vlissides

In my opinion, Multicast is a special case of Observer, a more complicated case. This is not a proof that there shouldn't be two patterns in the catalog, just something to consider when you are deciding what should be there.

The waning arguments for an independent Multicast pattern came from Richard:

I still believe that Observer/Multicast are different but related patterns. . . . Think about what concepts are varying: in Observer, it really is the concrete observers, and possibly the aspects* of the subjects. In Multicast, it is the types of events. To me this is the key difference between the two patterns. I do not see Multicast as an extension to Observer or vice-versa for this reason. . . .

Note that in common to both patterns there is the solution concept of registration and notification. But this is basically a mechanism to allow senders and receivers to be bound at run-time. It is not intrinsic to the problem each pattern is solving but to the fact that these patterns establish relationships between objects, and registration/notification is a basic mechanism (pattern?) to do this.

[Think also about] scope and variations. In this light I think that the variations to Multicast include

• M_a: global notification, registering with the event class, e.g., MyEvent::register(MyEventHandler)—"broadcast" as per John's article.
• M_b: local notification, registering with the sender, e.g., Sender::registerMyEventHandler(MyEventHandler) as per Erich's preference and closer to my idea of "narrowcast."
• M_c: local notification, registering with the sender and using a single event class, e.g., Event.

Similarly, variations on Observer include

• O_a: notification of nonspecific change (naive observer), e.g., Observer::Update().
• O_b: notification of semispecific change, e.g., hints—Subject::Register(Aspect, Observer).
• O_c: notification of specific change, e.g., an event—Subject::registerMyEvent(MyEventHandler).

Note that M_b and O_c are very similar, as are O_a and M_c.

In this perspective, (a) Observer is a refinement of Multicast, but equally, (b) Multicast is a refinement of Observer. It is just that with (a) you have limited the scope of events more and more to arrive at a specialized Observer. With (b) you have extended the scope of Subject changes in Observer to arrive at a specialized Multicast. Both views are valid.

Exactly the same phenomenon [occurs] when you push traversals into the Visitor, [producing something] close to Iterator. Or you extend Strategy to arrive at Builder.

I always like to start with the naive patterns and see what kinds of changes you have to make to arrive at another pattern. From the above you have to go from M_a to M_b to M_c to O_a to get from Multicast to Observer. I have always maintained that wisdom about patterns comes from the space between them.

ONE MORE DATAPOINT

I wanted to respond to the issue you raised in your Multicast article. Is Multicast just a variation on Observer? I think not. And the reason that I think not is that observers know their subjects. But Multicast handlers don't have to know their event sources.

In Observer, you want to know when the state of something changes. So you register an observer on that thing. But in Multicast you are interested in the occurrence of a particular event. You don't care about the source of that event. (Which, by the way, is why I liked your idea about putting the registration function in the Event rather than Erich's notion of putting the registration interface on the event source.)**

Consider a keyboard event. We may have a system with a keyboard and a keypad. Both these devices produce keyboard events. The software doesn't care about the source. It doesn't care that the "3" key was hit on the keypad or on the keyboard, it just wants to know what keys were hit. We could make the same argument using a mouse and a joystick, or anything where there might be multiple event sources.

I think this is a fundamental difference between Multicast and Observer. In Multicast we are still observing something, but we don't know what we are observing. The thing we register with is not the thing that generates the stimuli that we are interested in.

Similarly, viewing Multicast as an extension of Observer runs counter to their respective purposes. Observer maintains a one-to-many dependency between objects, while Multicast is about delivering encapsulated information to objects in a type-safe and yet extensible fashion. To underscore the difference, I posited using Multicast to implement a many-to-one dependency—exactly Bob's example and clearly outside Observer's intent.

ABOUT FACE

In my Design Patterns and Java course, I had to explain the new JDK 1.1 event handling model. So it all came back to me again. It turns out in explaining the design that it was really easy to [introduce] this as an Observer relationship, since everybody was familiar with that. In the next step I explained the refinements on typed events and registering interests. So I think it is important to state that Multicast is a refinement of Observer and [to describe] what it refines instead of arguing whether Multicast is different from Observer. This doesn't answer the question whether a refinement deserves its own pattern. I still think it does.

Actually, there is another example of this in GOF. At some point we argued whether Builder isn't just a Strategy for creating things. Obviously Builder made into the book as a separate pattern.

Regarding the name, after reading the arguments about types. I'm getting attracted by the name "Typed Message."

I for one was taken aback, to be sure, but in a good way. Things finally seemed to be clicking. But like any prudent soul contemplating a one-eighty, and ever the bottom-liner, I wanted to make certain I understood the ramifications of this epiphany:

So you're advocating stripping registration and delivery out of Multicast, putting it into Observer, and saving the rest for Typed Message?

Yes, I think this is it. Remember that we already discuss the registration for interests in Observer (see page 298, bullet 7). The more I think about it, the more I like it . . .

Ralph gave his blessing shortly thereafter:

I would be a lot happier with Multicast/Typed Message if it were presented the way Erich said. The relationship to Observer is so obvious that when we don't emphasize it, it makes me think we are trying to hide something.

When we wrote our book, we were trying to hide something. We were trying to avoid talking about one pattern being a specialization of another, or one pattern containing another as a component. We wanted to avoid going meta and just wanted to talk about patterns. This was part of why we didn't describe abstract class as a pattern, since most of the patterns would have contained it.

I think that was a good decision for the first patterns catalog, but the world is different now. People want to know the relationship between patterns and we need to tell them. The relationship here is so obvious that we need to emphasize it, not just tuck it away at the end in the "related patterns" section.

A STRAWMAN

Intent

Encapsulate information in an object to allow its type-safe transmission. Clients may extend the object to add information without compromising type safety.

Motivation

[Basically the vending machine example from Multicast¹ with minor changes to emphasize the encapsulation and extension of events and to de-emphsize the notification process. Some of the more detailed code has been moved to the Sample Code section.]

Applicability

Use TYPED MESSAGE when all of the following are true:

• Certain classes of objects may be interested in receiving information from other objects.
• The information is of arbitrary structure and complexity and may vary as the software evolves.
• The information transfer should be statically type-safe.

[Exactly the same as before.]

Structure

See Figure 1.

Figure 1

Participants

Message (ProductDispensedEvent)

• Encapsulates information to be transferred from Sender to Receiver.

Sender (Dispenser)

• Maintains a reference to a Receiver object.
• Implements one or more operations that involve sending a message to the receiver.

AbstractReceiver (ProductDispensedHandler)

• Defines an interface for receiving a Message object.

Receiver (CoinChanger)

• Implements one or more AbstractReceiver interfaces.

Collaborations

• A sender instantiates a message and delivers it to its receiver.
• A message is passive; it does not initiate communication with senders or receivers.

Consequences

1. Information may be passed type-safely and extensibly without downcasts or switch statements...
2. Supports implicit invocation when combined with OBSERVER...
3. Lack of multiple (interface) inheritance makes application difficult...
4. May lead to convoluted inheritance graphs...

Implementation

1. There needn't be a one-to-one relationship between Message classes and AbstractReceiver interfaces...
2. Lumping Message and Sender improves extensibility but makes it harder to tell who sends a given Message...
3. Implementing TYPED MESSAGE in a weakly typed language or one lacking multiple inheritance...
4. Combining TYPED MESSAGE and OBSERVER...
5. Trade-offs in defining a common base class for Messages...

Sample Code

[Code snippets lifted from the Motivation's vending machine example. Includes variant implementations such as the lumped Sender-Message design described last time¹ and an implementation using composition instead of multiple inheritance.]

Known Uses

Java's JDK 1.1 uses TYPED MESSAGE in conjunction with OBSERVER in its "delegation-based event model," as Erich mentioned. I have used it in at least one project at IBM Research, but that work is as yet unpublished. Other known uses are most welcome!

Related Patterns

[OBSERVER is related, of course, but that will have been made abundantly clear by the time you get to this section.]

Typed messages may be mistaken for commands (see COMMAND²). As always, the difference has to do with intent. A command encapsulates an operation, whereas a typed message encapsulates state. One is active, the other is passive. TYPED MESSAGE also has an emphasis on type-safe extension that COMMAND lacks.

TYPED MESSAGE may seem closer to a pattern that's often used with COMMAND, namely MEMENTO². But MEMENTO's intent is the opposite of TYPED MESSAGE's: a memento must avoid transferring information to other objects. The information it encapsulates is for its originator's eyes only.

MORE TO COME

Well, suppose you could make that system generate an event when any one of its methods got called—without modifying the caller or callee one whit. Impossible you say? Next time we'll look at something called "subject-oriented programming"⁵ that adds a new dimension to these patterns.

MAILBAG

In ["Latter-Day Events"³] you resolve the "type-laundering" issue as it applies to handling of events in the control framework. Decentralization is one solution, but it has an effect that I didn't see directly acknowledged: haven't you decentralized event handling until it was driven right out of the framework?

If event handling is to be type-safe, which was the point of the exercise, then the framework must avoid binding a particular type of event to the handling of that event. That's the goal of decentralization. When the framework defines the lone event-handling interface by binding event to handler, it must assume a lowest-common-denominator event type, and applications must make up the difference dynamically.

That may be a reasonable trade-off, by the way. Static typing is more of a hindrance than a help in many circumstances—after all, 50,000 Smalltalkers can't be wrong!^*** But the larger and longer-lived the system, the more likely it is to benefit from static typing.

Speaking of reuse, Paul Pelletier (unknowingly) applied Cope's Curiously Recurring Template Pattern³ to Multicast and (unknowingly) wound up with a streamlined way to implement Typed Message:

After reading ["Latter-Day Events,"] I thought, "Hey, a nice template could probably be created to simplify even more the creation of new events . . ." After playing with this idea for a while, I came up with the following code. The part I'm not too sure about is the way the template is used, using the derived class we're creating as an argument:

    class CoinInsertedEvent : public TEvent<CoinInsertedEvent>
    

I've never seen templates used this way, but I can see now that this could be a useful way to have the type checking done at compile time. Does this way of using a template has a special name?

Another nice thing about using the template is that the Handler interface is automatically generated as part of the TEvent class itself, simplifying even more the addition of new events.

    #include <iostream.h>
    #include <stdio.h>
    #include <list>

    using namespace std;

    template <class T> class TEvent {
    public:
        class Handler {
        public:
            Handler() { TEvent<T>::Register(this); }
            virtual int HandleEvent(const T &t) = 0;
        };

        typedef list<Handler*> HandlerList;

        static void Register (Handler* aHandler) {
            registry.push_back(aHandler);
        }

        static void Notify (TEvent<T>* t) {
            HandlerList::iterator i;
            for (i = registry.begin(); i != registry.end(); i++) {
                (*i)->HandleEvent(*(T*) t);
            }
        }

        void Notify () { T::Notify(this); }

    private:
        static HandlerList registry;
    };

    class CoinInsertedEvent : public TEvent<CoinInsertedEvent> { };

    class CoinReleaseEvent : public TEvent<CoinReleaseEvent> { };

    class ProductDispensedEvent : public TEvent<ProductDispensedEvent> { };

    class CoinChanger : 
        public CoinReleaseEvent::Handler,
        public ProductDispensedEvent::Handler {
    public:
        int HandleEvent (const ProductDispensedEvent &event) {
            cout << "Changer::Coin dispensed." << endl;
            return 0;
        }
        int HandleEvent (const CoinReleaseEvent &event) {
            cout << "Changer::Coin released." << endl;
            return 0;
        }
    };

    TEvent<CoinInsertedEvent>::HandlerList
    TEvent<CoinInsertedEvent>::registry;
    TEvent<CoinReleaseEvent>::HandlerList
    TEvent<CoinReleaseEvent>::registry;
    TEvent<ProductDispensedEvent>::HandlerList
    TEvent<ProductDispensedEvent>::registry;

    int main (int, char**) {
        CoinReleaseEvent coinReleaseEvent;
        CoinChanger coinChanger;
        ProductDispensedEvent productDispensedEvent;

        coinReleaseEvent.Notify();
        productDispensedEvent.Notify();
    }
    

ACKNOWLEDGMENTS

***I pulled that number out of a hat. Please don't quote me!

References