Clone() vs Copy-Konstruktor - was in Java empfohlen wird

Question

Clone-Methode vs Kopie Konstruktor in Java. Welche ist die richtige Lösung? Wo soll jeder Fall verwendet werden?

Answer 1

Klon ist kaputt, also benutzen Sie es nicht.

die Clone-Methode der Object-Klasse ist eine etwas magische Methode, die tut, was keine reine Java-Methode jemals tun konnte: Es eine identische Kopie von sein Objekt erzeugt. Es war in der Primordial Object Superklasse seit der Beta-Release-Tage der Java Compiler *; und es, wie alle alten Magie, erfordert die entsprechende incantation den Zauber von unerwartet zu verhindern backfiring

Bevorzugen Sie eine Methode, die kopiert das Objekt

Foo copyFoo (Foo foo){ 
    Foo f = new Foo(); 
    //for all properties in FOo 
    f.set(foo.get()); 
    return f; 
} 

Lesen Sie mehr http://adtmag.com/articles/2000/01/18/effective-javaeffective-cloning.aspx

Answer 2

Bedenken Sie, dass clone() nicht out of the box funktioniert. Sie müssen Cloneable implementieren und die clone()-Methode außer Kraft setzen, die in public macht.

Es gibt ein paar Alternativen, die bevorzugt sind (da die clone() Methode hat viele Design-Fragen, wie in anderen Antworten angegeben), und die Kopie-Konstruktor würde erfordern Handarbeit:

• BeanUtils.cloneBean(original) schafft ein oberflächlicher Klon, wie der von Object.clone() erzeugte. (Diese Klasse ist von commons-beanutils)

• SerializationUtils.clone(original) erstellt einen tiefen Klon. (Dh die ganze Eigenschaften Graph geklont wird, nicht nur die erste Ebene) (von commons-lang), aber alle Klassen implementieren müssen Serializable

• Java Deep Cloning Library tief Klonen bietet, ohne die Notwendigkeit Serializable

Answer 3

Siehe auch umzusetzen : How to properly override clone method?. Klonen ist in Java gebrochen, es ist so hart, um es richtig zu machen, und selbst wenn es tut bietet nicht wirklich viel, so ist es nicht wirklich die Mühe wert.

Answer 4

Beachten Sie, dass der Kopierkonstruktor den Klassentyp auf den des Kopierkonstruktors beschränkt. Betrachten Sie das Beispiel:

// Need to clone person, which is type Person 
Person clone = new Person(person); 

Das funktioniert nicht, wenn person eine Unterklasse von Person sein könnte (oder wenn Person ist eine Schnittstelle). Das ist der springende Punkt von Klon, dass es den richtigen Typ zur Laufzeit dynamisch klonen kann (vorausgesetzt, Klon ist korrekt implementiert).

Person clone = (Person)person.clone(); 

oder

Person clone = (Person)SomeCloneUtil.clone(person); // See Bozho's answer 

Jetzt können person jede Art von Person unter der Annahme, dass clone richtig umgesetzt wird.

Answer 5

clone() wurde mit mehreren Fehlern erstellt (siehe this question), also vermeiden Sie es am besten.

Von Effective Java 2nd Edition, Punkt 11: Überschreiben von Klon umsichtig

alle Probleme im Zusammenhang mit klonbar Gegeben, ist es sicher zu sagen, dass andere Schnittstellen nicht verlängern sollte, und dass für Vererbung entworfen Klassen (Artikel 17) sollte es nicht umsetzen. Wegen seine vielen Mängel, wählen einige Experten Programmierer einfach nie überschreiben die Klon-Methode und nie, um es außer vielleicht, um kopieren Arrays. Wenn Sie eine Klasse für die Vererbung entwerfen, beachten Sie, dass Sie keine geschützte Klonmethode bereitstellen möchten. Daher ist für Unterklassen nicht möglich, Cloneable zu implementieren.

Dieses Buch beschreibt auch die vielen Vorteile, die Kopierkonstrukteure über Cloneable/Clone haben.

• Sie stützen sich nicht auf risikobehaftete außerObjektErstellung Mechanismus
• Sie verlange nicht nicht durchsetzbar Einhaltung dünn dokumentiert Konventionen
• Sie mit den richtigen Gebrauch der endgültigen Felder nicht
in Konflikt geraten
• Sie werfen keine unnötigen geprüften Ausnahmen
• Sie benötigen keine Umwandlungen.

Alle Standardsammlungen verfügen über Kopierkonstruktoren. Benutze sie.

List<Double> original = // some list 
List<Double> copy = new ArrayList<Double>(original); 

Answer 6

Große Traurigkeit: weder klonbar/Klon noch ein Konstruktor sind große Lösungen: ICH WILL NICHT die implementierende Klasse WISSEN !!! (z. B. - Ich habe eine Map, die kopiert werden soll, mit der gleichen versteckten MumbleMap-Implementierung) Ich möchte nur eine Kopie erstellen, wenn dies unterstützt wird. Aber leider hat Cloneable nicht die clone-Methode, also gibt es nichts, auf das Sie clone() sicher tippen können.

Was auch immer die beste "Kopierobjekt" -Bibliothek da draußen ist, Oracle sollte sie zu einer Standardkomponente der nächsten Java-Version machen (es sei denn, sie ist bereits irgendwo versteckt).

Natürlich, wenn mehr der Bibliothek (z. B. - Sammlungen) unveränderlich wäre, würde diese "Kopie" Aufgabe einfach weggehen. Aber dann würden wir anfangen, Java-Programme mit Dingen wie "Klasseninvarianten" anstatt dem verdammten "Bohnen" -Muster zu entwerfen (ein zerbrochenes Objekt machen und mutieren, bis es gut genug ist).