Re: dynamic_cast is ugly!
In message <0FSBj.7629$y83.2338@trndny06>, H. S. Lahman
Responding to Herring...
So now you have to expose that attribute, and the client has to have
access to the ordering relation which was previously encapsulated in the
It is a problem space property that is important to the requirements
and software solution. It is abstracted as an intrinsic knowledge
attribute of an object. That is basic problem OOA space abstraction.
Yes, but _which_ object? According to you (and I agree) the ordering
should be the responsibility of the collection.
I also don't follow how it was previously encapsulated in the
collection; the type, which includes the size property, is fully
exposed in the dynamic_cast solution.
No. The _ordering relation_ is not exposed by the dynamic_cast. The
client has no reason to know whether it's "less" or "greater", or
something more complicated calculated by an oracle from multiple
properties of the object, or even some abstraction not present _in_ the
object at all, such as its position in an external database. All the
client needs to know is that the objects will be presented in the
The "size" property was _your_ invention for the purpose of argument.
And even if the ordering is in fact as simple as comparing a simple
property, the property might be part of a different interface that the
dynamic_cast doesn't expose.
And if the number of collections increases beyond two, that "simple
interleaving" doesn't scale well, as it starts to look more and more
like a complete (partial) sort, so really the client, not the
collection, is now responsible for the ordering.
I disagree that it doesn't scale well because the number of machine
instructions executed is going to be essentially the same in either
But their location is not. It's is now distributed over more lines of
code, with more maintenance overhead. In your solution the class which
should be responsible for the ordering (the collection) has passed some
of the buck back to the client.
but let's not go there.
The relevant point to the thread is that the client checks the size
attribute rather than the object type via dynamic_cast.
My point is that the implementation detail of the ordering should be
encapsulated within the collection, not exposed to the client.
Making flow of control decisions based on problem space properties will
always be more robust during maintenance than making such decisions on
3GL implementation properties. The goal is to make the application more
maintainable and avoid foot-shooting; not elegance, reduced keystrokes,
minimizing static structure, or even being convenient for the developer.
Are you really suggesting that there's no correlation between "elegance,
[...] convenient for the developer" and "more maintainable"?