RE: [Freeorion-programmers] UniverseObject

[Zach L. <wha...@ho...>]

> > you've introduced the need for much more runtime type checking when 
>looking
> > at an arbitrary UniverseObject.
>
>I not sure if i see your point.

The point is that a bunch of dynamic_cast's is inefficient, and is not the 
way the language was intended to be used; virtual methods should be used in 
place of explicit runtime type checking whenever possible.


> > For instance, under your recommendation, if you are looking at a 
>container
> > of pointers to UniverseObjects (which is the normal way of looking at
> > UniverseObjects), you would need to figure out which type of object it 
>is in
> > order to see what owner(s) it has, if any.
>
>I don't think you will go blind onto the UniverseObject list. You will 
>always be in a
>context in which you will know what kind of object you handle with (or only
>look for specific object-types) . For instance when doing the combat 
>preperation i
>look for Fleets by system->FindObjects(IsFleet).

I can't think of any places right now, but I'm reasonably sure that there 
are some places where mixed-type containers of UniverseObjects are being 
used in the manner I describe.

> > If we leave things as they are now, you can go through all the items in 
>your
> > container, and if Owners().empty() is true, you know that the object has 
>no
> > owners, and otherwise you can get the list of owners the same way from 
>each
> > object.
>
>What will you do with this information. I really see no use in that.

For instance, during the movement phase between turns, it is far easier, 
more efficient, and a more correct use of C++ to keep MovementPhase() in 
UniverseObject and virtual, to call UniverseObject::MovementPhase() on every 
object in the Universe, and have the ones that cannot move (e.g. Systems) do 
nothing. The alternative is to have MovementPhase() only in the classes that 
move, dynamic_cast each object multiple times to find out if it is an object 
of a class that has a MovementPhase() method, and only then call the method. 
  Similar arguments can be made for the other accessors and mutators in 
UniverseObject.


> > This is known as a "fat" interface, since the base class has some
> > information that only some of the derived classes need.  However, this
> > interface is really only a little chubby :), since it represents the
> > essential info that you would need to access in a container of arbitrary
> > UniversObjects.  Other more specific info is left to the individual 
>derived
> > classes (e.g. UniverseObjects don't have an IsArmed() method, like Ship
> > does).
>
>It's true that this interface is chubby (had to look it up :-)), but this 
>isn't my
>main point. It's the redundacy of information which might leed to 
>contradictions
>(at least to confusion, sample ownership Planet/System)

This is the main argument against fat interfaces.  I feel that the 
usefulness of those functions in the UniverseObject class (for all 
UniverseObject-derived types) warrants their placement there.  I only want 
to change UniverseObject's interface if there are good reasons, on a 
method-by-method basis.

Zach

_________________________________________________________________
What are the 5 hot job markets for 2004? Click here to find out. 
http://msn.careerbuilder.com/Custom/MSN/CareerAdvice/WPI_WhereWillWeFindJobsIn2004.htm?siteid=CBMSN3006&sc_extcmp=JS_wi08_dec03_hotmail1