Constructeur de copie versus Clone()

Question

En C#, quelle est la meilleure façon d'ajouter la fonctionnalité de copie (profonde) à une classe ? Doit-on implémenter le constructeur de copie, ou plutôt dériver de ICloneable et mettre en œuvre le Clone() méthode ?

Remarque : J'ai écrit "profond" entre parenthèses parce que je pensais que ce n'était pas pertinent. Apparemment, d'autres ne sont pas d'accord, donc j'ai demandé si un constructeur/opérateur/fonction de copie doit indiquer clairement la variante de copie qu'il implémente .

Answer 1

Vous ne devez pas dériver de ICloneable .

La raison en est que lorsque Microsoft a conçu le cadre .net, il n'a jamais spécifié si l'interface de l'utilisateur devait être modifiée. Clone() méthode sur ICloneable devrait être un clone profond ou superficiel, donc l'interface est sémantiquement cassée car vos appelants ne sauront pas si l'appel clonera l'objet de manière profonde ou superficielle.

Au lieu de cela, vous devriez définir votre propre IDeepCloneable (et IShallowCloneable ) des interfaces avec DeepClone() (et ShallowClone() ).

Vous pouvez définir deux interfaces, l'une avec un paramètre générique pour prendre en charge le clonage fortement typé et l'autre sans pour conserver la capacité de clonage faiblement typé lorsque vous travaillez avec des collections de différents types d'objets clonables :

public interface IDeepCloneable
{
    object DeepClone();
}
public interface IDeepCloneable<T> : IDeepCloneable
{
    T DeepClone();
}

Que vous mettriez ensuite en œuvre comme ceci :

public class SampleClass : IDeepCloneable<SampleClass>
{
    public SampleClass DeepClone()
    {
        // Deep clone your object
        return ...;
    }
    object IDeepCloneable.DeepClone()   
    {
        return this.DeepClone();
    }
}

En général, je préfère utiliser les interfaces décrites plutôt qu'un constructeur de copie, cela permet de garder l'intention très claire. Un constructeur de copie serait probablement supposé être un clone profond, mais ce n'est certainement pas une intention aussi claire que l'utilisation d'une interface IDeepClonable.

Ce point est abordé dans le document .net Directives de conception du cadre et sur Brad Abrams blog

_{(Je suppose que si vous écrivez une application (par opposition à un framework/une bibliothèque) et que vous pouvez être sûr que personne en dehors de votre équipe n'appellera votre code, cela n'a pas tant d'importance et vous pouvez attribuer une signification sémantique de "deepclone" à l'interface .net ICloneable, mais vous devez vous assurer que cela est bien documenté et bien compris au sein de votre équipe. Personnellement, je m'en tiendrais aux directives du framework).}

Answer 2

En C#, quelle est la meilleure façon d'ajouter la fonctionnalité de copie (profonde) à une classe ? Doit-on implémenter le constructeur de copie, ou plutôt dériver de ICloneable et implémenter la méthode Clone() ?

Le problème avec ICloneable est, comme d'autres l'ont mentionné, qu'il ne précise pas s'il s'agit d'une copie profonde ou superficielle, ce qui le rend pratiquement inutilisable et, en pratique, rarement utilisé. Il renvoie également object ce qui est pénible, car cela nécessite beaucoup de casting. (Et bien que vous ayez spécifiquement mentionné les classes dans la question, l'implémentation de ICloneable sur un struct nécessite de la boxe).

Un constucteur de copie souffre également de l'un des problèmes de ICloneable. Il n'est pas évident de savoir si un constructeur de copie effectue une copie profonde ou superficielle.

Account clonedAccount = new Account(currentAccount); // Deep or shallow?

Il serait préférable de créer une méthode DeepClone(). De cette façon, l'intention est parfaitement claire.

Cela soulève la question de savoir s'il doit s'agir d'une méthode statique ou d'une méthode d'instance.

Account clonedAccount = currentAccount.DeepClone();  // instance method

o

Account clonedAccount = Account.DeepClone(currentAccount); // static method

Je préfère parfois légèrement la version statique, simplement parce que le clonage semble être quelque chose qui est fait à un objet plutôt que quelque chose que l'objet fait. Dans un cas comme dans l'autre, le clonage d'objets faisant partie d'une hiérarchie d'héritage pose des problèmes, et la façon dont ces problèmes sont résolus peut finalement déterminer la conception.

class CheckingAccount : Account
{
    CheckAuthorizationScheme checkAuthorizationScheme;

    public override Account DeepClone()
    {
        CheckingAccount clone = new CheckingAccount();
        DeepCloneFields(clone);
        return clone;
    }

    protected override void DeepCloneFields(Account clone)
    {
        base.DeepCloneFields(clone);

        ((CheckingAccount)clone).checkAuthorizationScheme = this.checkAuthorizationScheme.DeepClone();
    }
}

Answer 3

Il y a un grand argument pour dire que vous devriez implémenter clone() en utilisant un constructeur de copie protégé

Il est préférable de fournir un constructeur de copie protégé (non public) et de l'invoquer à partir de la méthode clone. Cela nous donne la possibilité de déléguer la tâche de création d'un objet à une instance de la classe elle-même, offrant ainsi une extensibilité et permettant de créer les objets en toute sécurité à l'aide du constructeur de copie protégé.

Il ne s'agit donc pas d'une question "versus". Vous pouvez avoir besoin à la fois d'un ou de plusieurs constructeurs de copie et d'une interface de clonage pour bien faire les choses.

(Bien que l'interface publique recommandée soit l'interface Clone() plutôt que Constructor-based).

Ne vous laissez pas entraîner par les arguments explicites, profonds ou superficiels, des autres réponses. Dans le monde réel, c'est presque toujours quelque chose entre les deux - et dans tous les cas, cela ne devrait pas préoccuper l'appelant.

Le contrat Clone() est simplement "ne change pas quand je change le premier". La quantité du graphe que vous devez copier, ou la façon dont vous évitez la récursion infinie pour y parvenir ne devrait pas concerner l'appelant.

Answer 4

La mise en œuvre de ICloneable n'est pas recommandée. en raison du fait qu'il n'est pas spécifié s'il s'agit d'une copie profonde ou superficielle, donc j'opterais pour le constructeur, ou implémentez simplement quelque chose vous-même. Peut-être l'appeler DeepCopy() pour que ce soit vraiment évident !

Answer 5

Vous rencontrerez des problèmes avec les constructeurs de copie et les classes abstraites. Imaginez que vous voulez faire ce qui suit :

abstract class A
{
    public A()
    {
    }

    public A(A ToCopy)
    {
        X = ToCopy.X;
    }
    public int X;
}

class B : A
{
    public B()
    {
    }

    public B(B ToCopy) : base(ToCopy)
    {
        Y = ToCopy.Y;
    }
    public int Y;
}

class C : A
{
    public C()
    {
    }

    public C(C ToCopy)
        : base(ToCopy)
    {
        Z = ToCopy.Z;
    }
    public int Z;
}

class Program
{
    static void Main(string[] args)
    {
        List<A> list = new List<A>();

        B b = new B();
        b.X = 1;
        b.Y = 2;
        list.Add(b);

        C c = new C();
        c.X = 3;
        c.Z = 4;
        list.Add(c);

        List<A> cloneList = new List<A>();

        //Won't work
        //foreach (A a in list)
        //    cloneList.Add(new A(a)); //Not this time batman!

        //Works, but is nasty for anything less contrived than this example.
        foreach (A a in list)
        {
            if(a is B)
                cloneList.Add(new B((B)a));
            if (a is C)
                cloneList.Add(new C((C)a));
        }
    }
}

Juste après avoir fait ce qui précède, vous commencez à regretter de ne pas avoir utilisé une interface ou de vous être contenté d'une implémentation de DeepCopy()/ICloneable.Clone().