ICloneable Interface

I was looking for something else, and stumbled upon this discussion thread, I agree with Tony Blaire78, it is exactly same what I have implemented when ever there was a need. With that said, I do believe that Microsoft should make the type of copy clear; i.e. it is Shallow or Deep upfront.

The returned object is always of type 'System.Object' which is not type-safe. A type-safe pattern to implement this interface can be found here: http://kristofverbiest.blogspot.com/2008/10/type-safe-pattern-to-implement.html

MemberwiseClone is a protected method inherited from Object, whereas IClonable.Clone is by definition public because it's a member of an interface.

So isn't it the case that the two methods are used for quite different purposes - the former in some kind of internal operation by a class, and the latter where you call externally into the object and you either don't want to have to know which type is implementing the interface, or you don't want to have to know what implementation the IClonable is providing.

It seems to me that the point of this interface has been obscured because the folks who named weren't sure if it will be used for a Deep or Shallow copy, so they took the safe side and said you can use it for both!.

Well, I have to disagree with David M. Kean about using copy constructors.  Not that I think copy constructors are bad (they aren't), but his argument fails on two grounds.

 

1.  A copy constructor has the exact same issue talked about by Jonathan.  There's no way to know if the copy constructor is going to make a deep or shallow copy.

 

2. A copy constructor can not be used polymorphically, which is the whole point in using a "Clone" method in OO languages.

Personally, I don't think throwing ICloneable out is appropriate.  Me, I always assume this does a shallow copy (which usually won't cause issues even if a deep copy is made), and if I must have a deep copy I use a custom IDeepCloneable interface.

The design of this interface was flawed, since it didn't specify the type of copy that would be done, but the concept is still useful and even necessary at times.

I have to dissagree with Jonathan Allen's post regarding his "Don't implement this interface." argument.

The IClonable interface is usefull when used properly. For example in a business solution, specifics regarding shallow or deep clones would be laid out in the design doc's prior to implementation. So any object implementing the IClonable interface would/should adhere to those design specifications. 

This interface has been pretty much abandoned by Microsoft.

The problem is that it doesn't indicate if this is a shallow or deep clone. Nor does it give a way to indicate which is desired in the given circumstance.