3

So I'm reading my C# book and it has an example of how to create a method for creating a deep copy of an object: 

[Serializable]
public class DeepClone : IDeepCopy<DeepClone>
{
    public int data = 1;
    public List<string> ListData = new List<string>();
    public object objData = new Object();
    public DeepClone DeepCopy ()
    {
        BinaryFormatter BF = new BinaryFormatter();
        MemoryStream memSfream = new MemoryStream();
        BF.Serialize(memStream,this);
        memStream.Flush();
        memStream.Position = 0;
        return (DeepClone)BF.Deserialize(memStream);
    }
}

But the method DeepCopy is general enough that it doesn't depend on the other members

    public int data = 1;
    public List<string> ListData = new List<string>();
    public object objData = new Object();

of the object. As far as I can tell, this method could be put in any class and would work just the same. Additionally, how to copy an object is a question that many C# programmers have when they first use the language, as evidenced by the popularity of this thread.

This brings up the question I have about why System.Object wasn't given a clone function. I bet programmers more often need a Clone method than a GetHashcode method, after all.

Community
  • 1
  • 1
user6048670
  • 2,861
  • 4
  • 16
  • 20
  • "I bet programmers more often need a Clone method than a GetHashcode method" I don't think I've used `Clone` more than I've used `GetHashCode`, and there's debate about whether `GetHashCode` should have been in `Object`. Not everything is suitable to be cloned and not everything is suitable to be used as keys in hashtables. – Dennis_E Mar 20 '16 at 22:50
  • The .NET designers learned that lesson pretty well from C++. A language that very often creates programs that misbehave badly because the programmer did not implement cloning correctly. There is nothing pretty about it, ICloneable narrowly escaped getting deprecated. It is much less necessary in .NET thanks to garbage collection. – Hans Passant Mar 20 '16 at 23:08

1 Answers1

3

Not all classes can support cloning. Singleton objects by their very definition cannot be cloned. OO dictates that such classes should not contain a Clone method. Since classes cannot avoid inheriting System.Object, the method should not be introduced at that level. (The same reasoning should apply to methods ToString(), Equals() and GetHashCode(), but I guess someone decided otherwise.)

In addition to the interface aspect, cloning is not as trivial as it seems, e.g. when child objects store references to their parents. For example, when cloning a (WinForms or other) control, you'd probably want child controls cloned as well, but not the parent control. Now which references need cloning and which don't? This makes it difficult (if not impossible) to implement cloning correctly for all cases.

Kai van Lopik
  • 246
  • 1
  • 4
  • Why not give every object a clone method and leave it up to the developer to decide whether or not it makes sense to use it on a particular object? – user6048670 Mar 20 '16 at 23:42
  • 1
    Hillary: my edited answer addresses this. You don't want a fat interface with methods that make no sense at the derived level. Derived classes will have no option but to throw, making the interface meaningless. – Kai van Lopik Mar 21 '16 at 00:06