Construtor de cópia versus Clone ()

Em C #, qual é a maneira preferida de adicionar funcionalidade de cópia (profunda) a uma classe? Deve-se implementar o construtor de cópia, ou melhor, derivar ICloneablee implementar o Clone()método?

Observação : escrevi "profundo" entre colchetes porque achei irrelevante. Aparentemente, outros discordam, então perguntei se um construtor / operador / função de cópia precisa deixar claro qual variante de cópia ele implementa .

Você não deve derivar de ICloneable.

O motivo é que, quando a Microsoft projetou a estrutura .net, eles nunca especificaram se o Clone()método em ICloneabledeve ser um clone profundo ou superficial, portanto, a interface é semanticamente quebrada, pois seus chamadores não saberão se a chamada clonará profundamente ou superficialmente o objeto.

Em vez disso, você deve definir as suas próprias IDeepCloneable(e IShallowCloneable) interfaces com DeepClone()(e ShallowClone()) métodos.

Você pode definir duas interfaces, uma com um parâmetro genérico para oferecer suporte à clonagem fortemente tipada e outra sem, para manter a capacidade de clonagem fracamente tipada para quando você estiver trabalhando com coleções de diferentes tipos de objetos clonáveis:

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

Que você implementaria assim:

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

Geralmente, prefiro usar as interfaces descritas em vez de um construtor de cópia, pois mantém a intenção muito clara. Um construtor de cópia provavelmente seria considerado um clone profundo, mas certamente não é uma intenção tão clara quanto usar uma interface IDeepClonable.

Isso é discutido no .net Framework Design Guidelines e no blog de Brad Abrams

_{(Suponho que se você estiver escrevendo um aplicativo (em oposição a um framework / biblioteca), então você pode ter certeza que ninguém fora de sua equipe irá chamar seu código, não importa muito e você pode atribuir um significado semântico de "deepclone" para a interface .net ICloneable, mas você deve se certificar de que isso seja bem documentado e bem compreendido por sua equipe. Pessoalmente, seguiria as diretrizes da estrutura.)}

Em C #, qual é a maneira preferida de adicionar funcionalidade de cópia (profunda) a uma classe? Deve-se implementar o construtor de cópia, ou melhor, derivar de ICloneable e implementar o método Clone ()?

O problema com ICloneableé, como outros mencionaram, que não especifica se é uma cópia profunda ou superficial, o que a torna praticamente inutilizável e, na prática, raramente usada. Também retorna object, o que é chato, pois requer muito casting. (E embora você tenha mencionado especificamente as classes na pergunta, a implementação ICloneableem um structrequer boxe.)

Um construtor de cópia também sofre de um dos problemas com o ICloneable. Não é óbvio se um construtor de cópia está fazendo uma cópia profunda ou superficial.

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

Seria melhor criar um método DeepClone (). Dessa forma, a intenção é perfeitamente clara.

Isso levanta a questão de saber se deve ser um método estático ou de instância.

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

ou

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

Às vezes, prefiro um pouco a versão estática, só porque a clonagem parece algo que está sendo feito em um objeto, em vez de algo que o objeto está fazendo. Em ambos os casos, haverá problemas com os quais lidar ao clonar objetos que fazem parte de uma hierarquia de herança, e como esses problemas são resolvidos pode, em última instância, conduzir o design.

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

Eu recomendo usar um construtor de cópia em vez de um método clone principalmente porque um método clone impedirá que você crie campos readonlyque poderiam ter sido se você tivesse usado um construtor em vez disso.

Se precisar de clonagem polimórfica, você pode adicionar um método abstractou virtual Clone()à sua classe base que você implementa com uma chamada para o construtor de cópia.

Se você precisar de mais de um tipo de cópia (por exemplo: profunda / superficial), poderá especificá-la com um parâmetro no construtor de cópia, embora, em minha experiência, eu ache que geralmente uma mistura de cópia profunda e superficial é o que preciso.

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

Há um grande argumento de que você deve implementar clone () usando um construtor de cópia protegida

É melhor fornecer um construtor de cópia protegida (não pública) e invocá-lo a partir do método clone. Isso nos dá a capacidade de delegar a tarefa de criar um objeto a uma instância da própria classe, fornecendo assim extensibilidade e também criando com segurança os objetos usando o construtor de cópia protegida.

Portanto, esta não é uma questão "versus". Você pode precisar de um (s) construtor (es) de cópia e uma interface clone para fazer isso direito.

(Embora a interface pública recomendada seja a interface Clone () em vez de baseada no Construtor.)

Não se deixe levar pelo argumento explícito profundo ou superficial das outras respostas. No mundo real, quase sempre é algo intermediário - e de qualquer forma, não deve ser a preocupação de quem liga.

O contrato Clone () é simplesmente "não mudará quando eu mudar o primeiro". O quanto do gráfico você precisa copiar ou como evitar a recursão infinita para fazer isso acontecer não deve preocupar o chamador.

Implementar ICloneable não é recomendado devido ao fato de que não é especificado se é uma cópia profunda ou superficial, então eu escolheria o construtor, ou apenas implementaria algo você mesmo. Talvez chame de DeepCopy () para tornar realmente óbvio!

Você terá problemas com construtores de cópia e classes abstratas. Imagine que você queira fazer o seguinte:

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

Logo depois de fazer o acima, você começa a desejar ter usado uma interface ou se conformado com uma implementação DeepCopy () / ICloneable.Clone ().

O problema com ICloneable é tanto intenção quanto consistência. Nunca fica claro se é uma cópia profunda ou superficial. Por causa disso, provavelmente nunca é usado apenas de uma maneira ou de outra.

Não acho um construtor de cópia pública para ser mais claro sobre esse assunto.

Dito isso, gostaria de apresentar um sistema de método que funciona para você e retransmite a intenção (a'la um pouco autodocumentável)

Se o objeto que você está tentando copiar for serializável, você pode cloná-lo, serializando-o e desserializando-o. Então você não precisa escrever um construtor de cópia para cada classe.

Não tenho acesso ao código agora, mas é algo assim

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
}

É dependente da semântica de cópia da classe em questão, que você deve definir como o desenvolvedor. O método escolhido geralmente é baseado nos casos de uso pretendidos da classe. Talvez faça sentido implementar os dois métodos. Mas ambos compartilham desvantagens semelhantes - não está exatamente claro qual método de cópia eles implementam. Isso deve ser claramente declarado na documentação de sua classe.

Para mim ter:

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

ao invés 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();

parecia uma declaração de intenções mais clara.

Acho que deve haver um padrão para objetos clonáveis, embora não tenha certeza de qual deve ser exatamente o padrão. Com relação à clonagem, parece que existem três tipos de classes:

1. Aqueles que explicitamente suportam clonagem profunda
2. Aqueles em que a clonagem por membro funcionará como clonagem profunda, mas que não têm nem precisam de suporte explícito.
3. Aqueles que não podem ser clonados de forma útil e em que a clonagem por membros produzirá resultados ruins.

Até onde eu posso dizer, a única maneira (pelo menos em .net 2.0) de obter um novo objeto da mesma classe de um objeto existente é usar MemberwiseClone. Um bom padrão seria ter uma função "nova" / "Sombras" Clone que sempre retorna o tipo atual, cuja definição é sempre chamar MemberwiseClone e então chamar uma sub-rotina virtual protegida CleanupClone (originalObject). A rotina CleanupCode deve chamar base.Cleanupcode para lidar com as necessidades de clonagem do tipo base e, em seguida, adicionar sua própria limpeza. Se a rotina de clonagem tiver que usar o objeto original, ele terá que ser typecast, mas caso contrário, a única typecasting será na chamada MemberwiseClone.

Infelizmente, o nível mais baixo de classe que era do tipo (1) acima, em vez do tipo (2), teria que ser codificado para assumir que seus tipos inferiores não precisariam de nenhum suporte explícito para clonagem. Eu realmente não vejo nenhuma maneira de contornar isso.

Mesmo assim, acho que ter um padrão definido seria melhor do que nada.

A propósito, se alguém souber que seu tipo base suporta iCloneable, mas não souber o nome da função que ele usa, há alguma maneira de fazer referência à função iCloneable.Clone de seu tipo base?

Se você ler todas as respostas e discussões interessantes, ainda poderá se perguntar como exatamente copia as propriedades - todas elas explicitamente, ou existe uma maneira mais elegante de fazer isso? Se essa for a sua pergunta restante, dê uma olhada (no StackOverflow):

Como posso clonar “profundamente” as propriedades de classes de terceiros usando um método de extensão genérico?

Ele descreve como implementar um método de extensão CreateCopy()que cria uma cópia "profunda" do objeto, incluindo todas as propriedades (sem ter que copiar propriedade por propriedade manualmente).