Re: dynamic_cast is ugly!
On 14 mar, 18:14, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
On Mar 13, 6:48 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
Juha Nieminen wrote:
Daniel T. wrote:
Juha Nieminen <nos...@thanks.invalid> wrote:
I have asked for a better design like ten times and got
nothing. What can I deduce from that?
Somehow, I feel that this discussion is suffering from the
lack of a concrete non-trivial case. We would need to have
some more or less real-life OO component (say a library)
before us which either (a) uses dynamic_cast in its
implementation or (b) might require client code to use
dynamic_cast. Then, the challenge would be to present a
functionally equivalent (i.e., at least equally powerful)
replacement that doesn't do so.
The problem is that dynamic_cast is really only justified in
fairly large applications, where layering becomes an important
issue. As long as you can manage the entire application as a
single layer, it is possible to avoid "loosing" type (or at
least, I've not seen an exception). It's when you start having
to define separate layers, frameworks and such, that it becomes
important.
The suggestion that dynamic_case is necessary for passing
application-layer objects through lower level transport layers
is only marginally true. It is true that casts are used for
this purpose, but IME they are almost always of the
reinterpret_cast variety.
That very much depends on the transport layer, I would think.
They have to be: A general-purpose transport layer does not
know about the higher layer's object types.
And a specialize transport layer only knows a little. It
doesn't take much specialization to ensure that all of the
objects transported have a common base (i.e.
TransportableObject?), and are polymorphic.
The transport mechanism is just sending bits over a wire,
Maybe, maybe not. There's not necessarily a wire; it's sending
objects between to components. There are many different types
of transport layer. (And even if there is a wire, many
protocols will have all transportable objects derive from some
common base type, or a small set of common base types.)
or at most doing some kind of byte-order or line-ending
conversion.
I think you're confusing the transport layer of OSI network
protocols (TCP, etc.) with the transport layer of OO design.
For dynamic_cast to be relevant, the transport mechanism has
to know about some base type used by the higher level. The
only case in which I could see this happening is if the
transport layer provides a base type with virtual methods,
maybe "serializable_object" or something, from which
higher-layer objects are supposed to derive. IMO, that kind
of design is completely upside-down and unnecessarily
invasive.
Why? If you want an object to be transportable, you say so. It
seems to me to be part of the basic principles of static type
checking. You're transporting message objects between higher
level components which have connected to the transport layer.
You don't (and can't) transport just anything.
--
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