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.

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. 

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.

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.