Below are two illustrations of the memory map for the following code fragment. > Picture x = new Picture("c:/cs123/mediasources/pictures/butterfly1.jpg") > Picture y = new Picture("c:/cs123/mediasources/pictures/turtle.jpg") > Picture z = x.pictureInAPictureVer2(300, 150, y)The first memory map shows what memory looks like just before the pictureInAPictureVer2() method returns. Notice that the newly created object, referenced by p3 , holds the merged data from the butterfly1.jpg and turtle.jpg Picture objects. That is, the pictureInAPictureVer2() method takes data from the object referenced by this and the object referenced by p2 and copies that data into the new object referenced by p3 . This new object therefore holds what should be the result of this method.
pictureInAPictureVer2() method returned. Notice that, when the method returned, the value from the local reference variable p3 was copied into the interaction reference variable z . Therefore, the variable z references the object that holds the merged data from the two original Picture objects. And the object referenced by x was not in any way modified (or mutated) by the method call (as opposed to the pictureInAPicture.java example).
Now let us consider the following example interaction. Below are two illustrations for this code. Be sure to compare this code and its illustrations to the above example and to the example from > Picture x = new Picture("c:/cs123/mediasources/pictures/butterfly1.jpg") > Picture y = new Picture("c:/cs123/mediasources/pictures/turtle.jpg") > x = x.pictureInAPictureVer2(300, 150, y)The first memory map shows what memory looks like just before the pictureInAPicture() method returns. Except for the lack of a interaction variable named z , this picture is the same as the corresponding picture above.
pictureInAPictureVer2() method returned. Notice that, when the method returned, the value from the local reference variable p3 was copied into the interaction reference variable x which over wrote the reference, that was in x |