Copia costruttore contro Clone ()

In C #, qual è il modo preferito per aggiungere funzionalità di copia (approfondita) a una classe? Si dovrebbe implementare il costruttore di copia, o piuttosto derivare ICloneablee implementare il Clone()metodo?

Nota : ho scritto "profondo" tra parentesi perché pensavo fosse irrilevante. Apparentemente altri non sono d'accordo, quindi ho chiesto se un costruttore / operatore / funzione di copia deve chiarire quale variante di copia implementa .

Non dovresti derivare da ICloneable.

Il motivo è che quando Microsoft ha progettato il framework .net non ha mai specificato se il Clone()metodo ICloneabledeve essere un clone profondo o superficiale, quindi l'interfaccia è semanticamente interrotta poiché i chiamanti non sapranno se la chiamata clonerà l'oggetto in modo profondo o superficiale.

Invece, si dovrebbe definire il proprio IDeepCloneable(e IShallowCloneable) interfacce con DeepClone()(e ShallowClone()metodi).

È possibile definire due interfacce, una con un parametro generico per supportare la clonazione fortemente tipizzata e l'altra senza per mantenere la capacità di clonazione debolmente tipizzata per quando si lavora con raccolte di diversi tipi di oggetti clonabili:

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

Che poi implementeresti in questo modo:

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

Generalmente preferisco usare le interfacce descritte al contrario di un costruttore di copie che mantiene l'intento molto chiaro. Si presume probabilmente che un costruttore di copie sia un clone profondo, ma non è certamente un intento chiaro come l'utilizzo di un'interfaccia IDeepClonable.

Questo è discusso nelle .net Framework Design Guidelines e nel blog di Brad Abrams

_{(Suppongo che se stai scrivendo un'applicazione (al contrario di un framework / libreria) così puoi essere sicuro che nessuno al di fuori del tuo team chiamerà il tuo codice, non importa così tanto e puoi assegnare un significato semantico di "clone in profondità" all'interfaccia .net ICloneable, ma dovresti assicurarti che sia ben documentato e ben compreso all'interno del tuo team. Personalmente mi atterrei alle linee guida del framework.)}

In C #, qual è il modo preferito per aggiungere funzionalità di copia (approfondita) a una classe? Si dovrebbe implementare il costruttore di copia, o piuttosto derivare da ICloneable e implementare il metodo Clone ()?

Il problema con ICloneableè, come altri hanno detto, che non specifica se si tratta di una copia profonda o superficiale, il che la rende praticamente inutilizzabile e, in pratica, usata raramente. Inoltre ritorna object, il che è un dolore, poiché richiede molto lancio. (E sebbene tu abbia menzionato specificamente le classi nella domanda, l'implementazione ICloneablesu un structrichiede boxe.)

Un copy constuctor soffre anche di uno dei problemi con ICloneable. Non è ovvio se un costruttore di copie sta eseguendo una copia profonda o superficiale.

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

Sarebbe meglio creare un metodo DeepClone (). In questo modo l'intento è perfettamente chiaro.

Ciò solleva la questione se debba essere un metodo statico o di istanza.

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

o

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

A volte preferisco leggermente la versione statica, solo perché la clonazione sembra qualcosa che viene fatto su un oggetto piuttosto che qualcosa che sta facendo l'oggetto. In entrambi i casi, ci saranno problemi da affrontare durante la clonazione di oggetti che fanno parte di una gerarchia di ereditarietà e il modo in cui tali problemi vengono risolti potrebbe alla fine guidare il progetto.

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();
    }
}

Consiglio di utilizzare un costruttore di copia su un metodo clone principalmente perché un metodo clone ti impedirà di creare campi readonlyche avrebbero potuto essere se avessi invece usato un costruttore.

Se è necessaria la clonazione polimorfica, è quindi possibile aggiungere un metodo abstracto virtual Clone()alla classe base che si implementa con una chiamata al costruttore di copia.

Se hai bisogno di più di un tipo di copia (es: profondo / superficiale) puoi specificarlo con un parametro nel costruttore di copia, anche se nella mia esperienza trovo che di solito un misto di copia profonda e superficiale è ciò di cui ho bisogno.

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);
}

C'è un ottimo argomento per implementare clone () usando un costruttore di copie protetto

È meglio fornire un costruttore di copia protetto (non pubblico) e richiamarlo dal metodo clone. Questo ci dà la possibilità di delegare il compito di creare un oggetto a un'istanza di una classe stessa, fornendo così estensibilità e anche, creando in sicurezza gli oggetti usando il costruttore di copia protetta.

Quindi questa non è una domanda "contro". Potresti aver bisogno di entrambi i costruttori di copia e un'interfaccia clone per farlo bene.

(Sebbene l'interfaccia pubblica consigliata sia l'interfaccia Clone () piuttosto che basata sul costruttore.)

Non lasciarti coinvolgere dall'argomento esplicito profondo o superficiale nelle altre risposte. Nel mondo reale è quasi sempre qualcosa di intermedio - e in entrambi i casi, non dovrebbe essere la preoccupazione del chiamante.

Il contratto Clone () è semplicemente "non cambierà quando cambio il primo". Quanta parte del grafico devi copiare, o come eviti la ricorsione infinita per farlo accadere non dovrebbe riguardare il chiamante.

L'implementazione di ICloneable non è consigliata poiché non è specificato se si tratta di una copia profonda o superficiale, quindi sceglierei il costruttore o implementerei qualcosa da solo. Forse chiamalo DeepCopy () per renderlo davvero ovvio!

Incontrerai problemi con i costruttori di copie e le classi astratte. Immagina di voler fare quanto segue:

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));
        }
    }
}

Subito dopo aver fatto quanto sopra, inizi a desiderare di aver utilizzato un'interfaccia o di aver optato per un'implementazione di DeepCopy () / ICloneable.Clone ().

Il problema con ICloneable è sia l'intento che la coerenza. Non è mai chiaro se si tratta di una copia profonda o superficiale. Per questo motivo, probabilmente non viene mai utilizzato solo in un modo o nell'altro.

Non trovo che un costruttore di copie pubbliche sia più chiaro su questo argomento.

Detto questo, introdurrei un sistema di metodi che funzioni per te e trasmetta l'intento (in qualche modo si documenta da solo)

Se l'oggetto che stai tentando di copiare è Serializable, puoi clonarlo serializzandolo e deserializzandolo. Quindi non è necessario scrivere un costruttore di copia per ogni classe.

Al momento non ho accesso al codice ma è qualcosa del genere

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
}

Dipende dalla semantica di copia della classe in questione, che dovresti definire come sviluppatore. Il metodo scelto è generalmente basato sui casi d'uso previsti della classe. Forse avrà senso implementare entrambi i metodi. Ma entrambi condividono uno svantaggio simile: non è esattamente chiaro quale metodo di copia implementano. Questo dovrebbe essere chiaramente indicato nella documentazione della tua classe.

Per me avere:

// 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();

invece di:

// 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();

sembrava una dichiarazione di intenti più chiara.

Penso che dovrebbe esserci un modello standard per gli oggetti clonabili, anche se non sono sicuro di quale dovrebbe essere esattamente il modello. Per quanto riguarda la clonazione, sembrerebbe che esistano tre tipi di classi:

1. Quelli che supportano esplicitamente la clonazione profonda
2. Quelli in cui la clonazione per membro funzionerà come clonazione profonda, ma che non hanno né necessitano di supporto esplicito.
3. Quelli che non possono essere clonati in modo proficuo e in cui la clonazione per membro darà risultati negativi.

Per quanto ne so, l'unico modo (almeno in .net 2.0) per ottenere un nuovo oggetto della stessa classe di un oggetto esistente è usare MemberwiseClone. Un bel pattern sembrerebbe essere quello di avere una funzione "new" / "Shadows" Clone che restituisce sempre il tipo attuale, la cui definizione è sempre quella di chiamare MemberwiseClone e quindi chiamare una subroutine virtuale protetta CleanupClone (originalObject). La routine CleanupCode dovrebbe chiamare base.Cleanupcode per gestire le esigenze di clonazione del tipo di base e quindi aggiungere la propria pulizia. Se la routine di clonazione deve utilizzare l'oggetto originale, dovrebbe essere typecast, ma altrimenti l'unico typecasting sarebbe sulla chiamata MemberwiseClone.

Sfortunatamente, il livello più basso di classe che era di tipo (1) sopra piuttosto che di tipo (2) dovrebbe essere codificato per presumere che i suoi tipi inferiori non necessitino di alcun supporto esplicito per la clonazione. Non vedo davvero alcun modo per aggirare questo.

Tuttavia, penso che avere uno schema definito sarebbe meglio di niente.

Per inciso, se si sa che il proprio tipo di base supporta iCloneable, ma non si conosce il nome della funzione che utilizza, c'è un modo per fare riferimento alla funzione iCloneable.Clone del proprio tipo di base?

Se leggi tutte le risposte e le discussioni interessanti, potresti ancora chiederti come copiare esattamente le proprietà, tutte in modo esplicito, o c'è un modo più elegante per farlo? Se questa è la tua domanda rimanente, dai un'occhiata a questa (su StackOverflow):

Come posso clonare "profondamente" le proprietà di classi di terze parti utilizzando un metodo di estensione generico?

Descrive come implementare un metodo di estensione CreateCopy()che crea una copia "profonda" dell'oggetto comprese tutte le proprietà (senza dover copiare manualmente proprietà per proprietà).