Advantages of ICloneable?

[Andy]

Hello.

I've got an issue with the ICloneable interface that makes me think I'm
missing the advantages of it.

My issue is that the implemented Clone method returns an object and not
a strongly typed definition. This means that the class you create
exposes a method that returns an object which the user of the class must
cast.

public object Clone() {...}

I would much prefer the class to expose a type of itself:

public MyClass Clone() {...}

so that the caller doesn't have to cast and the interface is cleaner.

Why should I then use IClonable??
Thanks,
Andy

[Jon Skeet [C# MVP]]

Andy <an*******@hotmail.com> wrote:

I've got an issue with the ICloneable interface that makes me think I'm
missing the advantages of it.

My issue is that the implemented Clone method returns an object and not
a strongly typed definition. This means that the class you create
exposes a method that returns an object which the user of the class must
cast.

public object Clone() {...}

I would much prefer the class to expose a type of itself:

public MyClass Clone() {...}

so that the caller doesn't have to cast and the interface is cleaner.
You can expose that separately, and implement ICloneable explicitly.
Why should I then use IClonable??

So that things which only care that an object can be cloned can accept
instances of your class as a parameter. Not everything will always know
your concrete type...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Samuel R. Neff]

One standard impelementation is something like this:

public MyClass Clone() { ... }

object ICloneable.Clone { return Clone(); }

That way if the reference is typed as MyClass you can use the strongly
typed Clone method, but if you're referring to the object simply as
ICloneable then you can use the standard interface method.

This implementation gives you the best of both worlds--a strongly
typed Clone() method and also a polymorhpic Clone() method.

HTH,

Sam
On Thu, 26 May 2005 20:46:11 GMT, Andy <an*******@hotmail.com> wrote:

Hello.

I've got an issue with the ICloneable interface that makes me think I'm
missing the advantages of it.

My issue is that the implemented Clone method returns an object and not
a strongly typed definition. This means that the class you create
exposes a method that returns an object which the user of the class must
cast.

public object Clone() {...}

I would much prefer the class to expose a type of itself:

public MyClass Clone() {...}

so that the caller doesn't have to cast and the interface is cleaner.

Why should I then use IClonable??
Thanks,
Andy

[Andy]

Jon Skeet [C# MVP] wrote:

Andy <an*******@hotmail.com> wrote:

I've got an issue with the ICloneable interface that makes me think I'm
missing the advantages of it.

My issue is that the implemented Clone method returns an object and not
a strongly typed definition. This means that the class you create
exposes a method that returns an object which the user of the class must
cast.

public object Clone() {...}

I would much prefer the class to expose a type of itself:

public MyClass Clone() {...}

so that the caller doesn't have to cast and the interface is cleaner.

You can expose that separately, and implement ICloneable explicitly.

Why should I then use IClonable??

So that things which only care that an object can be cloned can accept
instances of your class as a parameter. Not everything will always know
your concrete type...

That makes sense.

Thank you.

[Andy]

Good tip.

Thank you.

Samuel R. Neff wrote:

One standard impelementation is something like this:

public MyClass Clone() { ... }

object ICloneable.Clone { return Clone(); }

That way if the reference is typed as MyClass you can use the strongly
typed Clone method, but if you're referring to the object simply as
ICloneable then you can use the standard interface method.

This implementation gives you the best of both worlds--a strongly
typed Clone() method and also a polymorhpic Clone() method.

HTH,

Sam
On Thu, 26 May 2005 20:46:11 GMT, Andy <an*******@hotmail.com> wrote:

Hello.

I've got an issue with the ICloneable interface that makes me think I'm
missing the advantages of it.

My issue is that the implemented Clone method returns an object and not
a strongly typed definition. This means that the class you create
exposes a method that returns an object which the user of the class must
cast.

public object Clone() {...}

I would much prefer the class to expose a type of itself:

public MyClass Clone() {...}

so that the caller doesn't have to cast and the interface is cleaner.

Why should I then use IClonable??
Thanks,
Andy

[Bruce Wood]

Here's another tip: in an inheritance hierarchy, implementing
ICloneable can be a pain:

public class BaseClass : ICloneable
{
private int _member1;
private string _member2;

public BaseClass(string aString)
{
this._member2 = aString;
this._member1 = 0;
}

public virtual object Clone()
{
BaseClass clone = new BaseClass(this._member2);
clone._member1 = this._member1;
...
}
}

public class DerivedClass : BaseClass
{
}

Now, what you really want to do in DerivedClass is override Clone().
However, there's a problem: you can't get at the fields in the base
class, because they're private, and the base class doesn't necessarily
expose all of those fields as properties, or allow you to set them. So,
how do you clone the derived class (including the base class fields) if
you can't copy the base class fields?

The answer is to make a protected method called CopyTo (or CopyFrom...
it doesn't really much matter), and a protected empty constructor.

public class BaseClass : ICloneable
{
private int _member1;
private string _member2;

public BaseClass(string aString)
{
this._member2 = aString;
this._member1 = 0;
}

protected BaseClass()
{
this._member2 = null;
this._member1 = 0;
}

protected virtual CopyFrom(BaseClass otherBase)
{
this._member1 = otherBase._member1;
this._member2 = otherBase._member2;
...
}

public virtual object Clone()
{
BaseClass clone = new BaseClass();
clone.CopyFrom(this);
}
}

Now the derived class looks similar:

public class DerivedClass : BaseClass
{
private int _member3;
private string _member4;

public DerivedClass(string aString) : base(aString)
{
this._member3 = "";
this._member4 = 0;
}

protected DerivedClass() : BaseClass()
{
this._member3 = null;
this._member4 = 0;
}

protected virtual CopyFrom(DerivedClass otherDerived)
{
base.CopyFrom(otherDerived);
this._member3 = otherDerived._member3;
this._member4 = otherDerived._member4;
...
}

public virtual object Clone()
{
DerivedClass clone = new DerivedClass();
clone.CopyFrom(this);
}
}

[Jon Skeet [C# MVP]]

Bruce Wood <br*******@canada.com> wrote:

Here's another tip: in an inheritance hierarchy, implementing
ICloneable can be a pain:

<snip>

Alternatively, where it's appropriate (i.e. for shallow copies where
you have enough access to make any "interesting" bits deep yourself)
you can just use Object.MemberwiseClone.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too