Re: dynamic_cast is ugly!
On Mar 11, 2:06 am, "Daniel T." <danie...@earthlink.net> wrote:
James Kanze <james.ka...@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.
Sorry, but I fail to see any difference between having the
producer provide type information, and having the compiler do it
for him. In the end, it boils down to the same thing, except
that 1) having the producer do it explicitly is more work for
the programmer, and 2) the producer can lie.
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 article didn't mention "mutable", but all of the examples
and the reasoning it applied only applied to mutable.
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.
Agreed. You tell it to do something. In practice, however,
objects may pass through many layers of intermediate software,
which knows nothing about (or should know nothing about) what
services the provider actually offers, and what services the
consumer needs. In practice, however, real software often has
to deal with different versions: you must query whether your
partner supports some new functionality, and be prepared to use
an alternate strategy if it doesn't. Those are, IMHO, two cases
where dynamic_cast is called for---in the first case, it
actually helps design (by encapsulating the functionality at the
relevant level).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34