Let's say you have the following:
Book b = new Book();
Book c = new Book();
Two references, each referencing a respective object.
Then you create a third reference:
Book c = d;
First, do the references act like remote controls in that they actually affect the objects, personally, or does the JVM simply utilize the data from the references in regards to what each object does as it is referenced?
If it's the former, how does it work that two references do not conflict when controlling the SAME object? OR, is it that the two references simply act as their own individual selves AS IF there were actually two separate objects (even though, in fact, there's only one object twice referenced)?
Hope that makes sense. Besides all that, so far I'm getting object reference variables thus far.
The answer is: this varies by language and circumstances.
What you're really talking about is assignment by value vs. assignment by reference.
In Java, primitive types (think strings, numbers, etc.) are assigned by value.
x = 5;
y = x;
If you change y, it does not change the value of x, and vice versa--because they are assigned by value, not reference.
But suppose we are using your Book objects.
Book c = d;
This does not actually make a copy of "d". Instead, it says "take the memory location of object d, and assign it to object c." If you modify c or d, then the other object will also show those changes. What you think of as an object (the variables b, c, and d) is actually just a pointer to a memory location.
If, instead, you want c to be its own independent copy of d, you would use the "clone" method:
Book c = d.clone();
(Note that you may have to implement a "clone" method in the Book class to support this.)
Aslan safe? Of course He isn't safe. He's not a <i>tame</i> lion, you know? ... But He's GOOD.
Michael Miller Jr wrote:The following is a question I posted to my friend (via Facebook) who knows quite a bit about Java. The question posted is in response to the section "Life on the Garbage-Collectible Heap" in the book, "Head First Java", chapter 3.
Let's say you have the following:
Book b = new Book();
Book c = new Book();
Two references, each referencing a respective object.
Then you create a third reference:
Book c = d;
If it's the former, how does it work that two references do not conflict when controlling the SAME object?
The answer is: this varies by language
What you're really talking about is assignment by value vs. assignment by reference.
In Java, primitive types (think strings, numbers, etc.) are assigned by value.
But suppose we are using your Book objects.
Book c = d;
This does not actually make a copy of "d". Instead, it says "take the memory location of object d, and assign it to object c."
If you modify c or d, then the other object will also show those changes. What you think of as an object (the variables b, c, and d) is actually just a pointer to a memory location.
If, instead, you want c to be its own independent copy of d, you would use the "clone" method:
Book c = d.clone();
(Note that you may have to implement a "clone" method in the Book class to support this.)
For that matter - and perhaps this will be better explained later in the book - why would you want two references to the same object when changing the values in the reference will affect the other reference equally?
References don't contain objects. They refer to, or "point to" them.
I assume you mean Book d = c; I'm going to continue my answers based on that assumption.
First, do the references act like remote controls in that they actually affect the objects, personally, or does the JVM simply utilize the data from the references in regards to what each object does as it is referenced?
No idea what that question is supposed to mean. However, what Book d = c; does is copy the reference value from variable c into variable d, so that now both variables "point to" the same Book object.
What kind of conflict to you think there would be? Imagine you're holding two remotes that control the same TV. You use one to change the channel and the other to adjust the volume. So what? The TV doesn't know or care. All that matters to it is that it got one message about the channel and another message about the volume. It doesn't care where the messages came from, and the remotes don't know or care if some other remote is sending messages.
Well, yes, it definitely varies by language. We're talking about Java here though.
There are various cases where it's useful. For instance, if parameters are passed to a method or constructor, and you want to copy them to a member variable. The parameter ceases to exist when the method ends, but the member variables lives as long as the object does:
There are various cases where it's useful. For instance, if parameters are passed to a method or constructor, and you want to copy them to a member variable. The parameter ceases to exist when the method ends, but the member variables lives as long as the object does:
public class Person {
private String name;
public Person(String name) {
this.name = name; // now two reference variables point to the same Person object
} // now the "name" parameter no longer exists, but the member variable does
}
Aslan safe? Of course He isn't safe. He's not a <i>tame</i> lion, you know? ... But He's GOOD.
Michael Miller Jr wrote:Thank you, so much!
What the "remote" does is to interact with the object without ever actually touching the object, itself, yes?
The references do all the work and the object sorta "sits" there.
There are various cases where it's useful. For instance, if parameters are passed to a method or constructor, and you want to copy them to a member variable. The parameter ceases to exist when the method ends, but the member variables lives as long as the object does:
There are various cases where it's useful. For instance, if parameters are passed to a method or constructor, and you want to copy them to a member variable. The parameter ceases to exist when the method ends, but the member variables lives as long as the object does:
Okay, so... The private tag (correct term?) is putting the string name as a variable accessible only within the Person class. Nothing outside can reference or otherwise make use of it.
Then the Person object does...?
After the Person object is done, though, that parameter usage of name is done, as well.
...how'd I do?
In the real world, a physical remote and TV, yes. In Java, the notion of the reference "touching" or "not touching" doesn't have any meaning that I can imagine, so I'm not sure what you're trying to say.
If you're familiar with C and its pointers, you can imagine a reference as being like a C pointer--that is, being the address of an object.
Aslan safe? Of course He isn't safe. He's not a <i>tame</i> lion, you know? ... But He's GOOD.
Michael Miller Jr wrote:An objectReference.method() is, as you said, a pointer to the object and its method, as opposed to utilizing code that interacts more directly with the object (like actually getting up to push the TV's buttons.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
The main difference between "reference" (String, Object, List...) and "primitive" (char, int, byte...) types, as far as memory alone is concerned, is (a) where they are (or can be) created and (b) how they are handled when calling methods.
If I call a method somewhere in my code, eg:
doSomethingWith(x)
if 'x' is a primitive (say an int with a value of 3), then its value (3) is copied to the doSomethingWith method code.
if 'x' is a reference-type (say a String with a value of "3"), then its reference (ie, its memory address) is copied to the method code. In fact 'x' is a reference to the String, not the String object itself.
Jeff Verdegan wrote:Actually, in terms of how the JLS defines things, that's not quite accurate.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
What I was more interested in doing was explaining a bit of the mechanics of references, as opposed to primitives, to Michael, without getting too bogged down in JLS semantics.
Aslan safe? Of course He isn't safe. He's not a <i>tame</i> lion, you know? ... But He's GOOD.
Michael Miller Jr wrote:Either way, gentlemen, I deeply appreciate the help.
If you can offer any other insight, especially if you have some workable picture analogies, that would be of tremendous help. Thank you, deeply!
Jeff Verdegan wrote:I don't know what help to offer because I don't know what questions you still have.
Aslan safe? Of course He isn't safe. He's not a <i>tame</i> lion, you know? ... But He's GOOD.
Don't get me started about those stupid light bulbs. |