Runtime Dynamic Dispatch

PrevUpHomeNext

Rationale

Why was this library made when std::map<T, boost::function<U, V> > does pretty much all the functionality this library provides?

The reason really all boils down to the value add that comes with the library which are:

Strategized Index Validation which is discussed here.

Strategized Routing which is discussed here.

Scheduled/Sequenced Invocation using an invoker which is discussed here.

The dispatcher aims to provide a common interface for self-registering classes and self-registering dynamically loaded functions. Since the dispatcher is dynamic while exposing a lot of aspects of the instantiated strategies, it allows for flexible extension and seamless type-safe usage.

The dispatcher does not aim to replace the Signals library, which is basically a publish-subscribe (or subject-observer) library. The dispatcher is more of a router which does either/both index/message validation and index/message routing. The policies used to instantiate a dispatcher allows for decoupling the index validation implementation from the routing logic during compile time.

The invoker concept was added to allow for a mechanism for chaining consecutive invocation of registered callbacks. Instead of writing:

d[0](); d[1](); d[2]();

The invoker allows you to write this:

invoke_(d)() << 0 << 1 << 2;

Overall, the dispatcher is more of a convenience library for being a switch replacement that can be manipulated during runtime by the application. It also allows for writing dynamic behavior based on runtime rules with a combination of dynamic loading mechanisms and a simple language/protocol -- think of it as a reprogrammable switch statement, with index validation and routing strategies built in.

The following sections will discuss further the design of the library.

Copyright © 2006 ,2007 Dean Michael Berris

PrevUpHomeNext