RE: [Algorithms] "Entity" data structures

[Michael P. <MPo...@cy...>]

Of course the internal represenation of Width & Height is changed --
it's a different type of object!  (The relationship is HAS-A, not IS-A.)
Unless you don't a container, and are simply overloading the behaviour
of 2DObject??

I don't see the problem with a container, having the same function
naming as an atomic entity. If it really is an issue, I would change the
container names to be something different.

i.e.
class 2DObjectContainer
{
   float _nCachedWidth;
   float _nCachedHeight;

   GetContainerWidth()  // some people might find GetWidth() ambigious
with 2DObject
   GetContainerHeight() // ditto for GetHeight()
}

Maybe I'm being dense, but I don't see why you would end up with
duplicated states.

Cheers


-----Original Message-----
From: mark_me [mailto:ma...@so...]=20
Sent: Wednesday, April 10, 2002 4:09 AM
To: gda...@li...
Subject: RE: [Algorithms] "Entity" data structures

here you might think that all objects should have the states Width and
Height , so why don't we share them in the base class and access them
through non-virtual functions ? it looks reasonable in the beginning.
Then during development , you find that you want to have a 2D Object
that has multiple 2DObjets in it ( a composite object ), here the
internal representation of Width and Height is changed , it becomes the
width and height of the area=20
covered by the smaller objects of the composite object. You still can
use Width and Height variables to cache the calculated width and height
of that area , but then they have to be mutable otherwise you will end
up with duplicated states which is very bad. This is a simple example ,
in big projects things become much more nasty , and the maintenance of
the expanded code becomes a nightmare.