Por que nenhum ICloneable <T>?

Existe uma razão específica para a inexistência de um genérico ICloneable<T>?

Seria muito mais confortável, se eu não precisasse transmiti-lo toda vez que clonasse algo.

O ICloneable é considerado uma API incorreta agora, pois não especifica se o resultado é uma cópia profunda ou superficial. Eu acho que é por isso que eles não melhoram essa interface.

Você provavelmente pode fazer um método de extensão de clonagem digitado, mas acho que exigiria um nome diferente, já que os métodos de extensão têm menos prioridade que os originais.

Além de resposta de Andrey (que eu concordo com, +1) - quando ICloneable é feito, você pode também escolher implementação explícita para fazer o público Clone()retornar um objeto digitado:

public Foo Clone() { /* your code */ }
object ICloneable.Clone() {return Clone();}

Claro que há um segundo problema com uma ICloneable<T>herança genérica .

Se eu tiver:

public class Foo {}
public class Bar : Foo {}

E eu implementei ICloneable<T>, então eu implemento ICloneable<Foo>? ICloneable<Bar>? Você começa rapidamente a implementar muitas interfaces idênticas ... Compare com um elenco ... e é realmente tão ruim assim?

Eu preciso perguntar, o que exatamente você faria com a interface além de implementá-la? As interfaces geralmente são úteis apenas quando você faz conversão para ela (por exemplo, essa classe suporta 'IBar') ou possui parâmetros ou configuradores que a utilizam (por exemplo, eu uso um 'IBar'). Com o ICloneable - percorremos todo o Framework e falhamos em encontrar um único uso em qualquer lugar que não fosse uma implementação dele. Também não conseguimos encontrar nenhum uso no 'mundo real' que faça algo além de implementá-lo (nos ~ 60.000 aplicativos aos quais temos acesso).

Agora, se você gostaria de impor um padrão que deseja que seus objetos 'clonáveis' implementem, esse é um uso muito bom - e vá em frente. Você também pode decidir exatamente o que "clonagem" significa para você (por exemplo, profundo ou superficial). No entanto, nesse caso, não há necessidade de nós (o BCL) defini-lo. Só definimos abstrações na BCL quando há necessidade de trocar instâncias digitadas como essa abstração entre bibliotecas não relacionadas.

David Kean (Equipe BCL)

Eu acho que a pergunta "por que" é desnecessária. Há muitas interfaces / classes / etc ... que são muito úteis, mas não fazem parte da biblioteca base do .NET Frameworku.

Mas, principalmente, você pode fazer isso sozinho.

public interface ICloneable<T> : ICloneable {
    new T Clone();
}

public abstract class CloneableBase<T> : ICloneable<T> where T : CloneableBase<T> {
    public abstract T Clone();
    object ICloneable.Clone() { return this.Clone(); }
}

public abstract class CloneableExBase<T> : CloneableBase<T> where T : CloneableExBase<T> {
    protected abstract T CreateClone();
    protected abstract void FillClone( T clone );
    public override T Clone() {
        T clone = this.CreateClone();
        if ( object.ReferenceEquals( clone, null ) ) { throw new NullReferenceException( "Clone was not created." ); }
        return clone
    }
}

public abstract class PersonBase<T> : CloneableExBase<T> where T : PersonBase<T> {
    public string Name { get; set; }

    protected override void FillClone( T clone ) {
        clone.Name = this.Name;
    }
}

public sealed class Person : PersonBase<Person> {
    protected override Person CreateClone() { return new Person(); }
}

public abstract class EmployeeBase<T> : PersonBase<T> where T : EmployeeBase<T> {
    public string Department { get; set; }

    protected override void FillClone( T clone ) {
        base.FillClone( clone );
        clone.Department = this.Department;
    }
}

public sealed class Employee : EmployeeBase<Employee> {
    protected override Employee CreateClone() { return new Employee(); }
}

É muito fácil escrever a interface você mesmo, se precisar:

public interface ICloneable<T> : ICloneable
        where T : ICloneable<T>
{
    new T Clone();
}

Tendo lido recentemente o artigo Por que copiar um objeto é uma coisa terrível a se fazer? , Acho que essa pergunta precisa de clafiricação adicional. Outras respostas aqui fornecem bons conselhos, mas a resposta ainda não está completa - por que não ICloneable<T>?

1. Uso

   Então, você tem uma classe que a implementa. Enquanto anteriormente você tinha um método que queria ICloneable, agora ele precisa ser genérico para aceitar ICloneable<T>. Você precisaria editá-lo.

   Então, você poderia ter um método que verifica se há um objeto is ICloneable. E agora? Você não pode fazer is ICloneable<>e, como não conhece o tipo de objeto no tipo de compilação, não pode tornar o método genérico. Primeiro problema real.

   Então você precisa ter ambos ICloneable<T>e ICloneable, o primeiro implementando o último. Assim, um implementador precisaria implementar os dois métodos - object Clone()e T Clone(). Não, obrigado, já nos divertimos o suficiente IEnumerable.

   Como já apontado, há também a complexidade da herança. Embora a covariância pareça resolver esse problema, um tipo derivado precisa implementar ICloneable<T>seu próprio tipo, mas já existe um método com a mesma assinatura (= parâmetros, basicamente) - a Clone()da classe base. Tornar explícita sua nova interface de método de clone é inútil, você perderá a vantagem que procurava ao criar ICloneable<T>. Então adicione a newpalavra - chave. Mas não esqueça que você também precisaria substituir a classe base ' Clone()(a implementação deve permanecer uniforme para todas as classes derivadas, ou seja, para retornar o mesmo objeto de cada método clone, portanto, o método clone base deve ser virtual)! Mas, infelizmente, você não pode tanto overrideenewmétodos com a mesma assinatura. Ao escolher a primeira palavra-chave, você perderia a meta que queria ter ao adicionar ICloneable<T>. Ao escolher o segundo, você quebraria a própria interface, criando métodos que deveriam fazer o mesmo retornar objetos diferentes.

2. Ponto

   Você deseja ICloneable<T>conforto, mas o conforto não é para o que as interfaces são projetadas, seu significado é (em geral OOP) para unificar o comportamento dos objetos (embora em C # seja limitado à unificação do comportamento externo, por exemplo, métodos e propriedades, não seu funcionamento).

   Se o primeiro motivo ainda não o convenceu, você pode objetar que ICloneable<T>também funcione de forma restritiva, para limitar o tipo retornado pelo método clone. No entanto, o programador desagradável pode implementar ICloneable<T>onde T não é o tipo que está implementando. Portanto, para alcançar sua restrição, você pode adicionar uma boa restrição ao parâmetro genérico:
   public interface ICloneable<T> : ICloneable where T : ICloneable<T>
   certamente mais restritivo que o outro where, ainda não é possível restringir que T é o tipo que está implementando a interface (você pode derivar ICloneable<T>de outro tipo que o implementa).

   Veja bem, mesmo esse propósito não pode ser alcançado (o original ICloneable também falha nisso, nenhuma interface pode realmente limitar o comportamento da classe de implementação).

Como você pode ver, isso prova que a interface genérica é difícil de implementar completamente e também é realmente desnecessária e inútil.

Mas voltando à questão, o que você realmente procura é ter conforto ao clonar um objeto. Existem duas maneiras de fazer isso:

Métodos adicionais

public class Base : ICloneable
{
    public Base Clone()
    {
        return this.CloneImpl() as Base;
    }

    object ICloneable.Clone()
    {
        return this.CloneImpl();
    }

    protected virtual object CloneImpl()
    {
        return new Base();
    }
}

public class Derived : Base
{
    public new Derived Clone()
    {
        return this.CloneImpl() as Derived;
    }

    protected override object CloneImpl()
    {
        return new Derived();
    }
}

Essa solução fornece conforto e comportamento pretendido aos usuários, mas também é muito longa para ser implementada. Se não queremos que o método "confortável" retorne o tipo atual, é muito mais fácil ter apenaspublic virtual object Clone() .

Então, vamos ver a solução "definitiva" - o que em C # realmente pretende nos dar conforto?

Métodos de extensão!

public class Base : ICloneable
{
    public virtual object Clone()
    {
        return new Base();
    }
}

public class Derived : Base
{
    public override object Clone()
    {
        return new Derived();
    }
}

public static T Copy<T>(this T obj) where T : class, ICloneable
{
    return obj.Clone() as T;
}

É chamado Copiar para não colidir com os métodos Clone atuais (o compilador prefere os métodos declarados do tipo em vez dos de extensão). oclass restrição existe para a velocidade (não requer verificação nula etc.).

Espero que isso esclareça a razão pela qual não fazer ICloneable<T>. No entanto, é recomendável não implementar ICloneable.

Embora a pergunta seja muito antiga (cinco anos depois de escrever essas respostas :) e já tenha sido respondida, mas achei que este artigo responde muito bem à pergunta, verifique aqui

EDITAR:

Aqui está a citação do artigo que responde à pergunta (leia o artigo completo, inclui outras coisas interessantes):

Existem muitas referências na Internet que apontam para uma publicação de Brad Abrams em 2003 - na época empregada na Microsoft - na qual são discutidas algumas reflexões sobre o ICloneable. A entrada do blog pode ser encontrada neste endereço: Implementando o ICloneable . Apesar do título enganoso, esta entrada do blog pede para não implementar o ICloneable, principalmente por causa de confusão superficial / profunda. O artigo termina com uma sugestão direta: se você precisar de um mecanismo de clonagem, defina sua própria metodologia Clone ou Copiar e garanta que você documente claramente se é uma cópia profunda ou superficial. Um padrão apropriado é:public <type> Copy();

Um grande problema é que eles não podiam restringir T à mesma classe. Por exemplo, o que impediria você de fazer isso:

interface IClonable<T>
{
    T Clone();
}

class Dog : IClonable<JackRabbit>
{
    //not what you would expect, but possible
    JackRabbit Clone()
    {
        return new JackRabbit();
    }

}

Eles precisam de uma restrição de parâmetro como:

interfact IClonable<T> where T : implementing_type

É uma pergunta muito boa ... Você pode fazer o seu, no entanto:

interface ICloneable<T> : ICloneable
{
  new T Clone ( );
}

Andrey diz que é considerada uma API ruim, mas não ouvi nada sobre essa interface ficar obsoleta. E isso quebraria toneladas de interfaces ... O método Clone deve executar uma cópia superficial. Se o objeto também fornecer cópia em profundidade, um Clone sobrecarregado (profundidade em bool) pode ser usado.

Edição: Padrão que eu uso para "clonar" um objeto, está passando um protótipo no construtor.

class C
{
  public C ( C prototype )
  {
    ...
  }
}

Isso remove qualquer possível situação de implementação de código redundante. BTW, falando sobre as limitações do ICloneable, não cabe realmente ao objeto decidir se um clone raso ou profundo, ou mesmo um clone parcialmente raso / parcialmente profundo, deve ser executado? Deveríamos realmente nos importar, desde que o objeto funcione como pretendido? Em algumas ocasiões, uma boa implementação de Clone pode muito bem incluir clonagem superficial e profunda.