Results 1 to 7 of 7
  1. #1
    jlowery2663 is offline Member
    Join Date
    Aug 2009
    Posts
    4
    Rep Power
    0

    Question Multiple references to the same object

    This smells bad to me:

    I have a data object. That data object is referenced by a class field in the parent container, and a class field in some of its children.

    ALSO, the children have the data object referenced in a superclass field, as well as a field in the child class (down cast type).

    So, I have multiple references to the same data object in 1) the containment heirarchy; 2) the class heirarchy.

    This seems like asking for trouble, as someone will miss updating one of these references someday. My natural inclination is to use a hashmap to tie one data reference to muliple class instances, like: <data>::<list of referrers>, but that doesn't really work for finding an instance's data object (does work for updating the data instance of all referrers, though).

    There must be a simple solution to this, but I'm in a brain fog today.

  2. #2
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    7

    Default

    What do you mean by parent container?
    If you have multiple references to the same object then updating the object through one of the references makes the updates visible to the other references. Perhaps if you post your code it may become clearer what you are talking about.

  3. #3
    jlowery2663 is offline Member
    Join Date
    Aug 2009
    Posts
    4
    Rep Power
    0

    Default

    Object m contains instance z (has field == z)
    Class Y is a superclass of z.class

    m, y, and z have field data.

    m.data = y.data = z.data = instance d;

    I could use a final ReferenceHolder for all data fields:

    A.RH(d); z.RH(d); y.RH(d); where A.RH == z.RH == y.RH. If d changes in RH, then all referents are 'updated'.

  4. #4
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    7

    Default

    You only need one of those instances then! You are failing to identify inheritance and composition.
    The data only needs to be in class Y.

    Z doesn't need to re-declare because Z is-A Y "Class Y is a superclass of z.class".
    M does not need to re-declare it as well because M has-A Z which already has the d.

  5. #5
    jlowery2663 is offline Member
    Join Date
    Aug 2009
    Posts
    4
    Rep Power
    0

    Default

    First of all, you are making the assumption that I wrote this code-- I didn't. I'm looking at legacy code and trying to figure out the best way to refactor it.

    Z redeclares a field because it wants that field to be a subclass of d. Personally, I'd use a getter function that returns the subclass type of d (down cast occurring in the getter). One other possibility is to refactor the existing accessor method to take an array of a (subclassed) type, which would serve as a holder to the d in the parameter list. Probably best to just create a new method with a new name, rather than fiddle with parameter list signatures in that way.

    I disagree with you about placing sole declaration of d in Z. This makes the container responsible for knowing what children it contains and where to locate d amongst it's children. It is more acceptable to have the child know how to navigate up the tree, as that's a path less likely to change. However, it still *could* change in the future (say an additional containment layer is inserted between M and Z), so that's an argument to place d somewhere outside the container heirarchy.

    I agree with you that is smells like there's some missing conceptual component here. Not sure what that is. Seems like an embedded datastore of some kind is needed, but if this is the only component, then I'm not sure the cost in additional complexity is worth it.

  6. #6
    mrmatt1111's Avatar
    mrmatt1111 is offline Senior Member
    Join Date
    Aug 2009
    Location
    San Jose, CA, USA
    Posts
    320
    Rep Power
    6

    Default

    "Seems like an embedded datastore of some kind is needed"

    That might work. You could give each object an Id and store the objects in a hashmap. It then does a quick look up on the id to grab the object. Then all you need to do is update it in one place, the hashmap (might need a blocking hashmap).

    I did something like that to manage resources that needed to be loaded and reloaded, that way i could load things at will or handle it if nothing was loaded yet or invalid a resource.
    My Hobby Project: LegacyClone

  7. #7
    jlowery2663 is offline Member
    Join Date
    Aug 2009
    Posts
    4
    Rep Power
    0

    Default

    Yeah, that's similar to a reference holder that sits outside the containment heirarchy. The double class heirarchy reference (super and subtype) can also be fixed this way, but it would probably be best to have the subtype navigate up the class heirarchy.

    The fact that I have this data object that's needed in three different contexts makes me wonder if the data class isn't overgeneralized. I haven't actually looked closely at what it contains.

Similar Threads

  1. Creating multiple local references & impact on performance
    By raki.seattle in forum Advanced Java
    Replies: 17
    Last Post: 09-05-2009, 02:39 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •