Main Page | Namespace List | Class Hierarchy | Class List | Directories | File List | Class Members | Related Pages | Examples

A broker-based implementation of the Typed message pattern[1][2]

Benjamin Kaufmann


This little library is essentually an implementation of the Typed message pattern [1][2]

Typed message (and therefore this implementation) is useful when all of the following are true (quoting from the applicability section):

In his book Pattern Hatching, John Vlissides discusses two different ways to establish the connection between events and their handlers. Event handlers either register with the event types or with the event sources.

Both implementations have there problems.

Registering with the event type is problematic if the identity of the source is relevant. Staying with the vending machine example imagine you would have to support more than one machine. In that case it would be rather inappropriate if the Dispenser of the first machine would react on CoinInserted-Events of the second machine.

Registering with the event source on the other hand is wasteful if there are many event sources all producing events of the same type and your handlers are more interested in the events than in the identity of the source.

This implementation tackles both problems by introducing a mediator between event sources and event handlers. This mediator is called event broker and it has two main responsibilities:

Having this mediator in place the problems mentioned above are easily solved:

In this implementation one needs to distinguish five different participants:

1. Event types:

Event types are arbitrary value types that encapsulate information to be transferred from event sources to event handlers. When used with broker managers event types must be associated with a unique id using the Event class.
2. Event brokers:

Event brokers are objects of the class Broker. An event broker acts as a mediator between event sources and event handlers therefore keeping them from referring to each other explicitly. Event brokers maintain references to event handlers (see event::Connection[3]) and provide a dispatch method over which event sources can send information to interested objects. Which and when events are dispatched is decided by event filters that can be installed on event brokers.
3. Event sources:

Event sources create events and send them to interested handlers by calling event::Broker::dispatch.
4. Event handler:

Event handlers are either objects of arbitrary types that provide member functions of the form
void handle(const E&)
for each concrete event type E the handler is interested in (refer to the documentation of the class CallTraits for information on how to specify the names of the concrete handler methods) or functions that accept one parameter that is compatible with the event type the function wants to handle.
Event handlers connect to event brokers in order to receive events.
5. Broker Manager:

Broker Managers manage and provide access to event brokers for different event types. Broker managers create brokers on demand and guarantee that all brokers that were created by the manager are destroyed when the manager gets destroyed.

Design Rationale:

If you are interested in the reasons why this library is implemented the way it is refer to the page Design Rationale.

A Minimal Example:

struct AnEvent {};
struct AnotherEvent {};
struct AHandler {
    void handle(const AnEvent&) {
        cout << "received an event of type AnEvent" << endl;
    void handle(const AnotherEvent&) {
        cout << "received an event of type AnotherEvent" << endl;
int main() {
    // not strictly necessary but see documentation for event::Event

    event::BrokerManager m;
    AHandler h;

    // alternative syntax for compilers not supporting
    // explicit template argument specification



[1]: John Vlissides, Pattern Hatching - Design Patterns Applied, Addison-Wesley, 1998
[2]: John Vlissides, Multicast - Observer = Typed Message
[3]: The Connection class is inspired by Douglas Gregor's boost::signals library

© Copyright Benjamin Kaufmann, 2004-2005 Last revised: 6 Apr 2005

Back to