Re: dynamic_cast is ugly!
James Kanze <james.kanze@gmail.com> wrote:
"Daniel T." <danie...@earthlink.net> wrote:
Actually, I'm advocating choice 3:
Have the producer provide the type information directly to the
consumer, this doesn't necessarally have to be through the
collection.
Isn't this exactlly what dynamic_cast does?
No, dynamic_cast punts. It's a query on object state.
What's the difference between a member function
"supportsInterfaceX()" and dynamic_cast< X* >. Except that
providing the member function means that the base interface must
know about the extended interface.
Nothing.
I don't think it is necessarally a good idea to put type
information in the collection, but it is a good idea to only
navigate relationships along the trajectory they were designed to
be navigated along (i.e., follow the UML arrows, don't try to
backtrack against them.) And, I think it is important to follow
the "tell, don't ask" principle.
(http://pragmaticprogrammer.com/articles/tell-dont-ask) Asking
the object its type and then telling the object to do something
based on the answer goes against this principle.
The problem with this is that it means that everything any derived
class supports must be known and declared in the base class.
No, it doesn't.
And how do you handle the different levels of functionality? What
happens if you tell an object to do something it's not capable of?
What happens is, you have a design error.
(Note that the article you site is mainly concerned with not
exposing mutable state, in order to reduce coupling.
The type of the object is part of the objects state. The word "mutable"
is nowhere to be found in the article. "as the caller, you should not be
making decisions based on the state of the called object that result in
you then changing the state of the object."
The idea is that you shouldn't be telling the object to do X, you
shouldn't be telling it to change its state to X, you should be telling
it about changes in its environment.