Re: dynamic_cast is ugly!
Juha Nieminen <nospam@thanks.invalid> wrote:
Daniel T. wrote:
another would be to have a virtual function in Shape that
lets Shapes know that a "change rectangles to yellow" request
has been made.
That's exactly what I asked how to do...
You don't know how to make a virtual function in a base class?
You want me to add a virtual function named "changeSquareColor" to
the Shape base class if I want to be able to change the color of
squares?
Not at all, that would be a silly name.
That breaks object-oriented design quite horribly. For one, it
breaks the "is-a" relationship. More precisely, it breaks the
"behaves like" property of an "is-a" relationship: If you specify
that "Shape" supports the functionality "changeSquareColor", you
are effectively saying that *all* classes derived from Shape
support that functionality. However, only one does, the others
don't.
Is that really the case? Let's ignore the silly name for a bit and ask
something more important... What is the post-condition of this function?
I would expect the post-condition to be simply "true", i.e., the
function guarantees to return, but nothing else. Since no behavior is
prescribed, I don't see how any "behaves like" property could be broken.
So, why would a client call this function on the shapes in question? To
let them know of a particular event, *not* in order to tell them what to
do. When designing an OO system, it is better to decentralize your
thinking, try to treat each object has a semi-autonomous,
anthropomorphic entity, instead of a billiard ball you are banging
around. The is the basic design behind the observer pattern, notify
others of your state changes rather than telling them what state to
change to.
Is this particular design the best solution for this particular problem?
Probably not, but it does suit other problems where dynamic_cast is used.
The base class would be cluttered with functions specific to some
derived classes.
Absolutely not. I don't recommend putting functions in the base class
that relate to derived classes. I recommend putting functions in the
base class (interface) that relate to client classes.
And besides, in some cases you *can't* modify the base class (eg.
because it's in a library).
As I said more than once, if you are forced by the current design to use
dynamic_cast, then by all means use it.