ICloneable Vs Strongly Typed Function Vs Being Lazy

Hi Folks I need to deep clone some custom objects that references other custom objects and these may reference other cust... and so on you开发者_JAVA百科 get the idea.

I'm just at the documentation & conception stage at the moment so wan't to get it right.

Q1. Why implement ICloneable and return an object when you could write a strongly typed custom function that returns the correct object type cloned?

Q2. The objects are not huge and I don't mind doing the initial heavy lifting copying each element but being lazy I could memberwiseClone the object and then add specific code for the referenced members again this would create a need for casting, so what is more effiecient in terms of cpu cycles?

Any thoughts, opinions & musings welcomed.

See 536349 for reasons not to implement ICloneable; basically you could define your own (strongly typed) interface and use that, I don't see any problems with it as long as it properly documents that it creates deep copies.

The purpose of an interface is to allow people to operate upon objects that support the interface without having to worry about what the objects actually are. Without knowing what iCloneable.Clone is actually going to do on any given object, merely knowing that an object supports iCloneable is pretty useless.

It would have been useful for collection types to have a protected BaseClone method, and for them to have a derived type that would make it public (doing things that way would allow one to derive cloneable and non-cloneable types from the collections). Having something like Dictionary support a Clone method would be better than including a copy constructor, since the argument to a copy constructor could be a type which derived from Dictionary but was significantly different internally.

For a cloning interface to be useful, it would have to include a property by which items could say how they felt about cloning (e.g. -1- the type is immutable and doesn't need cloning; -2- cloning a type would likely break it; -3- the type supports cloning), and specify that a DeepClone operation would check all objects to make sure they didn't mind being cloning, and if that was the case, it would clone all nested mutable objects. Unfortunately, nothing like that exists in the framework.

Having an interface to indicate that an object is cloneable may be useful if a set of derived types includes cloneable and non-cloneable versions. If it's possible that derivatives of a type may not be able to support cloning, the cloning methods of that type should be Protected; a cloneable version of the type should be derived from it, but other types should derive from the non-cloneable versions.

For example, one could have a type Widget with derived types including CloneableWidget and SuperWidget (which isn't cloneable). SuperWidget could have a derived type CloneableSuperWidget (along with some others that would break if cloned). If one wants to be able to work with all cloneable derivatives of type Widget, one would have to check both that the object derives from Widget, and that it be cloneable. Adding iCloneable to the cloneable derivatives would allow one to check for such an object.