Re: dynamic_cast is ugly!
On 8 mar, 23:32, "Daniel T." <danie...@earthlink.net> wrote:
James Kanze <james.ka...@gmail.com> wrote:
"Daniel T." <danie...@earthlink.net> wrote:
I don't agree that dynamic_cast has its place in *good* OO
design, but it does have its place.
You're obviously using a different definition of OO than I am,
then. Generally speaking, IMHO you should access the object
through defined interfaces; whether they are in the concrete
class, or in an abstract base class, isn't that important in the
absolute, but there will definitely be cases where a concrete
class will want to implement an extended interface. In an ideal
world, in such cases, you wouldn't loose the type, and you'd
always have access to the extended interface.
It sounds like we aren't that far apart after all. Sometimes
dynamic_cast is necessary, but designing your framework so
that one must use dynamic_cast to use it properly... It
doesn't sound like you would approve of such a design.
It depends on the context. Making some intermediary aware of
all of the details of what it transporting isn't something I'd
approve of either. (The context was Java Swing, and not C++,
but I've used very generic code for linking up application
specific actions and the buttons in toolbars, etc.)
What is bad, of course, is a long list of:
if ( dynamic_cast< Concrete1* >( p ) ) {
// ...
} else if ( dynamic_cast< Concrete2* >( p ) {
// ...
} else if ( dynamic_cast< Concrete3* >( p ) {
}
I don't find anything particularly bad, however, in the idea
that some concrete types support an extended interface, and that
the ultimate user might do something like:
Extended* px = dynamic_cast< Extended* >( p ) ;
if ( px != NULL ) {
// use the extended interface, e.g. to get more
// information...
} else {
// carry out some default action...
}
Think for a moment about Smalltalk---the granddaddy of OO
languages.
Even in Smalltalk, sending a message to an object without
knowing if the object will understand the message is frowned
upon.
Certainly. But in Smalltalk, you could also ask the object if
it understood the method, and do something by default if it
didn't. (But I prefer the C++ solution, where you have to ask
the object if it supports a specific extended interface, and not
just whether it happens to have a method with the targetted
name.)
I'm not going to pretend that the matter is settled. There is
a regular debate in comp.object over whether designs that
require down-casting are appropriate, but I think it is fair
to say that it isn't *necessary*, and I happen to believe that
it *isn't* appropriate.
I would say rather that it is associated with a certain "cost"
(in terms of readability and maintainability), and shouldn't be
used unless the alteratives have a greater cost.
Which is why, when the Andy asked how often I use it, I said
"never," and when he asked why not, I said that I don't use it
because I design my code such that its use isn't necessary.
Well, I don't use it very often, but there are times when the
alteratives involve even greater cost.
--
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