Implementing Mediator Pattern in C++

[cppaddict]

I have a design question which I am posting here because the
implementation will be in C++ and I think there may be C++ specific
language constructs (eg, friends) that might be relevant to the
solution.

I am implementing the Mediator pattern to create an event-driven app.
The Collaborators (which watch for various events and which all have a
reference to the Mediator object) will call handleEvent(Event e) on
the Mediator object when they observe a relevant event.

Right now, my Mediator object is branching on the event to do the
processing:

if (e.type == "Event1")
//tell collaborator 2 to do some stuff
//tell collaborator 3 to do some stuff
else if (e.type == "Event2")
//handle event2
etc.....

But I can't stand the look of this design. It is, for one, closed to
the addition of new event handlers (ie, I have to modify the branching
code in Mediator if I want to handle a new event or modify the
handling of an event).

It seems there should be a way to add EventHandler objects (with
member variables specifying what types of events they handle) to the
Mediator. When the Mediator received an event, it could look through
its handlers and execute a handleEvent() method on each relevant
handler. The problem is that the EventHandler objects don't have
access rights to call methods on the Collaborators, which are private
members of Mediator.

How should I handle this problem? Pass those members into the
EventHandlers when they are created, perhaps in Mediator's ctor? Or I
could declare the EventHandlers as friends? But I would probably need
to put the EventHandlers into a vector -- can you declare a vector of
friends???

Or is there some more fundamental flaw to this design??

Thanks for any help,
cpp

 

[Ivan Vecerina]

hi,

I am implementing the Mediator pattern to create an event-driven app.
The Collaborators (which watch for various events and which all have a
reference to the Mediator object) will call handleEvent(Event e) on
the Mediator object when they observe a relevant event.

Right now, my Mediator object is branching on the event to do the
processing:

if (e.type == "Event1")

Is such a switch-like statement necessary?
In implementations of the Mediator pattern, it is common to have
one method/handler for each type of event.

But I can't stand the look of this design. It is, for one, closed to
the addition of new event handlers (ie, I have to modify the branching
code in Mediator if I want to handle a new event or modify the
handling of an event).

Ok, let's assume that the possible events are not known a priori.

It seems there should be a way to add EventHandler objects (with
member variables specifying what types of events they handle) to the
Mediator. When the Mediator received an event, it could look through
its handlers and execute a handleEvent() method on each relevant
handler. The problem is that the EventHandler objects don't have
access rights to call methods on the Collaborators, which are private
members of Mediator.

How should I handle this problem? Pass those members into the
EventHandlers when they are created, perhaps in Mediator's ctor? Or I
could declare the EventHandlers as friends? But I would probably need
to put the EventHandlers into a vector -- can you declare a vector of
friends???

Or is there some more fundamental flaw to this design??

Because you do not describe the problem to be solved (but only
a proposed solution), we have to guess what you are trying to do.
But it seems to me that you only want to pass on the events to the
Collaborators, and that your Mediator does not have much
intelligence.
So maybe you should consider an Observer or Broadcaster-Listener
design pattern.
For example:

class Event { /*...*/ };

class IListener { // interface for all listeners
public:
void listen(Event& event);

virtual ~IListener() {} // or make it protected?
};

class Broadcaster
{
private:
// ... manage a list of listeners, maybe using an std::vector
// or an std::set<IListener*>
bool include(Listener& listener); // --> true not already present
bool exclude(Listener& listener); // --> true if removed (was included)

void broadcast(Event& event)
{
... call listen(event) on each connected Listener ...
}
};


hth,
Ivan

 

[Daniel T.]

I am implementing the Mediator pattern to create an event-driven app.

You say you are implementing a Mediator pattern, but what you describe
doesn't sound much like one...

The Collaborators (which watch for various events and which all have a
reference to the Mediator object) will call handleEvent(Event e) on
the Mediator object when they observe a relevant event.

By "Collaborators" I assume you mean the classes the book calls
Colleagues?

Do the Collaborators create the event objects, or are the event objects
created elsewere and sent to the Collaborators via a Chain of
Responsibility?

Right now, my Mediator object is branching on the event to do the
processing:

if (e.type == "Event1")
//tell collaborator 2 to do some stuff
//tell collaborator 3 to do some stuff
else if (e.type == "Event2")
//handle event2
etc.....

But I can't stand the look of this design. It is, for one, closed to
the addition of new event handlers (ie, I have to modify the branching
code in Mediator if I want to handle a new event or modify the
handling of an event).

Does each Collaborator listen for multiple events?

It seems there should be a way to add EventHandler objects (with
member variables specifying what types of events they handle) to the
Mediator. When the Mediator received an event, it could look through
its handlers and execute a handleEvent() method on each relevant
handler. The problem is that the EventHandler objects don't have
access rights to call methods on the Collaborators, which are private
members of Mediator.

The Mediator could pass the Collaborators to the EventHandler in
question.