Re: dynamic_cast is ugly!
James Kanze <james.kanze@gmail.com> wrote:
"Daniel T." <danie...@earthlink.net> wrote:
James Kanze <james.ka...@gmail.com> wrote:
The question is more: do you want to. Should the code between
the provider and the consumer need to know about all of the
possible interfaces, as long as the provider and the consumer
are in agreement?
How do you know that the provider and the consumer are in
agreement? Or to put it another way, the fact that
dynamic_cast is in the code shows that the provider may very
well give the consumer something it can't consume (i.e., they
aren't in agreement.)
No, I don't think the transporting code should necessarily
know what it is transporting, but just like in the real world,
consumers shouldn't have to open the box after receiving the
item to see if it is really what they asked for either.
Agreed, but you can't really have it both ways. At least
dynamic_cast is like finding a detailed inventory at the top of
the box when you open it (or arguably, in an envelop pasted to
the outside of the box).
I can see it now. I order some RAM for my computer, and the producer
ships me 30 boxes for which I have to check each invoice to see if it is
what I *really* want, shipping the others back to the producer... How
about this instead. I ask for type X and I get type X?
And you still haven't responded to Juta's question about what
you do when the transporter is managing several different
producer/consumer relationships, using different types, and the
order is significant.
I also haven't answered what a designer should do if all his classes
derive from Object and all his pointers are Object*, forcing him to
dynamic_cast every time he wants to call a member-function. There are
uncountable numbers of designs that would require dynamic_cast. If the
design requires you to use dynamic_cast, then (as I've said before) use
it. But IMHO, the design could have been better.
And so on. The fact remains that I've found cases where
dynamic_cast was justified, in the sense that it was more cost
efficient than the alternatives. (With cost being measured in
program readability and maintainability, which basically end up
the equivalent of monitary cost in the end.)
This is simply a difference of experience I guess. I'm certainly not
going to second guess your sense that dyanic_cast is justified, all I
can say is that I have never found a case in OO code where it is.