Come sovrascrivere correttamente il metodo di clonazione?

Devo implementare un clone profondo in uno dei miei oggetti che non ha una superclasse.

Qual è il modo migliore per gestire il check CloneNotSupportedExceptionlanciato dalla superclasse (che è Object)?

Un collega mi ha consigliato di gestirlo nel modo seguente:

@Override
public MyObject clone()
{
    MyObject foo;
    try
    {
        foo = (MyObject) super.clone();
    }
    catch (CloneNotSupportedException e)
    {
        throw new Error();
    }

    // Deep clone member fields here

    return foo;
}

Questa mi sembra una buona soluzione, ma volevo inviarla alla community di StackOverflow per vedere se ci sono altri approfondimenti che posso includere. Grazie!

Devi assolutamente usare clone? La maggior parte delle persone concorda sul fatto che Java clonesia rotto.

Josh Bloch su Design - Copy Constructor vs Cloning

Se hai letto l'articolo sulla clonazione nel mio libro, soprattutto se leggi tra le righe, saprai che secondo me cloneè profondamente rotto. [...] È un peccato che Cloneablesia rotto, ma succede.

Puoi leggere ulteriori discussioni sull'argomento nel suo libro Effective Java 2nd Edition, Item 11: Override clonejudiciously . Raccomanda invece di utilizzare un costruttore di copie o una fabbrica di copie.

Ha continuato a scrivere pagine di pagine su come, se ritieni di doverlo fare, dovresti implementare clone. Ma ha chiuso con questo:

Tutte queste complessità sono davvero necessarie? Raramente. Se estendi una classe che implementa Cloneable, non hai altra scelta che implementare un clonemetodo ben comportato . Altrimenti, è meglio fornire mezzi alternativi per la copia di oggetti o semplicemente non fornire la capacità .

L'enfasi era sua, non mia.

Dato che hai chiarito che non hai altra scelta che implementare clone, ecco cosa puoi fare in questo caso: assicurati che MyObject extends java.lang.Object implements java.lang.Cloneable. Se è così, puoi garantire che non prenderai MAI un file CloneNotSupportedException. Lanciare AssertionErrorcome alcuni hanno suggerito sembra ragionevole, ma puoi anche aggiungere un commento che spiega perché il blocco catch non verrà mai inserito in questo caso particolare .

In alternativa, come hanno suggerito anche altri, puoi magari implementare clonesenza chiamare super.clone.

A volte è più semplice implementare un costruttore di copie:

public MyObject (MyObject toClone) {
}

Ti risparmia la fatica di maneggiare CloneNotSupportedException, lavora con i finalcampi e non devi preoccuparti del tipo da restituire.

Il modo in cui funziona il tuo codice è molto vicino al modo "canonico" di scriverlo. Però ne getterei una AssertionErrordentro la presa. Segnala che quella linea non dovrebbe mai essere raggiunta.

catch (CloneNotSupportedException e) {
    throw new AssertionError(e);
}

Ci sono due casi in cui CloneNotSupportedExceptionverrà lanciato:

1. La classe da clonare non viene implementata Cloneable(supponendo che la clonazione effettiva alla fine rimanda al Objectmetodo di clonazione di). Se la classe su cui stai scrivendo questo metodo in implements Cloneable, ciò non accadrà mai (poiché qualsiasi sottoclasse lo erediterà in modo appropriato).
2. L'eccezione viene lanciata esplicitamente da un'implementazione: questo è il modo consigliato per prevenire la clonabilità in una sottoclasse quando la superclasse lo è Cloneable.

Quest'ultimo caso non può verificarsi nella tua classe (poiché stai chiamando direttamente il metodo della superclasse nel tryblocco, anche se invocato da una chiamata di sottoclasse super.clone()) e il primo non dovrebbe poiché la tua classe dovrebbe chiaramente implementare Cloneable.

Fondamentalmente, dovresti sicuramente registrare l'errore, ma in questo caso particolare accadrà solo se sbagli la definizione della tua classe. Quindi trattalo come una versione verificata di NullPointerException(o simile): non verrà mai lanciato se il tuo codice è funzionante.

In altre situazioni dovresti essere preparato per questa eventualità: non c'è garanzia che un determinato oggetto sia clonabile, quindi quando si cattura l'eccezione è necessario intraprendere un'azione appropriata a seconda di questa condizione (continuare con l'oggetto esistente, adottare una strategia di clonazione alternativa es. serializzare-deserializzare, lanciare un IllegalParameterExceptionse il metodo richiede il parametro da clonabile, ecc. ecc.).

Modifica : anche se nel complesso dovrei sottolineare che sì, clone()è davvero difficile da implementare correttamente e difficile per i chiamanti sapere se il valore di ritorno sarà quello che vogliono, doppiamente quando si considerano i cloni profondi o superficiali. Spesso è meglio evitare del tutto tutto e utilizzare un altro meccanismo.

Usa la serializzazione per creare copie complete. Questa non è la soluzione più rapida ma non dipende dal tipo.

Puoi implementare costruttori di copie protette in questo modo:

/* This is a protected copy constructor for exclusive use by .clone() */
protected MyObject(MyObject that) {
    this.myFirstMember = that.getMyFirstMember(); //To clone primitive data
    this.mySecondMember = that.getMySecondMember().clone(); //To clone complex objects
    // etc
}

public MyObject clone() {
    return new MyObject(this);
}

Per quanto la maggior parte delle risposte qui siano valide, devo dire che la tua soluzione è anche il modo in cui lo fanno gli attuali sviluppatori di API Java. (O Josh Bloch o Neal Gafter)

Ecco un estratto da openJDK, classe ArrayList:

public Object clone() {
    try {
        ArrayList<?> v = (ArrayList<?>) super.clone();
        v.elementData = Arrays.copyOf(elementData, size);
        v.modCount = 0;
        return v;
    } catch (CloneNotSupportedException e) {
        // this shouldn't happen, since we are Cloneable
        throw new InternalError(e);
    }
}

Come avrai notato e altri menzionati, non CloneNotSupportedExceptionha quasi alcuna possibilità di essere lanciato se hai dichiarato di implementare l' Cloneableinterfaccia.

Inoltre, non è necessario sovrascrivere il metodo se non si esegue nulla di nuovo nel metodo sovrascritto. È necessario sovrascriverlo solo quando è necessario eseguire operazioni aggiuntive sull'oggetto o è necessario renderlo pubblico.

In definitiva, è comunque meglio evitarlo e farlo in un altro modo.

public class MyObject implements Cloneable, Serializable{   

    @Override
    @SuppressWarnings(value = "unchecked")
    protected MyObject clone(){
        ObjectOutputStream oos = null;
        ObjectInputStream ois = null;
        try {
            ByteArrayOutputStream bOs = new ByteArrayOutputStream();
            oos = new ObjectOutputStream(bOs);
            oos.writeObject(this);
            ois = new ObjectInputStream(new ByteArrayInputStream(bOs.toByteArray()));
            return  (MyObject)ois.readObject();

        } catch (Exception e) {
            //Some seriouse error :< //
            return null;
        }finally {
            if (oos != null)
                try {
                    oos.close();
                } catch (IOException e) {

                }
            if (ois != null)
                try {
                    ois.close();
                } catch (IOException e) {

                }
        }
    }
}

Solo perché l'implementazione di java di Cloneable è interrotta, non significa che non puoi crearne uno tuo.

Se il vero scopo di OP fosse creare un clone profondo, penso che sia possibile creare un'interfaccia come questa:

public interface Cloneable<T> {
    public T getClone();
}

quindi utilizzare il costruttore del prototipo menzionato prima per implementarlo:

public class AClass implements Cloneable<AClass> {
    private int value;
    public AClass(int value) {
        this.vaue = value;
    }

    protected AClass(AClass p) {
        this(p.getValue());
    }

    public int getValue() {
        return value;
    }

    public AClass getClone() {
         return new AClass(this);
    }
}

e un'altra classe con un campo oggetto AClass:

public class BClass implements Cloneable<BClass> {
    private int value;
    private AClass a;

    public BClass(int value, AClass a) {
         this.value = value;
         this.a = a;
    }

    protected BClass(BClass p) {
        this(p.getValue(), p.getA().getClone());
    }

    public int getValue() {
        return value;
    }

    public AClass getA() {
        return a;
    }

    public BClass getClone() {
         return new BClass(this);
    }
}

In questo modo puoi clonare facilmente in profondità un oggetto della classe BClass senza bisogno di @SuppressWarnings o altro codice ingannevole.