Comment remplacer correctement la méthode de clonage?

J'ai besoin d'implémenter un clone profond dans l'un de mes objets qui n'a pas de superclasse.

Quelle est la meilleure façon de gérer le CloneNotSupportedExceptionjeté vérifié par la superclasse (qui est Object)?

Un collègue m'a conseillé de le gérer de la manière suivante:

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

    // Deep clone member fields here

    return foo;
}

Cela me semble être une bonne solution, mais je voulais la lancer à la communauté StackOverflow pour voir s'il y a d'autres informations que je peux inclure. Merci!

Devez-vous absolument utiliser clone? La plupart des gens conviennent que Java cloneest cassé.

Josh Bloch sur la conception - Constructeur de copie versus clonage

Si vous avez lu l'article sur le clonage dans mon livre, surtout si vous lisez entre les lignes, vous saurez que je pense qu'il cloneest profondément brisé. [...] C'est une honte qui Cloneableest cassée, mais ça arrive.

Vous pouvez lire plus de discussion sur le sujet dans son livre Effective Java 2nd Edition, Item 11: Override clonejudicieusement . Il recommande à la place d'utiliser un constructeur de copie ou une fabrique de copies.

Il a continué en écrivant des pages de pages sur la façon dont, si vous pensez que vous devez, vous devriez mettre en œuvre clone. Mais il a conclu avec ceci:

Toutes ces complexités sont-elles vraiment nécessaires? Rarement. Si vous étendez une classe qui implémente Cloneable, vous n'avez guère d'autre choix que d'implémenter une cloneméthode bien conduite . Sinon, il vaut mieux fournir des moyens alternatifs de copie d'objets, ou simplement ne pas fournir la capacité .

L'accent était le sien, pas le mien.

Puisque vous avez clairement indiqué que vous n'aviez pas d'autre choix que de mettre en œuvre clone, voici ce que vous pouvez faire dans ce cas: assurez-vous que MyObject extends java.lang.Object implements java.lang.Cloneable. Si tel est le cas, vous pouvez garantir que vous n'attraperez JAMAIS un CloneNotSupportedException. Lancer AssertionErrorcomme certains l'ont suggéré semble raisonnable, mais vous pouvez également ajouter un commentaire expliquant pourquoi le bloc catch ne sera jamais entré dans ce cas particulier .

Alternativement, comme d'autres l'ont également suggéré, vous pouvez peut-être implémenter clonesans appeler super.clone.

Parfois, il est plus simple d'implémenter un constructeur de copie:

public MyObject (MyObject toClone) {
}

Cela vous évite les problèmes de manipulation CloneNotSupportedException, fonctionne avec les finalchamps et vous n'avez pas à vous soucier du type à retourner.

La façon dont votre code fonctionne est assez proche de la manière «canonique» de l'écrire. Je jetterais un AssertionErrordans la prise, cependant. Cela signale que cette ligne ne doit jamais être atteinte.

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

Il y a deux cas dans lesquels le CloneNotSupportedExceptionsera lancé:

1. La classe clonée n'est pas implémentée Cloneable(en supposant que le clonage réel soit finalement reporté à Objectla méthode de clonage de). Si la classe dans laquelle vous écrivez cette méthode implémente Cloneable, cela ne se produira jamais (car toutes les sous-classes en hériteront de manière appropriée).
2. L'exception est explicitement levée par une implémentation - c'est la méthode recommandée pour empêcher la clonabilité dans une sous-classe lorsque la superclasse l'est Cloneable.

Ce dernier cas ne peut pas se produire dans votre classe (car vous appelez directement la méthode de la superclasse dans le trybloc, même si elle est invoquée depuis un appel de sous-classe super.clone()) et le premier ne devrait pas car votre classe devrait clairement implémenter Cloneable.

Fondamentalement, vous devez enregistrer l'erreur à coup sûr, mais dans ce cas particulier, cela ne se produira que si vous gâchez la définition de votre classe. Traitez-le donc comme une version vérifiée de NullPointerException(ou similaire) - il ne sera jamais lancé si votre code est fonctionnel.

Dans d'autres situations, vous devez être préparé à cette éventualité - il n'y a aucune garantie qu'un objet donné soit clonable, donc lorsque vous interceptez l'exception, vous devez prendre les mesures appropriées en fonction de cette condition (continuer avec l'objet existant, adopter une stratégie de clonage alternative par exemple sérialiser-désérialiser, lancer un IllegalParameterExceptionsi votre méthode nécessite le paramètre par clonable, etc. etc.).

Edit : Bien que dans l'ensemble, je devrais souligner que oui, il clone()est vraiment difficile à implémenter correctement et difficile pour les appelants de savoir si la valeur de retour sera ce qu'ils veulent, doublement quand on considère les clones profonds vs peu profonds. Il est souvent préférable d'éviter complètement tout cela et d'utiliser un autre mécanisme.

Utilisez la sérialisation pour effectuer des copies complètes. Ce n'est pas la solution la plus rapide mais cela ne dépend pas du type.

Vous pouvez implémenter des constructeurs de copie protégée comme ceci:

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

Même si la plupart des réponses ici sont valables, je dois dire que votre solution est également la manière dont les développeurs d'API Java le font. (Soit Josh Bloch ou Neal Gafter)

Voici un extrait de 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);
    }
}

Comme vous l'avez remarqué et d'autres mentionnés, CloneNotSupportedExceptionn'a presque aucune chance d'être jeté si vous avez déclaré que vous implémentez l' Cloneableinterface.

En outre, vous n'avez pas besoin de remplacer la méthode si vous ne faites rien de nouveau dans la méthode remplacée. Vous ne devez le remplacer que lorsque vous devez effectuer des opérations supplémentaires sur l'objet ou que vous devez le rendre public.

En fin de compte, il est toujours préférable de l'éviter et de le faire d'une autre manière.

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) {

                }
        }
    }
}

Ce n'est pas parce que l'implémentation java de Cloneable est cassée que vous ne pouvez pas en créer une.

Si le véritable objectif d'OP était de créer un clone profond, je pense qu'il est possible de créer une interface comme celle-ci:

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

puis utilisez le constructeur prototype mentionné précédemment pour l'implémenter:

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

et une autre classe avec un champ objet 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);
    }
}

De cette façon, vous pouvez facilement cloner en profondeur un objet de la classe BClass sans avoir besoin de @SuppressWarnings ou d'un autre code astucieux.