Copier le constructeur contre Clone ()

En C #, quelle est la méthode préférée pour ajouter une fonctionnalité de copie (profonde) à une classe? Doit-on implémenter le constructeur de copie, ou plutôt dériver ICloneableet implémenter la Clone()méthode?

Remarque : j'ai écrit "deep" entre crochets parce que je pensais que ce n'était pas pertinent. Apparemment, d'autres ne sont pas d'accord, alors j'ai demandé si un constructeur / opérateur / fonction de copie devait préciser quelle variante de copie il implémentait .

Vous ne devriez pas dériver de ICloneable.

La raison en est que lorsque Microsoft a conçu le framework .net, ils n'ont jamais spécifié si la Clone()méthode sur ICloneabledoit être un clone profond ou superficiel, l'interface est donc sémantiquement interrompue car vos appelants ne sauront pas si l'appel clonera l'objet en profondeur ou en profondeur.

Au lieu de cela, vous devez définir vos propres IDeepCloneable(et IShallowCloneable) interfaces avec les méthodes DeepClone()(et ShallowClone()).

Vous pouvez définir deux interfaces, une avec un paramètre générique pour prendre en charge le clonage fortement typé et une 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();
}

Ce que vous implémenteriez ensuite 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 garde 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.

Ceci est discuté dans les directives de conception du .net et sur le blog de Brad Abrams

_{(Je suppose que si vous écrivez une application (par opposition à un framework / bibliothèque) afin que vous puissiez être sûr que personne en dehors de votre équipe n'appellera votre code, cela n'a pas tellement 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 tiendrai aux directives du cadre.)}

En C #, quelle est la méthode préférée pour ajouter une fonctionnalité de copie (profonde) à une classe? Faut-il implémenter le constructeur de copie, ou plutôt dériver de ICloneable et implémenter la méthode Clone ()?

Le problème avec ICloneableest, comme d'autres l'ont mentionné, qu'il ne spécifie pas s'il s'agit d'une copie profonde ou superficielle, ce qui la rend pratiquement inutilisable et, en pratique, rarement utilisée. Il revient également object, ce qui est pénible, car il nécessite beaucoup de casting. (Et bien que vous ayez spécifiquement mentionné les classes dans la question, la mise ICloneableen œuvre sur un structnécessite de la boxe.)

Un constructeur de copie souffre également de l'un des problèmes liés à ICloneable. Il n'est pas évident qu'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'instance.

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

ou

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 les deux cas, il y aura des problèmes à résoudre lors du clonage d'objets qui font partie d'une hiérarchie d'héritage, et la façon dont ces problèmes sont résolus peut finalement conduire 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();
    }
}

Je recommande d'utiliser un constructeur de copie sur une méthode de clonage principalement parce qu'une méthode de clonage vous empêchera de créer des champs readonlyqui auraient pu l'être si vous aviez utilisé un constructeur à la place.

Si vous avez besoin d'un clonage polymorphe, vous pouvez ensuite ajouter une méthode abstractou virtual Clone()à votre classe de base que vous implémentez avec un appel au constructeur de copie.

Si vous avez besoin de plus d'un type de copie (ex: deep / shallow), vous pouvez le spécifier avec un paramètre dans le constructeur de copie, bien que d'après mon expérience, je trouve que généralement un mélange de copie profonde et superficielle est ce dont j'ai besoin.

Ex:

public class BaseType {
   readonly int mBaseField;

   public BaseType(BaseType pSource) =>
      mBaseField = pSource.mBaseField;

   public virtual BaseType Clone() =>
      new BaseType(this);
}

public class SubType : BaseType {
   readonly int mSubField;

   public SubType(SubType pSource)
   : base(pSource) =>
      mSubField = pSource.mSubField;

   public override BaseType Clone() =>
      new SubType(this);
}

Il existe un excellent argument selon lequel vous devriez implémenter clone () en utilisant un constructeur de copie protégée

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

Ce n'est donc pas une question «contre». Vous devrez peut-être à la fois des constructeurs de copie et une interface de clonage pour le faire correctement.

(Bien que l'interface publique recommandée soit l'interface Clone () plutôt que basée sur un constructeur.)

Ne vous laissez pas prendre par l'argument explicite profond ou superficiel des autres réponses. Dans le monde réel, c'est presque toujours quelque chose entre les deux - et de toute façon, ne devrait pas être la préoccupation de l'appelant.

Le contrat Clone () est simplement "ne changera pas quand je changerai le premier". La quantité de graphique que vous devez copier ou la manière d'éviter une récursivité infinie pour que cela se produise ne devrait pas concerner l'appelant.

La mise en œuvre d'ICloneable n'est pas recommandée raison du fait qu'il n'est pas spécifié s'il s'agit d'une copie profonde ou superficielle, alors je choisirais le constructeur, ou implémenterais simplement quelque chose vous-même. Appelez-le peut-être DeepCopy () pour le rendre vraiment évident!

Vous rencontrerez des problèmes avec les constructeurs de copie et les classes abstraites. Imaginez que vous vouliez 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 à souhaiter soit utiliser une interface, soit opter pour une implémentation DeepCopy () / ICloneable.Clone ().

Le problème avec ICloneable est à la fois l'intention et la cohérence. Il n'est jamais clair s'il s'agit d'une copie profonde ou superficielle. Pour cette raison, il n'est probablement jamais utilisé d'une seule manière ou d'une autre.

Je ne trouve pas de constructeur de copie publique plus clair à ce sujet.

Cela dit, je présenterais un système de méthodes qui fonctionne pour vous et qui relaie l'intention (a'la un peu auto-documenté)

Si l'objet que vous essayez de copier est sérialisable, vous pouvez le cloner en le sérialisant et en le désérialisant. Ensuite, vous n'avez pas besoin d'écrire un constructeur de copie pour chaque classe.

Je n'ai pas accès au code pour le moment mais c'est quelque chose comme ça

public object DeepCopy(object source)
{
   // Copy with Binary Serialization if the object supports it
   // If not try copying with XML Serialization
   // If not try copying with Data contract Serailizer, etc
}

Cela dépend de la sémantique de copie de la classe en question, que vous devez définir vous-même en tant que développeur. La méthode choisie est généralement basée sur les cas d'utilisation prévus de la classe. Il sera peut-être judicieux d'implémenter les deux méthodes. Mais les deux partagent un inconvénient similaire - la méthode de copie qu'ils implémentent n'est pas exactement claire. Cela doit être clairement indiqué dans la documentation de votre classe.

Pour moi ayant:

// myobj is some transparent proxy object
var state = new ObjectState(myobj.State);

// do something

myobject = GetInstance();
var newState = new ObjectState(myobject.State);

if (!newState.Equals(state))
    throw new Exception();

au lieu de:

// myobj is some transparent proxy object
var state = myobj.State.Clone();

// do something

myobject = GetInstance();
var newState = myobject.State.Clone();

if (!newState.Equals(state))
    throw new Exception();

ressemblait à une déclaration d'intention plus claire.

Je pense qu'il devrait y avoir un modèle standard pour les objets clonables, même si je ne suis pas sûr de ce que le modèle devrait être exactement. En ce qui concerne le clonage, il semblerait qu'il existe trois types de classes:

1. Ceux qui soutiennent explicitement le clonage profond
2. Ceux pour lesquels le clonage par membre fonctionnera comme un clonage profond, mais qui n'ont ni besoin de soutien explicite.
3. Ceux qui ne peuvent pas être utilement clonés en profondeur, et où le clonage par membre donnera de mauvais résultats.

Pour autant que je sache, le seul moyen (au moins dans .net 2.0) d'obtenir un nouvel objet de la même classe qu'un objet existant est d'utiliser MemberwiseClone. Un bon modèle semble être d'avoir une fonction "new" / "Shadows" Clone qui retourne toujours le type actuel, dont la définition est toujours d'appeler MemberwiseClone puis d'appeler un sous-programme virtuel protégé CleanupClone (originalObject). La routine CleanupCode doit appeler base.Cleanupcode pour gérer les besoins de clonage du type de base, puis ajouter son propre nettoyage. Si la routine de clonage doit utiliser l'objet d'origine, il devrait être transtypé, mais sinon le seul typage serait sur l'appel MemberwiseClone.

Malheureusement, le niveau le plus bas de classe qui était de type (1) ci-dessus plutôt que de type (2) devrait être codé pour supposer que ses types inférieurs n'auraient pas besoin de support explicite pour le clonage. Je ne vois vraiment aucun moyen de contourner cela.

Pourtant, je pense qu'avoir un modèle défini serait mieux que rien.

Incidemment, si l'on sait que son type de base prend en charge iCloneable, mais ne connaît pas le nom de la fonction qu'il utilise, y a-t-il un moyen de référencer la fonction iCloneable.Clone de son type de base?

Si vous lisez toutes les réponses et discussions intéressantes, vous pourriez toujours vous demander comment exactement vous copiez les propriétés - toutes explicitement, ou y a-t-il une manière plus élégante de le faire? Si c'est votre dernière question, jetez un coup d'œil à ceci (sur StackOverflow):

Comment puis-je cloner «profondément» les propriétés de classes tierces à l'aide d'une méthode d'extension générique?

Il décrit comment implémenter une méthode d'extension CreateCopy()qui crée une copie "profonde" de l'objet comprenant toutes les propriétés (sans avoir à copier manuellement propriété par propriété).