Arraylist mit anderer ArrayList überschreiben

Diskutiere Arraylist mit anderer ArrayList überschreiben im Allgemeine Java-Themen Bereich.
H

Hieu

Hallo Leute ich hätte mal eine grundlegende Frage. Nehmen wir an ich hätte eine Arraylist wo Kunden gespeichert werden und dann noch eine andere ArrayList wo auch Kunden gespeichert werden. Wie kann ich Daten einer ArrayList mit den Daten der anderen ArrayList überschreiben?
 
H

httpdigest

Java:
List<Kunde> kundenListe = ...;
List<Kunde> andereKundenListe = ...;
kundenListe.clear(); // <- `kundenListe` leeren
kundenListe.addAll(andereKundenListe); // <- `kundenListe` mit den Kunden aus `andereKundenListe` füllen
 
J

JustNobody

Wenn die Instanz die gleiche bleiben muss:
Erst clear und dann ein addAll mit der zweiten Instanz mit toArray als Parameter.

Wenn die Instanz des Ziels eine andere sein darf:
Einfach ein clone() aufrufen und zuweisen

Falls du keine zwei getrennten ArrayListen brauchst:
Einfach die Referenz zuweisen

Edit: httpdiggest hat natürlich Recht, addAll will eine Collection und kein Array als Parameter ... daher geht der Aufruf ohne toArray()
 
J

JustNobody

Das trifft es ziemlich gut: kommt die ClassCastException oder geht es ohne? :)
Also das Probleme sehe ich hier nicht. Wo siehst Du dieses Problem bei zwei ArrayList<Kunde>, die gegeben sind?

Argumente wieso dein Vorschlag besser ist, sehe ich aber natürlich auch. Einer wird z.B. direkt sichtbar, wenn man mit Interfaces arbeitet. Die List<> hat halt kein clone().
 
mihe7

mihe7

Also das Probleme sehe ich hier nicht. Wo siehst Du dieses Problem bei zwei ArrayList<Kunde>, die gegeben sind?
Ne, das war nicht speziell auf dieses Beispiel bezogen. Ich dachte eher an etwas, wo man eine List bekommt, diese klont und dann - in Unkenntnis des Laufzeittyps - einfach mal auf ArrayList castet :)

Edit:
Die List<> hat halt kein clone().
Oha. Da sieht man mal, wie wenig ich mit clone bislang gearbeitet habe... das ist in Object ja protected :eek:
 
J

JustNobody

Ahh, ok. Danke für die Aufklärung. Ich hatte kurz den Verdacht, dass es die "alte" Problematik ist, dass dies teilweise falsch/oft gemacht wurde.
Einige machen das halt falsch und dann bekommt man auch ClassCastException Probleme. Wenn ich also in A.clone() nicht super.clone() aufrufe sondern einfache in new A() erzeuge ... dann wird B von A abgeleitet, B.clone ruft super.clone() auf aber bekommt dann natürlich ein A und kein B und der Cast auf B schlägt fehl.

So ein clone greift halt immer auf ein super.clone() zurück und das landet dann am Ende bei Object.clone(), welches dann eine neue Instanz der Klasse selbst erzeugt (also bei B.clone() wird das ein B. A bekommt dann auch schon ein B, aber das kann man in A casten....

Also in ArrayList hat man dann einen cast auf ArrayList von eben super.clone() wenn man sich das einmal anschaut.

So man klare Typen hat, dann funktioniert das schon recht gut. Aber ich gebe zu, dass ich es nicht gut durchdacht habe und es kam mir halt in den Sinn - habe ich halt in der Vergangenheit auch schon Dinge mit machen dürfen. Aber der Hauptgrund ist für mich, dass man ja mit Interfaces arbeitet (also in der Regel List statt ArrayList) und wenn man dann neue Instanzen erzeugt, dann greift man halt auf konkrete Klassen zurück. Und da ist Dein Weg genau der, der halt genommen wird.

Bei einer List wäre ansonsten der Weg List -> Cloneable -> clone() -> List
Und hätte dann die Einschränkung, dass es nur für List Implementationen funktionieren würde, die auch Cloneable implementieren.
Also zum einen Aufwändig und zum anderen stark eingeschränkt ...
 
L

LimDul

Meine letzte Begegnung mit Clone ist noch aus einem Projekt wo zum einen generierter Code drin und wir zum anderen GregorianCalender zum speichern von Datumsangeben genutzt haben. Und da wurde jeder getter auf GregorianCalender-Attribut als return (GregorianCalender)datum.clone(); generiert. Seitdem gott sei Dank so gut wie nie mehr gebraucht :) (Sowohl Clone als auch das unsägliche GregorianCalender)
 
T

temi

Einige machen das halt falsch und dann bekommt man auch ClassCastException Probleme. Wenn ich also in A.clone() nicht super.clone() aufrufe sondern einfache in new A() erzeuge ... dann wird B von A abgeleitet, B.clone ruft super.clone() auf aber bekommt dann natürlich ein A und kein B und der Cast auf B schlägt fehl.

So ein clone greift halt immer auf ein super.clone() zurück und das landet dann am Ende bei Object.clone(), welches dann eine neue Instanz der Klasse selbst erzeugt (also bei B.clone() wird das ein B. A bekommt dann auch schon ein B, aber das kann man in A casten....
Das liest sich ähnlich wie die Metaphern unseres Bayerischen Wirtschaftsministers

Sorry für den Offtopic...
 
J

JustNobody

Meine letzte Begegnung mit Clone ist noch aus einem Projekt wo zum einen generierter Code drin und wir zum anderen GregorianCalender zum speichern von Datumsangeben genutzt haben. Und da wurde jeder getter auf GregorianCalender-Attribut als return (GregorianCalender)datum.clone(); generiert. Seitdem gott sei Dank so gut wie nie mehr gebraucht :) (Sowohl Clone als auch das unsägliche GregorianCalender)
Wobei das eigentlich der Usecase ist, in dem es Sinn macht (das Clone). Du willst halt eine Referenz zurück geben, die einen 'Wert' darstellt und die Klasse ist nicht immutable... Eine Veränderung soll sich halt nicht auswirken bei Dir.

Diese Clone Verwendung Ist sehr stark bei mir verdrängt worden dadurch dass vieles immutable geworden ist. Wenn du also von einer MyCoolClass per Getter eine Instanz von MyCoolData bekommst, dann ist das etwas ohne Setter und so, so dass die gespeicherte Referenz direkt zurück gegeben werden kann.

Das hat sich auch bei der Arbeit mit (parallelen) Streams bewährt / positiv bemerkbar gemacht.
 
mihe7

mihe7

Ich denke auch, dass man sehen muss, dass clone() "historisch gewachsen" ist. Mal abgesehen davon, dass es seinerzeit Generics in Java noch nicht gab (im Gegensatz zu Templates in C++), war in den 90ern ja Vererbung noch das Maß aller OO-Dinge. Im Zusammenhang mit Polymorphie ist clone() tatsächlich interessant. "Leider" brauche ich das heute nie :) Ich kann mich zwar dunkel daran erinnern, dass ich clone() auch schon verwendet habe, aber nicht mehr, wann. Das ist zu lange her, ich schätze mal Anfang der Nuller-Jahre.
 
T

temi

Ein kurzes Résumé aus "Effective Java" von Joshua Bloch zu den vorherigen Erläuterungen aller Schwierigkeiten mit clone():
Angesichts all der mit Cloneable verbundenen Probleme sollte Cloneable nicht um neue Schnittstellen erweitert und nicht von neuen erweiterbaren Klassen implementiert werden. Auch wenn es für finale Klassen weniger gefährlich ist, [..], sollte diese Maßnahme als Performanceoptimierung betrachtet werden und nur den seltensten Fällen vorbehalten bleiben, [..]. Als Regel können Sie sich merken, dass Kopierfunktionalität am besten von Konstruktoren oder Factory-Methoden bereitgestellt wird. Eine nennenswerte Ausnahme zu dieser Regel bilden Arrays, die am besten mit der clone-Methode kopiert werden.
 
Zuletzt bearbeitet:
Thema: 

Arraylist mit anderer ArrayList überschreiben

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben