Jak poprawnie zastąpić metodę klonowania?

Muszę zaimplementować głębokiego klona w jednym z moich obiektów, który nie ma nadklasy.

Jaki jest najlepszy sposób na obsłużenie czeku CloneNotSupportedExceptionwyrzuconego przez superklasę (czyli Object)?

Współpracownik poradził mi, żebym to zrobił w następujący sposób:

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

    // Deep clone member fields here

    return foo;
}

Wydaje mi się, że jest to dobre rozwiązanie, ale chciałem przekazać to społeczności StackOverflow, aby sprawdzić, czy są jakieś inne spostrzeżenia, które mogę uwzględnić. Dzięki!

Czy absolutnie musisz użyć clone? Większość ludzi zgadza się, że Java clonejest zepsuta.

Josh Bloch on Design - Copy Constructor versus Cloning

Jeśli przeczytałeś artykuł o klonowaniu w mojej książce, zwłaszcza jeśli czytasz między wierszami, będziesz wiedział, że moim zdaniem clonejest głęboko zepsuty. […] Szkoda, że Cloneablejest zepsuty, ale się zdarza.

Możesz przeczytać więcej dyskusji na ten temat w jego książce Effective Java 2nd Edition, Item 11: Override clonerozsądnie . Zamiast tego zaleca użycie konstruktora kopiującego lub fabryki kopiowania.

Następnie napisał kilka stron o tym, jak, jeśli uważasz, że musisz, powinieneś wdrażać clone. Ale zakończył tym:

Czy wszystkie te zawiłości są naprawdę konieczne? Rzadko. Jeśli rozszerzasz klasę, która implementuje Cloneable, nie masz innego wyboru, jak zaimplementować dobrze zachowaną clonemetodę. W przeciwnym razie lepiej będzie zapewnić alternatywne sposoby kopiowania obiektów lub po prostu nie zapewnić takiej możliwości .

Nacisk był jego, nie mój.

Ponieważ jasno wskazałeś, że nie masz innego wyboru, jak tylko wdrożyć clone, oto, co możesz zrobić w tym przypadku: upewnij się, że MyObject extends java.lang.Object implements java.lang.Cloneable. W takim przypadku możesz zagwarantować, że NIGDY nie złapiesz CloneNotSupportedException. Rzucanie, AssertionErrorjak sugerowali niektórzy, wydaje się rozsądne, ale możesz również dodać komentarz wyjaśniający, dlaczego blok catch nigdy nie zostanie wprowadzony w tym konkretnym przypadku .

Alternatywnie, jak sugerowali inni, możesz być może zaimplementować clonebez wywoływania super.clone.

Czasami łatwiej jest zaimplementować konstruktor kopiujący:

public MyObject (MyObject toClone) {
}

Oszczędza Ci to kłopotów z obsługą CloneNotSupportedException, działa z finalpolami i nie musisz martwić się o typ do zwrotu.

Sposób działania twojego kodu jest bardzo zbliżony do „kanonicznego” sposobu jego pisania. Ale rzuciłbym AssertionErrorw pułapkę. Sygnalizuje, że ta linia nigdy nie powinna zostać osiągnięta.

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

Istnieją dwa przypadki, w których CloneNotSupportedExceptionzostanie wyrzucony testament:

1. Klonowana klasa nie została zaimplementowana Cloneable(zakładając, że faktyczne klonowanie ostatecznie odroczone zostanie do Objectmetody clone). Jeśli klasa, w której piszesz tę metodę w implementacjach Cloneable, nigdy się nie wydarzy (ponieważ wszystkie podklasy odziedziczą ją odpowiednio).
2. Wyjątek jest jawnie zgłaszany przez implementację - jest to zalecany sposób zapobiegania klonowaniu w podklasie, gdy nadklasa jest Cloneable.

Ten drugi przypadek nie może wystąpić w twojej klasie (ponieważ bezpośrednio wywołujesz metodę nadklasy w trybloku, nawet jeśli jest wywoływana z wywołania podklasy super.clone()), a ten pierwszy nie powinien, ponieważ twoja klasa wyraźnie powinna implementować Cloneable.

Zasadniczo powinieneś na pewno zarejestrować błąd, ale w tym konkretnym przypadku stanie się to tylko wtedy, gdy zepsujesz definicję swojej klasy. Dlatego traktuj go jak sprawdzoną wersję NullPointerException(lub podobną) - nigdy nie zostanie wyrzucona, jeśli twój kod działa.

W innych sytuacjach trzeba by być przygotowanym na taką ewentualność - nie ma gwarancji, że dany przedmiot jest Cloneable, więc podczas połowu wyjątek należy podjąć odpowiednie działania w zależności od tego warunku (kontynuacja istniejącego obiektu, wziąć alternatywną strategię klonowania np. serialize-deserialize, wyrzuć, IllegalParameterExceptionjeśli twoja metoda wymaga parametru przez cloneable itp.).

Edycja : Chociaż ogólnie powinienem zaznaczyć, że tak, clone()naprawdę trudno jest poprawnie zaimplementować i trudno jest dzwoniącym wiedzieć, czy wartość zwracana będzie taka, jakiej chcą, podwójnie, jeśli weźmie się pod uwagę klony głębokie i płytkie. Często lepiej jest po prostu całkowicie uniknąć całej sytuacji i użyć innego mechanizmu.

Użyj serializacji, aby wykonać głębokie kopie. Nie jest to najszybsze rozwiązanie, ale nie zależy od typu.

Możesz zaimplementować chronione konstruktory kopiujące, takie jak:

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

O ile większość odpowiedzi tutaj jest poprawnych, muszę powiedzieć, że Twoje rozwiązanie jest również sposobem, w jaki robią to faktyczni programiści Java API. (Albo Josh Bloch albo Neal Gafter)

Oto wyciąg z openJDK, klasy 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);
    }
}

Jak zauważyłeś i inni wspomnieli, CloneNotSupportedExceptionnie ma prawie żadnych szans na wyrzucenie, jeśli zadeklarowałeś, że implementujesz Cloneableinterfejs.

Ponadto, nie ma potrzeby, aby zastąpić metodę, jeśli nie nic nowego w zastąpiona metoda zrobić. Musisz to zmienić tylko wtedy, gdy musisz wykonać dodatkowe operacje na obiekcie lub musisz go upublicznić.

Ostatecznie nadal najlepiej jest tego unikać i robić to w inny sposób.

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

                }
        }
    }
}

Tylko dlatego, że implementacja Cloneable w Javie jest zepsuta, nie oznacza to, że nie możesz stworzyć własnego.

Jeśli prawdziwym celem OP było stworzenie głębokiego klonu, myślę, że można stworzyć taki interfejs:

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

następnie użyj wspomnianego wcześniej konstruktora prototypów, aby go zaimplementować:

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

i inna klasa z polem obiektu 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);
    }
}

W ten sposób można łatwo i głęboko sklonować obiekt klasy BClass bez potrzeby używania @SuppressWarnings lub innego sztucznego kodu.