Re: Event dispatcher, hooks and Interceptor pattern for C++?
Lothar Behrens wrote:
On 27 Dez., 02:21, Pavel
<pauldontspamt...@removeyourself.dontspam.yahoo> wrote:
Lothar Behrens wrote:
Are there any documents available about the interceptor pattern?
I have a class that registers an event handler to be called on a given
event. The interceptor pattern then should be used to add restrictions
or other things to the function.
I could implement that in my dispatcher class (like an event
dispatcher pattern), but I think there are patterns also usable for
this issue in C++.
I have cases where I register event handlers per class and others per
instance (by adding the pointer to the event name). Thus when I have
an event handler per instance, but a interceptor
per class I have to strip the pointer from the event name (after
resolving it from the number) to locate the handler correctly.
Any help out there?
Thanks
Lothar
RTTI in C++ is not sophisticated enough to get you a static function if
you have a typeid or another "runtime id" of the event class.
You could probably construct your own metadata ("Runtime Class") so you
could refer to an instance of "RunTime class" from a virtual method of
your event or from "dispatchEvent" or similar method of your event
dispatcher, based on the result of some virtual method of the event
returning some form of its class id (maybe even typeid).
Alternatively, with somewhat lesser flexibility, you could put your
intercepting logic into the method of the event itself, something along
these lines:
class Event;
class EventHandler {
public:
virtual void handle(Event *)=0;
};
class Event {
public:
void process() {
if (!intercept())
handler_.handle(this);
} // I assume that's what you meant by "adding pointer to the event name"
virtual bool intercept(Event *) = 0;
private:
EventHandler handler_;
};
class ConcreteEvent : public Event {
public:
bool intercept() {
// one algorithm per event class here
// so no need to register
}
};
I am not sure I captured your problem fully; it would help if you posted
some source code to illustrate the issue.
-Pavel
The C++ language may not have the same capabilities as java, so I need
a dispatcher where I register my callbacks to names or ID's.
The event handler pattern is not the problem, as I use it since some
years.
The interceptor as I do understad, is a pre and post condition I could
activate on demand to change the plain behavior for sample to
add permission handling.
My problem is if this interceptor pattern is also usable if I have a
class (that is a database form) and I have different form instances
and thus different interceptors are required to add logic depending on
the particular form. Thus I may have more than one interceptor per
form. The form it self is a dynamic implementation to be used for
different data to be shown, thus there may also different
interceptors.
My main issue is about saving code. Another function I previously have
implemented is inside of the handlers. I don't like to keep adding
any more if I can do the same with interceptors. (application hooks
will become interceptors)
Lothar
I guess I am slightly confused then. I thought you wanted one
interceptor per class (even though I could not clearly understand -- per
event class, event source class or event handler class; in my example, I
assumed you wanted one interceptor per event class).
From your last post, however, I cannot see a difference between event
handler and event interceptor other than that you want some interceptors
to be called before and some after event handlers for same event. I
think you can achieve this without introducing new concept of an
Interceptor, simply with event handlers you already have. You could
register event handlers in a priority queue (with the priorities like
enum { PRE_INTERCEPTOR_PTY, REGULAR_HANDLER_PTY, POST_INTERCEPTOR_PTY }
) or two or three separate lists (two or three depending on whether you
want both "pre-" and "post-" interceptors). Also, if you want to be able
to stop event handling in an interceptor (to "veto" an event in terms of
Java or Interceptor pattern), you will need a boolean "processed"
attribute in events or alternatively you could make "handleEvent" return
bool.
If you require even more complex interactions between event handlers
(for example, you want to be able to skip some handlers but still
execute the last "logging" interceptor), you may need to add more
complex information to an event.
-Pavel