Associate Objects using domain ID or using object references?

Discussion in 'C++' started by Veloz, Sep 21, 2007.

  1. Veloz

    Veloz Guest

    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
     
    Veloz, Sep 21, 2007
    #1
    1. Advertising

  2. Veloz

    Jim Langston Guest

    "Veloz" <> wrote in message
    news:...
    >
    > 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.
     
    Jim Langston, Sep 21, 2007
    #2
    1. Advertising

  3. Veloz

    Kai-Uwe Bux Guest

    Veloz wrote:

    >
    > 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.


    Actually, I probably would not. In this problem, of analysing the data, I do
    not see, why teachers and students need to be objects. They seem not
    involved. For instance, I do not see, how a method like

    class student {
    ...
    void rate_on_clarity( teacher & t, course & c );

    };

    could be useful: after all, we do not want to _simulate_ the creation of the
    data, we want to analyse them. Students and teachers are not agents in that
    process.

    Instead, I see the individual ratings as the basic entities in the program.
    So, I would, maybe, end up with a ratings class like so:

    // NOTE: [if necessary, replace by a copy_on_write string]
    typedef std::string teacher_id;
    typedef std::string student_id;
    typedef std::string course_id;

    class rating {

    teacher_id the_teacher;
    student_id the_student;
    course_id the_course;

    float teachers_clarity;
    float teachers_enthusiasm;
    ...
    std::string some_comment_field;
    ...

    };

    The reason to have a rating class is that this one might actually need to be
    polymorphic: the university has some questions it wants asked, the colleges
    adds some questions of their own, then departments may make amendmends, and
    finally teachers might ask their favorite question, too. So, I would expect
    that the data sets I get are not uniform across courses. That could be
    modelled using derivation.

    To analyse the data, now you would need a data structure that allows
    efficient retrieval along each teacher_id, student_id, and couse_id. At
    that point, I would probably read the documentation of
    Boost::multi_index :)


    [snip: the actual question, on which I have nothing to say (sorry)]


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Sep 22, 2007
    #3
  4. Veloz

    James Kanze Guest

    On Sep 21, 7:10 pm, Veloz <> wrote:

    > 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:
    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
     
    James Kanze, Sep 23, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Angel
    Replies:
    2
    Views:
    592
    Kikoz
    Dec 26, 2003
  2. Wolfram Kraus

    Associate objects with Tix.Tree

    Wolfram Kraus, Jan 15, 2005, in forum: Python
    Replies:
    0
    Views:
    396
    Wolfram Kraus
    Jan 15, 2005
  3. itaj sherman
    Replies:
    1
    Views:
    302
    Daniel Pitts
    Feb 25, 2009
  4. James Allsopp
    Replies:
    11
    Views:
    464
    gwowen
    Apr 9, 2010
  5. Jack Bates
    Replies:
    3
    Views:
    309
    Steven D'Aprano
    Aug 6, 2011
Loading...

Share This Page