Usage of ICloneable
-
Hi everyone, this is not really a programming question, but as I made some thoughts about cloning my objects I had an idea and just want to hear some comments on it. Normally when a class should be cloneable it implements ICloneable like this:
public class TestClass : ICloneable {
public object Clone() {
//Do something
}
}The nasty thing about this is that everybody who calls Clone will have to do a cast afterwards (assuming the caller wants to do something with the result where object doesn't help). Do avoid this one could just forget ICloneable and make a typed Clone method:
public class TestClass {
public TestClass Clone() {
//Do something
}
}Sadly this isn't an option for me because at some places in my code I have an ArrayList which holds objects of several different classes which I all have to clone. So I came to the idea to instead combine the two methods and do the following:
public class TestClass : ICloneable {
object ICloneable.Clone() {
return this.Clone();
}public TestClass Clone() {
//Do something
}
}So now when I use a variable of type TestClass the Clone method will return TestClass, but I can use it also as an ICloneable where I get an object (Truly also having the type TestClass but unknown to the caller). So what are your thoughts about it? I think this casting problem when using Clone is relatively widespread, but why is everybody using (I refer to the framework and some 3rd party components) just the naiv method? PS: Why is the result of ICloneable.Clone an object and not ICloneable? I thought the intention of this interface was that the result should be some kind of deep copy of the object and should always have the same type... :confused: -- modified at 15:56 Sunday 9th October, 2005
-
Hi everyone, this is not really a programming question, but as I made some thoughts about cloning my objects I had an idea and just want to hear some comments on it. Normally when a class should be cloneable it implements ICloneable like this:
public class TestClass : ICloneable {
public object Clone() {
//Do something
}
}The nasty thing about this is that everybody who calls Clone will have to do a cast afterwards (assuming the caller wants to do something with the result where object doesn't help). Do avoid this one could just forget ICloneable and make a typed Clone method:
public class TestClass {
public TestClass Clone() {
//Do something
}
}Sadly this isn't an option for me because at some places in my code I have an ArrayList which holds objects of several different classes which I all have to clone. So I came to the idea to instead combine the two methods and do the following:
public class TestClass : ICloneable {
object ICloneable.Clone() {
return this.Clone();
}public TestClass Clone() {
//Do something
}
}So now when I use a variable of type TestClass the Clone method will return TestClass, but I can use it also as an ICloneable where I get an object (Truly also having the type TestClass but unknown to the caller). So what are your thoughts about it? I think this casting problem when using Clone is relatively widespread, but why is everybody using (I refer to the framework and some 3rd party components) just the naiv method? PS: Why is the result of ICloneable.Clone an object and not ICloneable? I thought the intention of this interface was that the result should be some kind of deep copy of the object and should always have the same type... :confused: -- modified at 15:56 Sunday 9th October, 2005
If only C# supported Covariant[^] return types, then your problem would go away. You'll be able to return TestClass and still implement ICloneable.Clone. Robert Rohde wrote: Why is the result of ICloneable.Clone an object and not ICloneable? I thought the intention of this interface was that the result should be some kind of deep copy of the object and should always have the same type.. ICloneable.Clone clones an object, so why should it return ICloneable? Regards Senthil _____________________________ My Blog | My Articles | WinMacro