Is this a viable way to 'deep clone' objects?

[Peter Cimring]

Hi

Could someone give me a quick 'sanity check' on the following utility method for 'deep cloning' objects?:

Object cloneIt(Object o) {
    return o;
}

An example of the calling code:

MyObject my = new MyObject();
my.setFoo("bar");
MyObject clone = (MyObject)cloneIt(my);
// clone.getFoo() should now return "bar"

I have not seen this used before, so I'm wondering what I have missed here.

Thanks
Pete
[ September 10, 2008: Message edited by: Peter Cimring ]

[Brij Garg]

IS this a deep cloning .... ? I dont think so ....

Even it is not a cloning.

You are just returning a reference to the same object and storing in other reference. Just one object is there with more than one reference.

Correct me if I am not correct

[Peter Cimring]

Well - that's the crux of my question: does the 'return' statement return a copy of the object being referenced, or just a copy of the reference variable?

Take this example:

public class MyObject {
   private String foo = "bar";
   public String getFoo() {
       return foo;
   }
}
...
MyObject my = new MyObject();
String temp = my.getFoo();
temp.toUpperCase();
// my.foo == ???

Has 'my.foo' changed to "BAR"?

I admit that I may be totally confused - that's why I'm asking the question

Also, I realize that I could run some tests on my own - but I was hoping someone could provide some clarity on this - before I start 'chasing my own tail'

[Joanne Neal]

Originally posted by Peter Cimring:
Well - that's the crux of my question: does the 'return' statement return a copy of the object being referenced, or just a copy of the reference variable?

Just a copy of the reference variable - in your original example after your cloneIt() method returns you will have two references (my and clone) pointing at the same object.
[ September 10, 2008: Message edited by: Joanne Neal ]

[Brij Garg]

does the 'return' statement return a copy of the object being referenced, or just a copy of the reference variable

copy of the reference varible is returned.

// my.foo == ???

In the case my.foo is still "bar" ... NOT "BAR"
because foo is a String variable which is mutable.

temp.toUpperCase();

above statement will create new object having value "BAR".
We still have a foo as a reference to object "bar";

If you do
temp=temp.toUpperCase();
Even then foo refers to "bar" and temp refers to new object "BAR".

I hope this will help you.

[Peter Cimring]

Thanks all for the responses - it's a bit clearer now. I still would like to clarify one last question:

Let's say we're talking about a more complex data member - not a String. I'll use a (random) example of a UserProfile object that is composed of:
- String values
- A 'CountryProfile' object.

Let's look at the following (rather pointless) code:

public class UserProfile {
    String name = "";
    int age = 0;
    CountryProfile = null;
    
    // Getters and setters would follow here...
}
 
public class CountryProfile {
    String country = "";
    String country_code = "0";
 
    // Getters and setters would follow here...
 
    public resetDetails() {
        String country = "USA";
        String country_code = "1";
    }
}
 
UserProfile me = new UserProfile();
me.getCountryProfile().setCountry("Banana Republic");
me.getCountryProfile().setCountryCode("999");
 
...
 
CountryProfile temp = me.getCountryProfile(); // ref to original
temp.reset();
 
// Does me.getCountryProfile().getCountry() return "USA"?
// In other words, am I working with the original 'UserProfile.CountryProfile' object?

Does me.getCountryProfile().getCountry() return "USA"?
In other words, am I working with the original 'UserProfile.CountryProfile' object?

Many thanks
Pete
[ September 10, 2008: Message edited by: Peter Cimring ]

[Joanne Neal]

There are too many errors and unknown code there to know exactly what it will do. Why don't you complete the code and run it and then if it doesn't do what you expect come back and tell us what it is doing.

// In other words, am I working with the original 'UserProfile.CountryProfile' object?

You never create a CountryProfile object, so you are not working with the original or any other.
[ September 10, 2008: Message edited by: Joanne Neal ]

[Peter Cimring]

Sorry - I was rushing, so the example was a bit incorrect. I meant something like this:

public class UserProfile {
    String name = "";
    int age = 0;
    CountryProfile countryProfile = new CountryProfile();
    
    // Getters and setters omitted for brevity...
}
 
public class CountryProfile {
    String country = "";
    String country_code = "0";
 
    // Getters and setters omitted for brevity...
 
    public void resetDetails() {
        String country = "USA";
        String country_code = "1";
    }
}
 
UserProfile me = new UserProfile();
me.getCountryProfile().setCountry("Banana Republic");
me.getCountryProfile().setCountryCode("999");
 
...
 
CountryProfile temp = me.getCountryProfile(); // ref to original
temp.reset();
 
// Does me.getCountryProfile().getCountry() return "USA"?
// In other words, am I working with the original 'UserProfile.CountryProfile' object?

If I understand the answers posted thus far, accessor methods will return a ref to the original data member - presuming that the data member is an object, not a primitive.

Since the whole idea of getters and setters is to prevent accidental / unauthorized change to the object's data member, I always had a (vaguely formed) notion that the 'getter' would return a copy (clone) of the object - in keeping with the idea that you could only change the data member via the 'setter'.

I guess that's where I was wrong. The above code snippet (with or without the errors) was an attempt to demonstrate that with a concrete example.

[Joanne Neal]

Originally posted by Peter Cimring:

If I understand the answers posted thus far, accessor methods will return a ref to the original data member - presuming that the data member is an object, not a primitive.

That depends on how you write your accessor methods. They can return a reference to the original object or you can create a new object and return a reference to that.

Originally posted by Peter Cimring:
Since the whole idea of getters and setters is to prevent accidental / unauthorized change to the object's data member, I always had a (vaguely formed) notion that the 'getter' would return a copy (clone) of the object - in keeping with the idea that you could only change the data member via the 'setter'.

It's certainly a good idea to return a reference to a different object for the reasons you've stated. In the case of a String it's not actually necessary because Strings are immutable so you couldn't change them anyway.

[Peter Cimring]

Thanks Joanne - that's clarified it quite nicely.