Re: dynamic_cast is ugly!
On Mar 11, 12:49 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 10 Mar, 10:51, James Kanze <james.ka...@gmail.com> wrote:
On Mar 9, 5:09 pm, "Daniel T." <danie...@earthlink.net> wrote:
On Mar 9, 11:38 am, "H. S. Lahman" <h...@pathfindermda.com> wrote:
Responding to Nieminen...
The key is to not throw that information away. How you
pass that information from the creator to the user
depends on the situation.
I'm afraid this is just too vague to be of any help to me...
I think what Daniel T. is saying is that from a design perspective y=
ou
have two choices:
(1) Use separate homogeneous collections rather than heterogeneous
collections. Then the client who needs specific types of objects can=
navigate the appropriate relationship to the right collection.
(2) Provide the type information to the collection and provide an
interface to the collection that clients can access by providing a
desired type. Then the collection manages the {type, object} tuples =
in
its implementation.
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?
could *you* give a simple concrete example. Why don't you know
the type?
Because the middleware didn't provide it. Because the
middleware doesn't care about the type---it's just there to
ensure communication.
Because I have no control over what version of the software the
client is running. So I have to be prepared to handle two
different versions.
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.
yes
If the collection's job is to keep track of ordering
information,
what is "ordering information"? Z order? creation order?
The order of the requests?
then
that should be its only job. The consumer shouldn't be expected to use=
that collection to *also* get all objects of a particular type.
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.
but why would you want all the objects in certain order
unless you were going to apply a common operation to them?
Who knows? But it doesn't seem so unreasonable to me that
different operations may still require ordering between them.
If they don't all support the common operation why do you want
them?
Would the Visitor pattern be any use?
Maybe.
My point is just that there are a number of different tools
available, and no one tool is always the right one.
And how do you handle the different levels of
functionality?
for example?
The fact that the middleware doesn't know (and isn't supposed to
know) the services provided by the higher levels.
In large projects, the software tends to be structured very much
like network protocols. The IP layer doesn't know beans about
NNTP, and shouldn't. Similarly, the various layers that connect
the different components of a large application shouldn't know
beans about the services provided by those components.
--
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