A broker-based implementation of the Typed message pattern
- Benjamin Kaufmann
This little library is essentually an implementation of the Typed message pattern 
Typed message (and therefore this implementation) is useful when all of the following are true (quoting from the applicability section):
- 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.
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:
- It provides an registration interface for event handlers.
- It provides an dispatch interface for event sources.
Having this mediator in place the problems mentioned above are easily solved:
- If you need different sets of handlers create a broker for each set.
- If you have many event sources and you don't want to register with each and every source, let your sources use the same broker and register your handlers with that broker.
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) 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 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.
If you are interested in the reasons why this library is implemented the way it is refer to the page Design Rationale.
: John Vlissides, Pattern Hatching - Design Patterns Applied, Addison-Wesley, 1998
- 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.
: John Vlissides, Multicast - Observer = Typed Message
: The Connection class is inspired by Douglas Gregor's boost::signals library
© Copyright Benjamin Kaufmann, 2004-2005 Last revised: 6 Apr 2005
Back to www.ansi-pedantic.de