Copiar constructor versus Clonar ()

En C #, ¿cuál es la forma preferida de agregar funcionalidad de copia (profunda) a una clase? ¿Debe uno implementar el constructor de copia, o más bien derivar ICloneablee implementar elClone() método?

Observación : escribí "profundo" entre corchetes porque pensé que era irrelevante. Aparentemente, otros no están de acuerdo, así que pregunté si un constructor / operador / función de copia debe dejar en claro qué variante de copia implementa .

No deberías derivar de ICloneable.

La razón es que cuando Microsoft diseñó el marco .net nunca especificó si el Clone()método en ICloneabledebería ser un clon profundo o superficial, por lo que la interfaz está semánticamente rota ya que las personas que llaman no sabrán si la llamada clonará el objeto en profundidad o superficial.

En su lugar, debe definir sus propias IDeepCloneable(y IShallowCloneable) interfaces con DeepClone()(y ShallowClone()) métodos.

Puede definir dos interfaces, una con un parámetro genérico para admitir la clonación fuertemente tipada y otra sin para mantener la capacidad de clonación débil para cuando está trabajando con colecciones de diferentes tipos de objetos clonables:

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

Que luego implementaría así:

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

Generalmente prefiero usar las interfaces descritas en lugar de un constructor de copias, mantiene la intención muy clara. Probablemente se supondría que un constructor de copias es un clon profundo, pero ciertamente no es una intención tan clara como usar una interfaz IDeepClonable.

Esto se discute en las Pautas de diseño de .net Framework y en el blog de Brad Abrams

_{(Supongo que si está escribiendo una aplicación (en lugar de un marco / biblioteca) para que pueda estar seguro de que nadie fuera de su equipo llamará a su código, no importa tanto y puede asignar un significado semántico de "deepclone" a la interfaz .net ICloneable, pero debe asegurarse de que esto esté bien documentado y bien entendido dentro de su equipo. Personalmente, me apegaría a las pautas del marco).}

En C #, ¿cuál es la forma preferida de agregar funcionalidad de copia (profunda) a una clase? ¿Debería uno implementar el constructor de copia, o más bien derivar de ICloneable e implementar el método Clone ()?

El problema con ICloneablees, como han mencionado otros, que no especifica si se trata de una copia profunda o superficial, lo que la hace prácticamente inutilizable y, en la práctica, poco utilizada. También vuelve object, lo cual es un fastidio, ya que requiere mucho yeso. (Y aunque mencionaste específicamente las clases en la pregunta, implementar ICloneableen un structrequiere boxeo).

Un constructor de copias también sufre uno de los problemas con ICloneable. No es obvio si un constructor de copias está haciendo una copia profunda o superficial.

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

Lo mejor sería crear un método DeepClone (). De esta manera la intención es perfectamente clara.

Esto plantea la cuestión de si debería ser un método estático o de instancia.

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

o

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

A veces prefiero un poco la versión estática, solo porque la clonación parece algo que se está haciendo en un objeto en lugar de algo que el objeto está haciendo. En cualquier caso, habrá problemas con los que lidiar al clonar objetos que son parte de una jerarquía de herencia, y cómo esos problemas pueden finalmente impulsar el diseño.

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

Recomiendo usar un constructor de copia sobre un método de clonación principalmente porque un método de clonación evitará que cree campos readonlyque podrían haber sido si hubiera usado un constructor en su lugar.

Si necesita la clonación polimórfica, puede agregar un método abstracto virtual Clone()a su clase base que implementa con una llamada al constructor de copia.

Si necesita más de un tipo de copia (por ejemplo: profunda / superficial), puede especificarla con un parámetro en el constructor de copia, aunque en mi experiencia encuentro que lo que necesito normalmente es una mezcla de copia profunda y superficial.

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

Existe un gran argumento de que debería implementar clone () usando un constructor de copia protegido

Es mejor proporcionar un constructor de copia protegido (no público) e invocarlo desde el método de clonación. Esto nos da la capacidad de delegar la tarea de crear un objeto a una instancia de una clase en sí, proporcionando así extensibilidad y también, creando de forma segura los objetos usando el constructor de copia protegida.

Así que esta no es una pregunta "versus". Es posible que necesite tanto constructor (es) de copia como una interfaz de clonación para hacerlo bien.

(Aunque la interfaz pública recomendada es la interfaz Clone () en lugar de la basada en Constructor).

No se deje atrapar por el argumento explícito profundo o superficial de las otras respuestas. En el mundo real, casi siempre es algo intermedio y, de cualquier manera, no debería ser una preocupación para la persona que llama.

El contrato Clone () es simplemente "no cambiará cuando cambie el primero". La cantidad de gráfico que tienes que copiar o cómo evitas la recursividad infinita para que eso suceda no debería preocupar a la persona que llama.

No se recomienda implementar ICloneable debido al hecho de que no se especifica si es una copia profunda o superficial, así que iría por el constructor o simplemente implementaría algo usted mismo. ¡Quizás lo llame DeepCopy () para que sea realmente obvio!

Te encontrarás con problemas con los constructores de copias y las clases abstractas. Imagina que quieres hacer lo siguiente:

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

Inmediatamente después de hacer lo anterior, comienza a desear haber usado una interfaz o haberse conformado con una implementación de DeepCopy () / ICloneable.Clone ().

El problema con ICloneable es tanto la intención como la coherencia. Nunca está claro si es una copia profunda o superficial. Por eso, probablemente nunca se use de una manera u otra.

No encuentro un constructor de copia público que sea más claro al respecto.

Dicho esto, introduciría un sistema de métodos que funcione para usted y transmita la intención (algo que se autodocumenta)

Si el objeto que está intentando copiar es serializable, puede clonarlo serializándolo y deserializándolo. Entonces no es necesario escribir un constructor de copia para cada clase.

No tengo acceso al código en este momento, pero es algo como esto

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
}

Depende de la semántica de copia de la clase en cuestión, que debe definir usted mismo como desarrollador. El método elegido generalmente se basa en los casos de uso previstos de la clase. Quizás tenga sentido implementar ambos métodos. Pero ambos comparten una desventaja similar: no está exactamente claro qué método de copia implementan. Esto debe estar claramente indicado en la documentación de su clase.

Para mi tener:

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

en vez 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();

parecía una declaración de intenciones más clara.

Creo que debería haber un patrón estándar para objetos clonables, aunque no estoy seguro de cuál debería ser exactamente el patrón. Con respecto a la clonación, parece que hay tres tipos de clases:

1. Aquellos que apoyan explícitamente la clonación profunda
2. Aquellos en los que la clonación por miembros funcionará como clonación profunda, pero que no tienen ni necesitan apoyo explícito.
3. Aquellos que no se pueden clonar en profundidad de manera útil y donde la clonación por miembros dará malos resultados.

Por lo que puedo decir, la única forma (al menos en .net 2.0) de obtener un nuevo objeto de la misma clase que un objeto existente es usar MemberwiseClone. Un buen patrón parece ser tener una función Clone "nueva" / "Shadows" que siempre devuelve el tipo actual, cuya definición es siempre llamar a MemberwiseClone y luego llamar a una subrutina virtual protegida CleanupClone (originalObject). La rutina CleanupCode debe llamar a base.Cleanupcode para manejar las necesidades de clonación del tipo base y luego agregar su propia limpieza. Si la rutina de clonación tiene que usar el objeto original, tendría que ser encasillado, pero de lo contrario, el único encasillado sería en la llamada de MemberwiseClone.

Desafortunadamente, el nivel más bajo de clase que era del tipo (1) anterior en lugar del tipo (2) tendría que codificarse para asumir que sus tipos más bajos no necesitarían ningún soporte explícito para la clonación. Realmente no veo ninguna forma de evitar eso.

Aún así, creo que tener un patrón definido sería mejor que nada.

Por cierto, si uno sabe que el tipo base de uno es compatible con iCloneable, pero no conoce el nombre de la función que utiliza, ¿hay alguna forma de hacer referencia a la función iCloneable.Clone del tipo base de uno?

Si lee todas las respuestas y discusiones interesantes, es posible que aún se pregunte cómo copia exactamente las propiedades, todas explícitamente, o ¿hay una forma más elegante de hacerlo? Si esa es su pregunta restante, eche un vistazo a esto (en StackOverflow):

¿Cómo puedo clonar "profundamente" las propiedades de clases de terceros utilizando un método de extensión genérico?

Describe cómo implementar un método de extensión CreateCopy()que crea una copia "profunda" del objeto que incluye todas las propiedades (sin tener que copiar propiedad por propiedad manualmente).