Understanding Object References in Programming

4.2 Copying and Using Object References

When simple variable types are declared, a memory location is set aside for them where values of that type can be stored. Consider the following lines of code: double var1; double var2; var1 = 100.0; var2 = var1;

At the end of the sequence there are two copies of the value 100.0 stored in two different locations in memory, and each location is referred to by a different name in the program, var1 and var2.

Object references do not work the same way. Consider the following lines of code: Cup3 myCup; Cup3 yourCup; myCup = new Cup3(4); yourCup = myCup;

Only one object is created, and so only one object exists. However, there are two valid references and they both refer to that one single object. The diagram below illustrates this idea. The boxes on the left represent the named references in the program. The box on the right represents the actual object as stored in the computer s memory at run time. The line segments ending in solid dots graphically represent the relationships between the named references and the object.

myCup Cup3 object seedCount = 4 (Unless assigned to a reference, the object itself does not have a name. Internally it is uniquely identified by a hash code.) yourCup

In the following examples assume that the declarations have been made. Now consider these lines of code: myCup = new Cup3(4); myCup = new Cup3(5);

This time two objects are created, but there is only one reference. A reference can only refer to one object at a time. As a result, when the second object is created and its reference is assigned to myCup, the first object no longer has a reference to it. Here is a diagram illustrating this situation.

This reference no longer exists. Cup3 object seedCount = 4 Cup3 object myCup seedCount = 5

When this happens, the object without a reference still exists in the system, but it can no longer be used in the program because the program has lost its handle on it. It is possible to do this accidentally, but in generally it s perfectly all right to do this intentionally.

In Java, the system searches for objects that are no longer accessible and disposes of them. This is referred to as garbage collection , and you as a programmer don t have to worry about it.

Now consider the following lines of code: myCup = new Cup3(4); yourCup = new Cup3(5); yourCup = myCup;

In this case there are two objects and two references, but when the assignment, or copying of myCup to yourCup takes place, the reference to the object that yourCup originally referred to is lost. Both yourCup and myCup now refer to the same object. Here is a diagram illustrating this situation:

myCup Cup3 object seedCount = 4 Cup3 object yourCu p seedCount = 5

Unlike the assignment of variable values, the copying of object references does not result in a new copy of the object. It simply results in multiple references to the same object. If a new copy of an object is desired, it is possible to write a method that will return a reference to a copy. This is referred to as cloning and will be taken up later.

In the meantime, it is already possible to make copies of simple objects using the constructors and methods we have. Consider the following lines of code: myCup = new Cup3(4); yourCup = new Cup3(5); int someValue = myCup.getSeedCount(); yourCup.setSeedCount(someValue);

At the end of the sequence, the instance variables of myCup and yourCup have the same values, but myCup and yourCup are two separate objects. The two objects are faithful copies of each other. However, there is no link between them, and further actions could cause their contents to differ again. Here is a diagram illustrating this situation:

myCup Cup3 object seedCount = 4 Cup3 object yourCu p seedCount = 4