Linking objects...

  • Thread starter Thread starter Doogman
  • Start date Start date
D

Doogman

I have some questions about performance efficiency in C# on compact
framework in relation to Object design.

Lets say I am creating two classes, Car and Wheel.

Now, is it better performance to create a variable of WheelID in both
classes and use that ID as an index to wheel when needed? Or should I
create a Wheel object in Car?

I would think that it is much better design to go with option 2, but what
if I wanted to change all occurences of Wheel in all Cars? Would it not
be more efficient to change a particular WheelID that is referenced by
all cars than to parse all Cars for that particular Wheel and change each
and every occurence? That way on any retrieval of WheelID x, the change
would be reflected. Also, wouldn't this improve storage efficiency on
small devices?

Visually it is like Object Oriented Design versus a Database Relationship
design if you will. Indexing vs Objects.

Any and all input is appreciated and I hope you get what I am trying to
understand.

doogman
 
Hi Doogman,

Due to the limitiations of the hardware we are dealing with, I tend to lean
towards intancing of the objects as long as it does not clutter the design
too much. For example, I have a game demo with bitmaps that are shared by
numerous objects in the world. It is much more efficient to have a list of
bitmaps and then instance them (so they share the same bitmap object) than
to add a bitmap object to each world object. I have not seen any
significant performance speed issues regarding either implementation.

It only gets messy when you have some data that should be instanced and some
that should be unique in the same class. In the example of my game, I have
animations that share bitmaps but have unique information about which cell
they are displaying, animation rate, etc. To accomplish this, I use a list
of bitmaps that are shared by the animations, then create a new instance of
an animation for each object.

You could also have a list of Wheel objects and then each Car could have an
instance to a Wheel instead of an ID. If the objects are classes then they
are passed as references so no extra memory is used:

class Wheel { ... }
class Car
{
Wheel m_wheel; // This is a reference
}

--
Geoff Schwab
Program Manager
Excell Data Corporation
http://msdn.com/mobility
http://msdn.microsoft.com/mobility/prodtechinfo/devtools/netcf/FAQ/default.aspx

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Well, it depends on what you like to do.

1)
Say you have a set of "Wheels" (because you sell wheels). Those wheels has
some information that is global (size, weight, price, ...). Now you have
another list of "Cars". You like to _link_ them so that you know, which
wheels are for which car.

Now i would make it like Geoff wrote: reference them!
Make a list of wheel objects and store them as you like. In the Car-Object
you will have a reference to one (or more - if you use a list) wheels.

That's nearly the same as you would store own wheel-objects (class is
class...) but you shouldn't create new objects (MyCar.MyWheel = new
Wheel()) but refence them (MyCar.MyWhae = WheelList[5])

2)
If you have Wheels that will JUST fit for a single car or if theres a lot
of car-dependend information - then i would create a new object for each
wheel for each car. This should not be slower and shouldn't need more
memory because either way you need to create wheel-objects for each car and
store them somewhere!

The PRO when using objects is, that you always have your information
together where you need it.
The CON would be, if you need just a list of wheels then you may have a
problem because you need to scan all cars... but this depends on how you
store the data!

When you work with SQL-Database, you can of course have a table with Wheels
and a table with Cars. Then you have IDs to know which wheel is for which
car (or you have a link-list CarWheel if there are more wheels for each
car)... this way you can read just the cars, just the wheels or let the
car-object load all wheel-objects for itself... ect.

Boris
 
Well, it depends on what you like to do.

1)
Say you have a set of "Wheels" (because you sell wheels). Those wheels
has some information that is global (size, weight, price, ...). Now
you have another list of "Cars". You like to _link_ them so that you
know, which wheels are for which car.

Now i would make it like Geoff wrote: reference them!
Make a list of wheel objects and store them as you like. In the
Car-Object you will have a reference to one (or more - if you use a
list) wheels.

That's nearly the same as you would store own wheel-objects (class is
class...) but you shouldn't create new objects (MyCar.MyWheel = new
Wheel()) but refence them (MyCar.MyWhae = WheelList[5])

2)
If you have Wheels that will JUST fit for a single car or if theres a
lot of car-dependend information - then i would create a new object
for each wheel for each car. This should not be slower and shouldn't
need more memory because either way you need to create wheel-objects
for each car and store them somewhere!

The PRO when using objects is, that you always have your information
together where you need it.
The CON would be, if you need just a list of wheels then you may have
a problem because you need to scan all cars... but this depends on how
you store the data!

When you work with SQL-Database, you can of course have a table with
Wheels and a table with Cars. Then you have IDs to know which wheel is
for which car (or you have a link-list CarWheel if there are more
wheels for each car)... this way you can read just the cars, just the
wheels or let the car-object load all wheel-objects for itself... ect.
Click to expand...

Excellent description from both that have responded. Thats exactly what I
was needing to hear. I usually to setup the objects as reference, and
thus no memory is sacrificed. I would imagine with a well thought out
storage structure, that changes will not be a very big problem either.

Thanks again for the help!
doogman
 
Back
Top