Re: The merits of dynamic_cast<>()
* Leslaw Bieniasz:
I have a base class A, and a number of derived classes B, C, etc.
The problem is that although the classes have a lot of common
functionality (contained in A), there are also some specific
features (new methods) added to B, C, etc.
But, since there is a common functionality, it is convenient to
keep pointers to the various objects as pointers to A, in a common
container. This implies that whenever I need to access the common
functionality, I can use pointers to A, but if I need the specific
features, I have to cast from the pointer to A, to pointers to derived
classes. Is this OK,
The number of tails depends on the dog.
or there are ways to implement the same
thing without using dynamic_cast<>() ?
Depends. You should look up the visitor pattern. But as mentioned by James Kanze
else-thread, in some situations casting can be the most reasonable thing to do.
For the case of objects representing states I've found it useful, in the sense
of clarity, to use simple event handling where the event object performs a
dynamic cast of the target to the event object's handler interface, and if that
interface isn't present, calling a default handler on the object[1]. This avoids
a cluttered central "God object" interface and makes the intent more clear: any
object may simply ignore any event. But this is less than natural when the
actions can't be modeled as simple events (preferably without arguments).
If neither approach seems feasible then consider the knowledge distribution of
your design. The need for casting arises because the knowledge needed for some
action isn't present where the responsibility for carrying out the action has
been assigned. The trick is then to make the knowledge available where it's
needed, by moving or referencing the knowledge and/or the action responsibility.
Cheers & hth.,
- Alf
Notes:
[1] In C++, where generality is not cheap, I just use a simple two-level
hierarchy: completely generic handler or event-specific handler, templated. In
Java, with introspection, I once generalized this idea to general hierarchies of
handler interfaces. I can report that although it's theoretically a very nice
idea in practice it's just inefficiency and complexity for very little gain.