Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why should I implement ICloneable in c#?

Can you explain to me why I should inherit from ICloneable and implement the Clone() method?

If I want to do a deep copy, can't I just implement my method? Let's say MyClone()?

Why should I inherit from ICloneable? What are the advantages? Is it just a matter of making code "more readable"?

like image 677
uinc Avatar asked Mar 30 '09 22:03

uinc


People also ask

Why use ICloneable?

"The ICloneable interface enables you to provide a customized implementation that creates a copy of an existing object. The ICloneable interface contains one member, the Clone method, which is intended to provide cloning support beyond that supplied by Object.

Which of the following method should be implemented when ICloneable interface is used?

ICloneable interface) should contain public or protected copy constructor. Base class should declare Clone method as virtual. Derived class should contain copy constructor which calls base class's copy constructor. Both base and derived class should implement Clone method by simply invoking the copy constructor.

What supports cloning which creates a new instance of a class with the same value as an existing instance?

Definition. Supports cloning, which creates a new instance of a class with the same value as an existing instance.


2 Answers

You shouldn't. Microsoft recommends against implementing ICloneable because there's no clear indication from the interface whether your Clone method performs a "deep" or "shallow" clone.

See this blog post from Brad Abrams back in 2003(!) for more information.

like image 55
Matt Hamilton Avatar answered Sep 28 '22 17:09

Matt Hamilton


The ICloneable interface by itself isn't very useful, which is to say that there really aren't many situations where it's useful to know that an object is cloneable without knowing anything else about it. This is a very different situation from e.g. IEnumerable or IDisposable; there are many situations where it's useful to accept an IEnumerable without knowing anything other than how to enumerate it.

On the other hand, ICloneable may be useful when applied as a generic constraint along with other constraints. For example, a base class might usefully support a number of derivatives, some of which could be usefully cloned, and some of which could not. If the base type itself exposed a public cloning interface, then any derivative type which could not be cloned would violate the Liskov Substitution Principle. The way to avoid this problem is to have the base type support cloning using a Protected method, and allow derived types to implement a public cloning interface as they see fit.

Once that was accomplished, a method which wants to accept an object of a WonderfulBase type, and needs to be able to clone it, could be coded to accept a WonderfulBase object which supports cloning (using a generic type parameter with base-type and ICloneable constraints). Although the ICloneable interface would not itself indicate deep or shallow cloning, the documentation for WonderfulBase would indicate whether cloneable WonderfulBase should be deep- or shallow-cloned. Essentially, the ICloneable interface wouldn't accomplish anything that wouldn't be accomplished by defining ICloneableWonderfulBase, except that it would avoid having to define different names for every different cloneable base class.

like image 43
supercat Avatar answered Sep 28 '22 17:09

supercat