How do I design an Observer pattern with different types of notifications and observers?

Question

Scenario: say I have a base class SketchbookEventObserver and derived classes MouseClickObserver, TouchObserver and TextChangedObserver.

All of these SketchbookEventObservers have to make a network request with data about the event that happened:

MouseClickObserver - coordinates of the mouse click.

TouchObserver - coordinates and duration of touch.

TextChangedObserver - the old and new text with a text box identifier.

All of these observers are registered on a UIEventRegistry class. When an event happens, it woud call OnEvent on each observer, and pass as params:

1. The type of event - mouse click / touch / text changed. This is represented by an ID.
2. The data about the event - as described above. Each type of event will have different types of data.

However, I cannot override OnEvent with different input parameters in each of the derived classes. If I have the input parameter generic and polymorphic, say EventData with a GetData() function, I would still need to override GetData() in derived classes of EventData, which will have different return values. This is also impossible.

The other option is to not have any inheritance between these observers, and treat them as separate entities. EventRegistry will have an array / list of observers of each type, where their types are known, then call mMouseClickObservers[i].OnEvent() for a mouse click event, mTouchObservers[i].OnEvent() for a touch event, and so on.

But this means that EventRegistry will need to have knowledge about the concrete classes, which need to be exposed publicly if EventRegistry is part of a different library / package.

Is there a better way to design this?

Answer 1

One way is you can derive MouseClickEventData, TouchEventData, TextChanged classes from EventData class. And cast your EventData so you will have specific classes for each data.

OnEvent(EventData *data) {
    if (data->type == MOUSE_CLICK) {
        MouseClickEventData *mData = dynamic_cast<MouseClickEventData*>(data); 
        // use mData->getCoordinates();
    }
    if (data->type == TEXT_CHANGED) {
        TextChangedEventData *tData = dynamic_cast<TextChangedEventData*>(data); 
        // use tData->getNewText();
    }
    ....
}

Answer 2

In order to vary the behavior of the observers based on both the type of the observer and the thing being observed, we need to use double-dispatch. The Visitor Pattern uses double-dispatch to allow a set of visitors to observe a set of events. I won't provide an implementation here, but the psuedocode would resemble:

interface SketchbookEventObserver:
    void handle(MouseClickEvent event);
    void handle(TouchEvent event);

interface SketchbookEvent:
    void accept(SketchbookEventObserver observer);

class MouseClickObserver implements SketchbookEventObserver:

    void handle(MouseClickEvent event):
        ...

    void handle(TouchEvent event):
        ...

interface MouseClickEvent implements SketchbookEvent:

    void accept(SketchbookEventObserver observer):
        observer.handle(this);

An alternative is to register a listener for each type of event. This is the approach taken by Java with its UI frameworks. For example:

class Component:

    void registerMouseClickListener(MouseClickListener listener):
        ...

    void registerTouchListener(TouchListener listener):
        ...

interface MouseClickListener:
    void handle(MouseClickEvent event);

interface TouchListener:
    void handle(TouchEvent event);

Answer 3

The other option is to not have any inheritance between these observers, and treat them as separate entities.

This is my favorite option, and one that I've advocated many times because it maintains type safety of the events. If each event is different, don't handle them all through the same API.

But this means that EventRegistry will need to have knowledge about the concrete classes...

MouseClickObserver, TouchObserver, and TextChangedObserver should all be abstractions. You may only have one implementation of each abstraction now; but the design should not enforce that.