Perché nessun ICloneable <T>?

C'è un motivo particolare per cui ICloneable<T>non esiste un generico ?

Sarebbe molto più comodo, se non avessi bisogno di lanciarlo ogni volta che clonavo qualcosa.

ICloneable è ora considerata una cattiva API, poiché non specifica se il risultato è una copia profonda o superficiale. Penso che sia per questo che non migliorano questa interfaccia.

Probabilmente puoi fare un metodo di estensione della clonazione tipizzato, ma penso che richiederebbe un nome diverso poiché i metodi di estensione hanno meno priorità rispetto a quelli originali.

Oltre alla risposta di Andrey (che sono d'accordo con, +1) - quando ICloneable è fatto, si può anche scegliere esplicito implementazione per rendere il pubblico Clone()di ritorno un oggetto tipizzato:

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

Naturalmente c'è un secondo problema con una ICloneable<T>eredità generica .

Se ho:

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

E ho implementato ICloneable<T>, quindi ho implementato ICloneable<Foo>? ICloneable<Bar>? Inizi rapidamente a implementare molte interfacce identiche ... Confronta con un cast ... ed è davvero così male?

Devo chiederti, cosa faresti esattamente con l'interfaccia oltre a implementarla? Le interfacce sono in genere utili solo quando si esegue il cast su di essa (ad esempio, questa classe supporta "IBar") o hanno parametri o setter che la accettano (ovvero, prendo una "IBar"). Con ICloneable - abbiamo esaminato l'intero Framework e non siamo riusciti a trovare un singolo utilizzo ovunque che fosse qualcosa di diverso da una sua implementazione. Inoltre, non siamo riusciti a trovare alcun utilizzo nel "mondo reale" che faccia qualcosa di diverso dall'implementarlo (nelle ~ 60.000 app a cui abbiamo accesso).

Ora, se vuoi solo applicare un modello che desideri implementare i tuoi oggetti "clonabili", è un uso del tutto perfetto - e vai avanti. Puoi anche decidere esattamente cosa significa "clonazione" per te (cioè profondo o superficiale). Tuttavia, in tal caso, non è necessario per noi (il BCL) definirlo. Definiamo astrazioni nel BCL solo quando è necessario scambiare istanze tipizzate come tale astrazione tra librerie non correlate.

David Kean (BCL Team)

Penso che la domanda "perché" sia inutile. Esistono molte interfacce / classi / ecc ... che sono molto utili, ma non fanno parte della libreria di base di .NET Frameworku.

Ma soprattutto puoi farlo da solo.

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

È abbastanza facile scrivere l'interfaccia da soli se ne hai bisogno:

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

Avendo letto di recente l'articolo Perché copiare un oggetto è una cosa terribile da fare? , Penso che questa domanda abbia bisogno di ulteriori clafirication. Altre risposte qui forniscono buoni consigli, ma la risposta non è completa - perché no ICloneable<T>?

1. uso

   Quindi, hai una classe che la implementa. Mentre prima avevi un metodo che desiderava ICloneable, ora deve essere generico da accettare ICloneable<T>. Dovresti modificarlo.

   Quindi, potresti avere un metodo che controlla se un oggetto is ICloneable. E adesso? Non puoi farlo is ICloneable<>e poiché non conosci il tipo di oggetto al tipo di compilazione, non puoi rendere generico il metodo. Primo vero problema.

   Quindi devi avere entrambi ICloneable<T>e ICloneable, il primo implementando il secondo. Quindi un implementatore dovrebbe implementare entrambi i metodi - object Clone()e T Clone(). No, grazie, ci siamo già già divertiti abbastanza IEnumerable.

   Come già sottolineato, esiste anche la complessità dell'eredità. Mentre la covarianza può sembrare risolvere questo problema, un tipo derivato deve implementare ICloneable<T>il proprio tipo, ma esiste già un metodo con la stessa firma (= parametri, in sostanza) - quello Clone()della classe base. Rendere esplicita la tua nuova interfaccia del metodo clone è inutile, perderai il vantaggio che hai cercato durante la creazione ICloneable<T>. Quindi aggiungi la newparola chiave. Ma non dimenticare che dovresti anche sovrascrivere la classe base ' Clone()(l'implementazione deve rimanere uniforme per tutte le classi derivate, cioè restituire lo stesso oggetto da ogni metodo clone, quindi deve essere il metodo clone base virtual)! Ma, sfortunatamente, non è possibile entrambioverride enewmetodi con la stessa firma. Scegliendo la prima parola chiave, si perderebbe l'obiettivo che si desidera avere quando si aggiunge ICloneable<T>. Lanciando il secondo, si romperà l'interfaccia stessa, facendo metodi che dovrebbero fare lo stesso restituire oggetti diversi.

2. Punto

   Desiderate il ICloneable<T>comfort, ma il comfort non è ciò per cui sono progettate le interfacce, il loro significato è (in generale OOP) unificare il comportamento degli oggetti (sebbene in C # sia limitato all'unificazione del comportamento esteriore, ad esempio i metodi e le proprietà, non il loro funzionamento).

   Se il primo motivo non ti ha ancora convinto, potresti obiettare che ICloneable<T>potrebbe funzionare anche in modo restrittivo, per limitare il tipo restituito dal metodo clone. Tuttavia, il programmatore cattivo può implementare ICloneable<T>dove T non è il tipo che lo sta implementando. Quindi, per ottenere la tua restrizione, puoi aggiungere un bel vincolo al parametro generico:
   public interface ICloneable<T> : ICloneable where T : ICloneable<T>
   Certamente più restrittivo di quello senza where, non puoi ancora limitare che T è il tipo che sta implementando l'interfaccia (puoi derivare da ICloneable<T>un tipo diverso che lo implementa).

   Vedete, anche questo scopo non può essere raggiunto (anche l'originale ICloneablefallisce, nessuna interfaccia può davvero limitare il comportamento della classe di implementazione).

Come puoi vedere, questo dimostra che rendere l'interfaccia generica sia difficile da implementare completamente, ma anche non necessaria e inutile.

Ma tornando alla domanda, quello che cerchi veramente è avere conforto durante la clonazione di un oggetto. Ci sono due modi per farlo:

Metodi aggiuntivi

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

Questa soluzione offre agli utenti comfort e comportamento previsto, ma è anche troppo lunga da implementare. Se non volessimo che il metodo "comodo" restituisse il tipo corrente, è molto più facile averlo public virtual object Clone().

Vediamo quindi la soluzione "definitiva": cosa in C # è veramente intenzionato a darci conforto?

Metodi di estensione!

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

Si chiama Copia per non scontrarsi con gli attuali metodi Clone (il compilatore preferisce i metodi dichiarati del tipo rispetto a quelli di estensione). Il classvincolo è lì per la velocità (non richiede controllo null ecc.).

Spero che questo chiarisca il motivo per cui non farlo ICloneable<T>. Tuttavia, si consiglia di non implementare ICloneableaffatto.

Sebbene la domanda sia molto vecchia (a 5 anni dalla stesura di questa risposta :) ed è già stata risolta, ma ho trovato questo articolo che risponde abbastanza bene alla domanda, controlla qui

MODIFICARE:

Ecco la citazione dall'articolo che risponde alla domanda (assicurati di leggere l'articolo completo, include altre cose interessanti):

Ci sono molti riferimenti su Internet che rimandano a un post del blog 2003 di Brad Abrams - all'epoca impiegato in Microsoft - in cui vengono discusse alcune considerazioni su ICloneable. La voce del blog è disponibile a questo indirizzo: Implementazione di ICloneable . Nonostante il titolo fuorviante, questo post sul blog invita a non implementare ICloneable, principalmente a causa della confusione superficiale / profonda. L'articolo termina con un semplice suggerimento: se hai bisogno di un meccanismo di clonazione, definisci la tua metodologia Clone o Copy e assicurati di documentare chiaramente se si tratta di una copia profonda o superficiale. Un modello appropriato è:public <type> Copy();

Un grosso problema è che non potevano limitare T alla stessa classe. Per esempio cosa ti impedirebbe di fare questo:

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

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

}

Hanno bisogno di una limitazione dei parametri come:

interfact IClonable<T> where T : implementing_type

È un'ottima domanda ... Puoi crearne una tua, però:

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

Andrey dice che è considerata una cattiva API, ma non ho sentito nulla su questa interfaccia diventare deprecata. E ciò spezzerebbe tonnellate di interfacce ... Il metodo Clone dovrebbe eseguire una copia superficiale. Se l'oggetto fornisce anche una copia approfondita, è possibile utilizzare un Clone sovraccarico (profondità bool).

EDIT: Pattern che uso per "clonare" un oggetto, sta passando un prototipo nel costruttore.

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

Ciò rimuove qualsiasi potenziale situazione di implementazione del codice ridondante. A proposito, parlando dei limiti di ICloneable, non sta davvero all'oggetto stesso decidere se eseguire un clone superficiale o profondo, o anche un clone parzialmente superficiale / parzialmente profondo? Dovremmo davvero preoccuparci, purché l'oggetto funzioni come previsto? In alcune occasioni, una buona implementazione di Clone potrebbe benissimo includere sia la clonazione superficiale che quella profonda.