Design question

[jonck]

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

 

[dar7yl]

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

 

[Thomas G. Marshall]

dar7yl coughed up:

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

 

[Thomas G. Marshall]

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]

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

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]

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

 

[Thomas G. Marshall]

Dave Neuendorf coughed up:

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.

 

[dar7yl]

dar7yl coughed up:

*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

 

[jonck]

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

Regards, Jonck

 

[Thomas G. Marshall]

dar7yl coughed up:

"Thomas G. Marshall"


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.