V
Veloz
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
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