Re: Clean ways to identify derived class types.
Stuart Golodetz wrote:
JC wrote:
I'm designing an application that uses a simple event-based model for
passing messages between objects. It's a basic "observer" setup. I
have it set up something like this (I'm just typing these here,
leaving a lot out I know):
class Event {
};
class EventListener {
public:
virtual void onEvent (const Event &);
};
class EventSource {
public:
void addListener (EventListener *);
protected:
void notifyListeners (const Event &);
};
Specific events (possibly with extra event-specific info) are derived
from Event. Note that an EventListener receives all types of events
that an EventSource generates -- it's all-or-nothing rather than
registering for specific types of events. This is important to me and
simplifies a lot of the logic throughout the application.
So, here is my question. In the various implementations of
EventListener::onEvent, some of the EventListeners handle a lot of
different event types, and the implementations end up looking rather
ugly, sort of like (again just typed here, pardon any errors):
void SomeEventListener::onEvent (const Event &e) {
const AnEvent *a = dynamic_cast<const AnEvent *>(&e);
if (a) {
handleAnEvent(a);
return;
}
const OtherEvent *b = dynamic_cast<const OtherEvent *>(&e);
if (b) {
handleOtherEvent(b);
return;
}
// and so on...
}
Are there other good ways to do this? I'm pretty much asking just out
of curiosity, as the above method actually does work adequately, even
though it's sort of painful to look at. Fortunately, in this
particular application, performance penalties of dynamic_cast are
negligible and not an issue, but what if performance did matter --
would there still be a way to keep the flexibility of EventListeners
not having to register for specific event types?
One obvious solution is to have type ID numbers, unique to each event
type, with a virtual int getType() or some such. However, I don't
think that's really a good solution here -- I think it will be a
maintenance problem in the future if new events are added, to ensure
uniqueness of the IDs (unless IDs are noted in a document somewhere,
which I guess is OK, or if they're all declared in some common header
or even assigned dynamically on first access, which works but breaks
encapsulation a bit). I could use ID strings with the same name as the
class to ensure uniqueness, but *if* the goal was performance, I'm not
sure if I'd be comfortable with string compares every time.
Thanks!
J
Sounds like double dispatch might be what you're after, in which case
look at:
http://www.ddj.com/cpp/184429055
Regards,
Stu
Sorry, didn't read what you said nearly carefully enough the first time
(i.e. about the not registering aspect of it all). That being said, a
scheme like the one described in the link above can work without event
listeners needing to register their interest with anyone else: you just
make them inherit from e.g. MessageHandler<Message1> and
MessageHandler<Message2>, etc. and specify the appropriate handlers for
each message. When it comes to sending messages of type M, you can then
avoid the need to register interest by doing a
dynamic_cast<MessageHandler<M> > and only sending the message if the
listener would do something with it. Just thought it might be worth
considering. I'm using such a scheme for my game (although in practice I
allow for registering interest in messages referring to specific game
objects, for performance reasons - but that's not strictly necessary),
so I can attest to the fact that it works.
Best wishes,
Stu