469,926 Members | 1,526 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,926 developers. It's quick & easy.

Associate Objects using domain ID or using object references?


Hiya
My question is whether or not you should associated related objects in
your software using a scheme of id's and lookups, or wether objects
should actually hold actual object references to objects they are
associated with.

For example, lets say you are modelling studen ratings of teachers.
Let's say your applications needs to analyze these ratings for
teachers and is provided a data file. In this data file the teachers
all have unique id's. Each studen'ts ratings of each teacher is listed
under an appropriate section for each student; these ratings carry the
teacher's ID so that you know what the rating is for.

Now, if you were to model this in software, it seems reasonable that
you might end up with a student class, which directly or indirectly
houses the student's ratings for the the teachers. And you would
probably end up with a teacher class and each teacher object would
carry the id assigned to it in the data file.

The question is this: in the class holding the ratings (e.g., the
student class), would you store ratings along with the teacher's ID or
would you actually store references to the proper teacher object?

On one hand, I like the id scheme because it mimics the domain a bit
more, possibly making the app easier to understand and debug (and
possibly to save off and restore state later? I don't know about this
yet).

On the other hand, if other objects "point to" feature objects by
holding their ID, you will probably have to do a feature-lookup by ID
to get the actual feature object so that you can interact with it.

I thought this issue was addressed by something called the "IDs versus
Objects" pattern, but I can't seem to turn up anything on that.

Any thouhgts on this topic would be greatly appreciated!!

Michael

Sep 21 '07 #1
2 1638
"Veloz" <mi**********@gmail.comwrote in message
news:11*********************@57g2000hsv.googlegrou ps.com...
>
Hiya
My question is whether or not you should associated related objects in
your software using a scheme of id's and lookups, or wether objects
should actually hold actual object references to objects they are
associated with.

For example, lets say you are modelling studen ratings of teachers.
Let's say your applications needs to analyze these ratings for
teachers and is provided a data file. In this data file the teachers
all have unique id's. Each studen'ts ratings of each teacher is listed
under an appropriate section for each student; these ratings carry the
teacher's ID so that you know what the rating is for.

Now, if you were to model this in software, it seems reasonable that
you might end up with a student class, which directly or indirectly
houses the student's ratings for the the teachers. And you would
probably end up with a teacher class and each teacher object would
carry the id assigned to it in the data file.

The question is this: in the class holding the ratings (e.g., the
student class), would you store ratings along with the teacher's ID or
would you actually store references to the proper teacher object?

On one hand, I like the id scheme because it mimics the domain a bit
more, possibly making the app easier to understand and debug (and
possibly to save off and restore state later? I don't know about this
yet).

On the other hand, if other objects "point to" feature objects by
holding their ID, you will probably have to do a feature-lookup by ID
to get the actual feature object so that you can interact with it.

I thought this issue was addressed by something called the "IDs versus
Objects" pattern, but I can't seem to turn up anything on that.

Any thouhgts on this topic would be greatly appreciated!!
If the student object contains the teacher ID, then the teacher ID is not
required to even exist if it is not needed. Also, during serialization you
would not have to be concerned with the teacher object still existing at the
time the student object is output. So in the least the student object needs
to contain the teacher ID whether it is used as a key to the teacher object
or not during lookup.

Using maps a lookup is rather quick and simple to do, so it seems that it
wouldn't be too much of a burden to get a refernce to the teacher object as
needed.

The main concern I see with storing references to a teacher object is the
fact that the teacher object pointer can not then change. If the teacher
object changes in some manner (it's stored by value in a vector and the
vector is resized, sorted, etc...) the reference would become invalid, as I
understand it. Also, there may be a condition where you don't even have the
teacher object loaded and would only load it from DB as needed. If you are
doing this then you have to ensure that the teacher object that was loaded
remains in memory at the same location until the student object is
destructed.

I'm not in favor of storing pointers (or references) to instances in my
classes when it is not strictly needed, and when I do I try to limit them to
objects that are created once at the beginning of the program and are
destructed at the end (graphical engine interface, DB connection info,
etc...).

The problem with not storing a reference, however, now leads us to the
problem of how is the student object going to get access to the teacher
object as needed? But then again, why would the student class ever need
access to the teacher object to begin with? I would not make it the
responsibility of the student class to update the teacher class. I would
lead that responsibilty to either a containing class that kept lists of both
teachers and students, or in mainline.
Sep 21 '07 #2
On Sep 21, 7:10 pm, Veloz <michaelve...@gmail.comwrote:
My question is whether or not you should associated related objects in
your software using a scheme of id's and lookups, or wether objects
should actually hold actual object references to objects they are
associated with.
For example, lets say you are modelling studen ratings of teachers.
Let's say your applications needs to analyze these ratings for
teachers and is provided a data file. In this data file the teachers
all have unique id's. Each studen'ts ratings of each teacher is listed
under an appropriate section for each student; these ratings carry the
teacher's ID so that you know what the rating is for.
Now, if you were to model this in software, it seems reasonable that
you might end up with a student class, which directly or indirectly
houses the student's ratings for the the teachers. And you would
probably end up with a teacher class and each teacher object would
carry the id assigned to it in the data file.
In this simple case, you probably wouldn't even have a teacher
class. Just a teacher ID. You'd only need a teacher class if
the teacher had additional behavior, beyond it's ID.
The question is this: in the class holding the ratings (e.g., the
student class), would you store ratings along with the teacher's ID or
would you actually store references to the proper teacher object?
On one hand, I like the id scheme because it mimics the domain a bit
more, possibly making the app easier to understand and debug (and
possibly to save off and restore state later? I don't know about this
yet).
On the other hand, if other objects "point to" feature objects by
holding their ID, you will probably have to do a feature-lookup by ID
to get the actual feature object so that you can interact with it.
I thought this issue was addressed by something called the "IDs versus
Objects" pattern, but I can't seem to turn up anything on that.
I see what you're getting at, although I don't think your
example shows it. Basically: in memory navigation (from one
object to another) is best handled by pointers; in the end, the
only way you can access another object is if you have its
address in memory. (If you use a table, the result of the table
lookup is a pointer.) Pointers do NOT work for external
communication or persistency, however, or if the objects may
move in memory between transactions (frequently the case, if
e.g. the transaction actually operates on a copy, which is
swapped with the original in the commit phase). So the rule is
to use a pointer if it works, and id's otherwise, and not to
forget that when you do the table lookup, and get the pointer,
you have to lock the object in place as long as you hold the
pointer.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 23 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by user | last post: by
49 posts views Thread by Steven Bethard | last post: by
16 posts views Thread by Paul Rubin | last post: by
6 posts views Thread by Bryan Martin | last post: by
9 posts views Thread by Aguilar, James | last post: by
reply views Thread by Nashat Wanly | last post: by
25 posts views Thread by Penelope Dramas | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.