Design question

Discussion in 'Java' started by jonck, Feb 25, 2005.

  1. jonck

    jonck Guest

    Hi,
    I have been struggling with this for days now, but it does not look
    like I'm going to figure it out. Here is the situation:

    I have a class that stores values that it read in from a database, lets
    call this class Storage. I display this data using a JPanel (which I
    will call DisplayPanel) with several JTextFields, JComboBoxes, JPanel's
    with pictures drawn on them, etc... So in other words, when the user
    selects a new record, the DisplayPanel loads in a new Storage class,
    and calls all the getters of Storage, something like this:
    getFirstNameTextField().setText(storage.getFirstName());
    getLastNameTextField().setText(storage.getLastName());
    getPicturePanel().drawPicture(storage.getPicture());

    etc...

    Now this is all fine, but now comes the time when the user has made
    some changes and I want to store those back into the Storage class.
    I now have to do the same thing again, but this time in reverse:
    getStorage().setFirstName(getFirstNameTextField().getText());
    getStorage().setLastName(getLastNameTextField().getText());
    getStorage().setPicture(getPicturePanel().getPicture());

    etc...

    Now there are about 20 fields per Storage class and I have about 10
    different types of Storage classes, so it seems kind of wasteful, very
    non-OOP and error-prone to be doing it as I described above. It seems
    like a pointer would be really useful here, so that I could just pass
    the pointer as the model value to the view, and then when the view is
    updated, the view can update the model, of which it has the pointer.
    But since Java is a pass-by-value language this won't work for me.

    Does anyone have any suggestions what a better way of doing things
    might be in the above described situation?

    Thanks, Jonck
     
    jonck, Feb 25, 2005
    #1
    1. Advertising

  2. jonck

    dar7yl Guest

    "jonck" <> wrote in message
    news:...
    > Hi,
    > I have been struggling with this for days now, but it does not look
    > like I'm going to figure it out. Here is the situation:
    >
    > I have a class that stores values that it read in from a database, lets
    > call this class Storage. I display this data using a JPanel (which I
    > will call DisplayPanel) with several JTextFields, JComboBoxes, JPanel's
    > with pictures drawn on them, etc... So in other words, when the user
    > selects a new record, the DisplayPanel loads in a new Storage class,
    > and calls all the getters of Storage, something like this:
    > getFirstNameTextField().setText(storage.getFirstName());
    > getLastNameTextField().setText(storage.getLastName());
    > getPicturePanel().drawPicture(storage.getPicture());
    >
    > etc...
    >
    > Now this is all fine, but now comes the time when the user has made
    > some changes and I want to store those back into the Storage class.
    > I now have to do the same thing again, but this time in reverse:
    > getStorage().setFirstName(getFirstNameTextField().getText());
    > getStorage().setLastName(getLastNameTextField().getText());
    > getStorage().setPicture(getPicturePanel().getPicture());
    >
    > etc...
    >
    > Now there are about 20 fields per Storage class and I have about 10
    > different types of Storage classes, so it seems kind of wasteful, very
    > non-OOP and error-prone to be doing it as I described above. It seems
    > like a pointer would be really useful here, so that I could just pass
    > the pointer as the model value to the view, and then when the view is
    > updated, the view can update the model, of which it has the pointer.
    > But since Java is a pass-by-value language this won't work for me.
    >
    > Does anyone have any suggestions what a better way of doing things
    > might be in the above described situation?
    >
    > Thanks, Jonck
    >


    Whatever gave you the idea that Java is pass-by-value?
    As far back as I can remember, it has been pass-by-reference
    for all object parameters.
    You can even consider all object variables to be pointers.
    (although you can't perform pointer arithmetic like C/C++)
    <code>
    Object obj = new Object();
    otherobj.method(obj); // obj is not copied, but passed by reference
    </code>

    so you could try:
    <code>
    class DisplayPanel extends Panel
    {
    String getFirstName()
    {
    return getFirstNameTextField().getText();
    }
    // ... more accessors

    void storeBack( Storage store )
    {
    store.setFirstName( getFirstName() );
    // ...
    }
    }
    </code>
    or
     
    dar7yl, Feb 26, 2005
    #2
    1. Advertising

  3. dar7yl coughed up:
    > "jonck" <> wrote in message
    > news:...
    >> Hi,
    >> I have been struggling with this for days now, but it does not look
    >> like I'm going to figure it out. Here is the situation:
    >>
    >> I have a class that stores values that it read in from a database,
    >> lets call this class Storage. I display this data using a JPanel
    >> (which I will call DisplayPanel) with several JTextFields,
    >> JComboBoxes, JPanel's with pictures drawn on them, etc... So in
    >> other words, when the user selects a new record, the DisplayPanel
    >> loads in a new Storage class, and calls all the getters of Storage,
    >> something like this:
    >> getFirstNameTextField().setText(storage.getFirstName());
    >> getLastNameTextField().setText(storage.getLastName());
    >> getPicturePanel().drawPicture(storage.getPicture()); etc...
    >>
    >> Now this is all fine, but now comes the time when the user has made
    >> some changes and I want to store those back into the Storage class.
    >> I now have to do the same thing again, but this time in reverse:
    >> getStorage().setFirstName(getFirstNameTextField().getText());
    >> getStorage().setLastName(getLastNameTextField().getText());
    >> getStorage().setPicture(getPicturePanel().getPicture());
    >>
    >> etc...
    >>
    >> Now there are about 20 fields per Storage class and I have about 10
    >> different types of Storage classes, so it seems kind of wasteful,
    >> very non-OOP and error-prone to be doing it as I described above. It
    >> seems like a pointer would be really useful here, so that I could
    >> just pass the pointer as the model value to the view, and then when
    >> the view is updated, the view can update the model, of which it has
    >> the pointer. But since Java is a pass-by-value language this won't
    >> work for me. Does anyone have any suggestions what a better way of doing
    >> things
    >> might be in the above described situation?
    >>
    >> Thanks, Jonck
    >>

    >
    > Whatever gave you the idea that Java is pass-by-value?
    > As far back as I can remember, it has been pass-by-reference
    > for all object parameters.


    *NO*

    Java is pass by value /only/. When you need to pass a reference you pass
    that reference BY VALUE.

    "Pass by Reference" has a completely different meaning in computer science.
    It has to do with whether or not using the formal parameter as the LHS of an
    equation will result in a change to the actual parameter.

    For example, in Java (a PBV language):

    public String method(String s) { s = "there"; }

    String str = "hello";
    method(str);
    // str is still "hello" here.

    If Java were PBR, then the str variable could have been changed to "there".



    > You can even consider all object variables to be pointers.


    I, like most long-time java guys, have to chuckle that there was never a
    NullReferenceException :)

    ....[rip]...



    --
    "I don't want FOP, God dammit! I'm a DAPPER DAN MAN!"
     
    Thomas G. Marshall, Feb 26, 2005
    #3
  4. jonck coughed up:

    ....[rip]...



    > [...] It seems
    > like a pointer would be really useful here, so that I could just pass
    > the pointer as the model value to the view, and then when the view is
    > updated, the view can update the model, of which it has the pointer.
    > But since Java is a pass-by-value language this won't work for me.



    You are correct that Java is pass by value only, but then so is C and C has
    pointers. You may be getting very confused as to what "pass by value" and
    "pass by reference" mean.

    In any case, for the time being you can think of references as a pointer
    upon which you can perform no pointer arithmetic. If you like, you can
    think of it as a pointer that always points to the very beginning of some
    object (or null). That's not a very strict definition, and I said it that
    way to not confuse you.

    If you would like some help, and/or examples, feel free to email me.

    If you want to understand the meaning and differences of the "pass by"
    terminology, you can try here, which discusses why java and C are pass by
    value:

    http://javadude.com/articles/passbyvalue.htm


    ....[rip]...




    --
    "I don't want FOP, God dammit! I'm a DAPPER DAN MAN!"
     
    Thomas G. Marshall, Feb 26, 2005
    #4
  5. I suggest that you check out Karsten Lentzsch's free open source binding
    library at http://www.jgoodies.com/downloads/libraries.html. He's got a
    consistent approach to binding data to presentation code that has
    simplified my gui programming immensely.

    Dave Neuendorf

    Thomas G. Marshall wrote:

    >jonck coughed up:
    >
    >...[rip]...
    >
    >
    >
    >
    >
    >>[...] It seems
    >>like a pointer would be really useful here, so that I could just pass
    >>the pointer as the model value to the view, and then when the view is
    >>updated, the view can update the model, of which it has the pointer.
    >>But since Java is a pass-by-value language this won't work for me.
    >>
    >>

    >
    >
    >You are correct that Java is pass by value only, but then so is C and C has
    >pointers. You may be getting very confused as to what "pass by value" and
    >"pass by reference" mean.
    >
    >In any case, for the time being you can think of references as a pointer
    >upon which you can perform no pointer arithmetic. If you like, you can
    >think of it as a pointer that always points to the very beginning of some
    >object (or null). That's not a very strict definition, and I said it that
    >way to not confuse you.
    >
    >If you would like some help, and/or examples, feel free to email me.
    >
    >If you want to understand the meaning and differences of the "pass by"
    >terminology, you can try here, which discusses why java and C are pass by
    >value:
    >
    >http://javadude.com/articles/passbyvalue.htm
    >
    >
    >...[rip]...
    >
    >
    >
    >
    >
    >
     
    Dave Neuendorf, Feb 26, 2005
    #5
  6. Re: Design question -- side comment on passing by reference

    Thomas G. Marshall wrote:

    >If you want to understand the meaning and differences of the "pass by"
    >terminology, you can try here, which discusses why java and C are pass by
    >value:
    >
    >http://javadude.com/articles/passbyvalue.htm
    >
    >
    >...[rip]...
    >
    >

    Of course you're right; the issue is admirably explained on the site you
    recommended. Just for fun, though, using the author's litmus test of
    trying to write a swap() method in Java, what if we redefine equals()
    and hashCode() on the class (a pointer to an instance of which is) being
    passed, so that object identity is determined by the values of its
    instance variables. In our swap method, we could exchange the guts of
    the two instances, thereby swapping their identities. It seems that we
    could get most of the way to passing by reference (though '==' would
    give results inconsistent with the equals() method). But I guess this
    kind of thing is best left to the Java obfuscation people.

    Dave Neuendorf
     
    Dave Neuendorf, Feb 26, 2005
    #6
  7. Re: Design question -- side comment on passing by reference

    Dave Neuendorf coughed up:
    > Thomas G. Marshall wrote:
    >
    >> If you want to understand the meaning and differences of the "pass
    >> by" terminology, you can try here, which discusses why java and C
    >> are pass by value:
    >>
    >> http://javadude.com/articles/passbyvalue.htm
    >>
    >>
    >> ...[rip]...
    >>
    >>

    > Of course you're right; the issue is admirably explained on the site
    > you recommended. Just for fun, though, using the author's litmus test
    > of trying to write a swap() method in Java, what if we redefine
    > equals() and hashCode() on the class (a pointer to an instance of
    > which is) being passed, so that object identity is determined by the
    > values of its instance variables. In our swap method, we could
    > exchange the guts of the two instances, thereby swapping their
    > identities. It seems that we could get most of the way to passing by
    > reference (though '==' would give results inconsistent with the
    > equals() method). But I guess this kind of thing is best left to the
    > Java obfuscation people.



    Sure, and similar arguments about the 'guts' are made with regard to this
    subject. The swap() litmus test is flawed for this reason. Here is how I
    put it previously (self quoted, which is a fairly obnoxious thing to do
    :) ):

    even if you /had/ the ability to copy full contents of one
    object to another's reference, bit for bit, it would /still/
    be PBV because: Inside the method, the formal
    parameter when used as the LHS of an equation
    /cannot/ affect the actual parameter.

    That's the problem with the swap mechanism. The full-on swapping out of all
    the guts thing seems to "allow" it, when it doesn't.



    --
    "It eats you starting with your bottom". Botched
    translation of the demonic warning "From beneath, it
    devours", in Buffy the Vampire Slayer ~2003.
     
    Thomas G. Marshall, Feb 26, 2005
    #7
  8. jonck

    dar7yl Guest

    "Thomas G. Marshall" <>
    wrote in message news:O7TTd.70712$g16.64687@trndny08...
    > dar7yl coughed up:
    >> "jonck" <> wrote in message
    >> news:...
    >>> Hi,
    >>> I have been struggling with this for days now, but it does not look
    >>> like I'm going to figure it out. Here is the situation:
    >>>
    >>> I have a class that stores values that it read in from a database,
    >>> lets call this class Storage. I display this data using a JPanel
    >>> (which I will call DisplayPanel) with several JTextFields,
    >>> JComboBoxes, JPanel's with pictures drawn on them, etc... So in
    >>> other words, when the user selects a new record, the DisplayPanel
    >>> loads in a new Storage class, and calls all the getters of Storage,
    >>> something like this:
    >>> getFirstNameTextField().setText(storage.getFirstName());
    >>> getLastNameTextField().setText(storage.getLastName());
    >>> getPicturePanel().drawPicture(storage.getPicture()); etc...
    >>>
    >>> Now this is all fine, but now comes the time when the user has made
    >>> some changes and I want to store those back into the Storage class.
    >>> I now have to do the same thing again, but this time in reverse:
    >>> getStorage().setFirstName(getFirstNameTextField().getText());
    >>> getStorage().setLastName(getLastNameTextField().getText());
    >>> getStorage().setPicture(getPicturePanel().getPicture());
    >>>
    >>> etc...
    >>>
    >>> Now there are about 20 fields per Storage class and I have about 10
    >>> different types of Storage classes, so it seems kind of wasteful,
    >>> very non-OOP and error-prone to be doing it as I described above. It
    >>> seems like a pointer would be really useful here, so that I could
    >>> just pass the pointer as the model value to the view, and then when
    >>> the view is updated, the view can update the model, of which it has
    >>> the pointer. But since Java is a pass-by-value language this won't
    >>> work for me. Does anyone have any suggestions what a better way of doing
    >>> things
    >>> might be in the above described situation?
    >>>
    >>> Thanks, Jonck
    >>>

    >>
    >> Whatever gave you the idea that Java is pass-by-value?
    >> As far back as I can remember, it has been pass-by-reference
    >> for all object parameters.

    >
    > *NO*
    >
    > Java is pass by value /only/. When you need to pass a reference you pass
    > that reference BY VALUE.
    > "Pass by Reference" has a completely different meaning in computer
    > science. It has to do with whether or not using the formal parameter as
    > the LHS of an equation will result in a change to the actual parameter.
    >
    > For example, in Java (a PBV language):
    >
    > public String method(String s) { s = "there"; }
    >
    > String str = "hello";
    > method(str);
    > // str is still "hello" here.
    >
    > If Java were PBR, then the str variable could have been changed to
    > "there".


    Ok, I admit you are right there.
    My point is that all object declarations are references,
    and when you pass an object to a method, that object
    is not cloned, but the reference only (ie, pointer) is copied.

    Even in C/C++, if you pass-by-reference (using the &param form),
    a pointer to the location of the object is created and passed-by-value
    to the function. In Java, you cannot get the location of a variable.

    regards,
    Dar7yl
     
    dar7yl, Feb 27, 2005
    #8
  9. jonck

    jonck Guest

    Thank you all for your suggestions, I'm going to look into Karsten's
    binding library.

    Regards, Jonck
     
    jonck, Feb 27, 2005
    #9
  10. dar7yl coughed up:
    > "Thomas G. Marshall"
    > <> wrote in
    > message news:O7TTd.70712$g16.64687@trndny08...
    >> dar7yl coughed up:
    >>> "jonck" <> wrote in message
    >>> news:...
    >>>> Hi,
    >>>> I have been struggling with this for days now, but it does not look
    >>>> like I'm going to figure it out. Here is the situation:
    >>>>
    >>>> I have a class that stores values that it read in from a database,
    >>>> lets call this class Storage. I display this data using a JPanel
    >>>> (which I will call DisplayPanel) with several JTextFields,
    >>>> JComboBoxes, JPanel's with pictures drawn on them, etc... So in
    >>>> other words, when the user selects a new record, the DisplayPanel
    >>>> loads in a new Storage class, and calls all the getters of Storage,
    >>>> something like this:
    >>>> getFirstNameTextField().setText(storage.getFirstName());
    >>>> getLastNameTextField().setText(storage.getLastName());
    >>>> getPicturePanel().drawPicture(storage.getPicture()); etc...
    >>>>
    >>>> Now this is all fine, but now comes the time when the user has made
    >>>> some changes and I want to store those back into the Storage class.
    >>>> I now have to do the same thing again, but this time in reverse:
    >>>> getStorage().setFirstName(getFirstNameTextField().getText());
    >>>> getStorage().setLastName(getLastNameTextField().getText());
    >>>> getStorage().setPicture(getPicturePanel().getPicture());
    >>>>
    >>>> etc...
    >>>>
    >>>> Now there are about 20 fields per Storage class and I have about 10
    >>>> different types of Storage classes, so it seems kind of wasteful,
    >>>> very non-OOP and error-prone to be doing it as I described above.
    >>>> It seems like a pointer would be really useful here, so that I
    >>>> could just pass the pointer as the model value to the view, and then
    >>>> when
    >>>> the view is updated, the view can update the model, of which it has
    >>>> the pointer. But since Java is a pass-by-value language this won't
    >>>> work for me. Does anyone have any suggestions what a better way of
    >>>> doing things
    >>>> might be in the above described situation?
    >>>>
    >>>> Thanks, Jonck
    >>>>
    >>>
    >>> Whatever gave you the idea that Java is pass-by-value?
    >>> As far back as I can remember, it has been pass-by-reference
    >>> for all object parameters.

    >>
    >> *NO*
    >>
    >> Java is pass by value /only/. When you need to pass a reference you
    >> pass that reference BY VALUE.
    >> "Pass by Reference" has a completely different meaning in computer
    >> science. It has to do with whether or not using the formal parameter
    >> as the LHS of an equation will result in a change to the actual
    >> parameter. For example, in Java (a PBV language):
    >>
    >> public String method(String s) { s = "there"; }
    >>
    >> String str = "hello";
    >> method(str);
    >> // str is still "hello" here.
    >>
    >> If Java were PBR, then the str variable could have been changed to
    >> "there".

    >
    > Ok, I admit you are right there.
    > My point is that all object declarations are references,
    > and when you pass an object to a method, that object
    > is not cloned, but the reference only (ie, pointer) is copied.
    >
    > Even in C/C++, if you pass-by-reference (using the &param form),
    > a pointer to the location of the object is created and passed-by-value
    > to the function.


    But that facility in C++ is *still* not PBV. /Behind/ the scenes a PBR
    language is fully allowed to pass or not pass anything it likes. So even
    though behind the scenes a ptr is passed, the syntactic sugar of allowing

    <formal param> = <value> // alters <actual param>

    is still there, and hence, still pass-by-reference.




    > In Java, you cannot get the location of a variable.
    >
    > regards,
    > Dar7yl




    --
    "His name was Robert Paulson. His name was Robert Paulson. His name was
    Robert Paulson..."
     
    Thomas G. Marshall, Feb 27, 2005
    #10
    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. ZackS
    Replies:
    5
    Views:
    6,805
    Just an Illusion
    Jul 9, 2004
  2. SpamProof
    Replies:
    3
    Views:
    650
    SpamProof
    Dec 1, 2003
  3. dave
    Replies:
    5
    Views:
    596
    William Brogden
    Jul 17, 2004
  4. Tim Smith
    Replies:
    2
    Views:
    855
    Tim Smith
    Dec 15, 2004
  5. Bartholomew Simpson

    class design/ design pattern question

    Bartholomew Simpson, Jun 12, 2007, in forum: C++
    Replies:
    2
    Views:
    452
    Daniel T.
    Jun 12, 2007
Loading...

Share This Page