Re: The merits of dynamic_cast<>()
On Sep 15, 5:59 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
Sam wrote:
Define all methods as virtual methods in your base class,
with the base class's skeleton implementation returning an
appropriate error code, or throwing an appropriate
exception, then define the appropriate methods in each one
of your derived classes.
This is really poor design and extremely BAD advice. I've
certainly seen it a lot and produced by a lot of self-declared
experts, even people who have been coding for years. However,
it breaks every principle there is and thus inevitably leads
to problems.
I'm not sure I'd agree with the "extremely", but I would argue
that you have to define clear interfaces, implemented by all of
the derived classes. There are a few special cases where one
might reasonably declare "conditionally implemented" functions
in an interfaces, but they certainly aren't common. (The most
frequent case is where a function is only authorised in certain
states, resulting from previous function calls, and some derived
class, for whatever reason, can simply never reach those
states.)
The problem here is that class B "is not" a class A and you
are forcing that relationship.
That's not true. His problem is that class B is not just a
class A; it's a class A and something more. That, in itself,
frequently occurs, even in the best designs. There's certainly
nothing wrong per se with a concrete class implementing several
different interfaces.
If there is a design problem, it's with the code using class A;
there are definite and clear exceptions, but most of the time,
if the code expects a pointer or a reference to an A, then it
should use the interface defined by A. In the exceptional
cases, a dynamic_cast can be used to ask if the object supports
the specific interface or not.
Note that I would be very leary of concrete classes adding
public functions in such a situation. You define an additional
interface (contract), and some of the derived classes implement
it, others not. Also, the number of such interfaces should be
fairly small---if every single derived class implements (or
defines) a new extention to the interface, there's definitely
something wrong somewhere.
One other valid use of dynamic_cast (although it doesn't seem to
be the case here) is in cases of type erasure. Intermediate
entities such as various middleware or persistancy generally
only require a very minimal interface; when recuperating an
object from them, some sort of dynamic_cast is often reasonable
in order to restore the correct type.
--
James Kanze