ArrayList kopieren

[limoneneis]

Hallo,

ich habe wohl ein banales Problem aber ich weiß nicht, wie ich das lösen soll. Ich habe eine ArrayList<Klasse> a1 mit Elementen drin. Nun will ich diese in eine andere Liste a2 kopieren.

Mein Ansatz war folgender

for(Klasse k : a1) a2.add(a1);

Wenn ich aber in Liste a2 was verändere, zB

a2.get(5).setNewTeacher("Herr Lehmann");

Ist das in a1 auch der Fall ?!

Ich speichere also nur Referenzen ab. Ich will aber zwei komplett unabhängige Listen haben, wobei a2 initial die a1 werte hat.
gruß

 

[Funart]

Du musst die objecte selbst kopieren und in die neue liste packen.

 

[NWay]

Alle Arrayelement mit ner For-Schleife durchgehen und in ein Neues Array oder ne Arraylist schreiben.
z.B.
Arrays oder arraylists anlegen udn dann:

for(i=0;i<a1.lenght;i++){
a1 = a2;
}

hoffe ich lehne mich da nicht zu weit aus dem fenster.

 

[limoneneis]

Du musst die objecte selbst kopieren und in die neue liste packen.

Super, so hat es geklappt. Habe einfach einen Klonkonstruktor gebastelt:

Klasse(Klasse k)

dann

...
a2.add(new Klasse(k))

 

[Meckie]

Du willst doch nicht immer wieder die Liste hinzufügen oder?

for(Klasse k : a1){
a2.add(k.clone());
}

Je nachdem was k für eine Klasse ist musst du die clone methoden selber implementieren oder nicht.

und Klammern setzen das ist Bad Smell...

Guck dir mal das Buch von Michael Inden an "Der Weg zum Java-Profi". Da stehen viele gute Infos drin.

 

[ice-breaker]

Schau dir mal den Code an, limoneneis hat einen Copy-Constructor gebaut

 

[Rossie]

Alle Arrayelement mit ner For-Schleife durchgehen und in ein Neues Array oder ne Arraylist schreiben.
z.B.
Arrays oder arraylists anlegen udn dann:

for(i=0;i<a1.lenght;i++){
a1 = a2;
}

hoffe ich lehne mich da nicht zu weit aus dem fenster.

Leider doch. So wird das Array auch nur wieder mit den Referenzen befüllt. Er will Deep Copy. Hierfür müssen neue Objekte erzeugt werden.

Ergänzung (27. Juli 2012)

und Klammern setzen das ist Bad Smell...

Satzzeichen sind dafür guter Stil. Dann fällt es dem geneigten Leser auch leichter, den Sinn zu verstehen

 

[1668mib]

@Meckie: So viel scheint das Buch nicht zu taugen... die erste gute Info wäre, clone() zu meiden... (wobei der aktuelle Ansatz in Bezug auf Polymorphie ebenfalls nicht unbedingt der beste Weg ist)

 

[Killkrog]

Rein aus Interesse: Wieso clone() meiden?
Danke schonmal im Voraus

 

[1668mib]

Also clone() hat halt ein paar Nachteile... darunter z.B. dass es nicht wirklich gut in Verbindung mit final-Feldern ist. Mag für viele hier wie kein echtes Problem aussehen, aber es geht halt nun mal kaum etwas über final-Felder ;-)

Siehe hier auch die Aufzählung bzgl. des Buchs Effective Java:
http://stackoverflow.com/questions/715650/how-to-clone-arraylist-and-also-clone-its-contents

Also ich persönlich würde wohl statt clone() lieber eine eigene Kopier-Methode schreiben... alternativ, wenn die konkrete Klasse definitiv bekannt ist evtl auch einen Kopierkonstruktor (z.B. wenn die Klasse selbst final ist). Aber wenn man z.B. auf einem Interface arbeiten würde, ginge das auch nicht...

 

[Meckie]

@1668mib:

Hmm das mit dem final stimmt schon. Zumindest teilweise. Oder aber ich verstehe es noch falsch.
Soweit ich weiß gibt es da doch nur Probleme wenn der Inhalt verschieden sein soll. Ansonsten kopiert super.clone() doch eh den Inhalt.

Den Ansatz mit clone habe ich von der folgenden Seite:
http://www.angelikalanger.com/Articles/EffectiveJava/06.Clone-Part2/06.Clone-Part2.html

da ist auch ein Beispiel, warum es Probleme mit final geben kann. Aus dem Grund mit der Polymorphie soll ja clone verwendet werden. Zumindest sagt das die Autorin. Ätzend ist das natürlich mit dem casten aber sonst fand ich das bisher eigentlich immer ganz praktisch.

Welchen Ansatz würdest du denn vorschlagen?

@soares:
Verzeihung. Du hast natürlich recht. Zu meiner Verteidigung. Auf einem kleinen iPod Touch schreibt sich nicht so gut.

 

[1668mib]

Wie immer gibt es in meinen Augen keine "Pauschallösung".

Wenn man Polymorphismus braucht, würde ich wohl dazu tendieren, eine eigene Clone-Methode zu implementieren, also mit anderem Namen. Und die könnte dann eben entweder eine Kopie mittels Kopierkonstruktor machen oder sonst wie, und diese dann zurückliefern. Diese aber clone() zu nennen finde ich nicht sinnvoll, da sie vom Standard-Java-Clone-Konzept abweicht, das eben explizit keine Konstruktoraufrufe macht zum Klonen.

Aber es kommt wie gesagt immer auf die Situation an. Ich habe auch gesagt, dass bei Clone häufig auf Immutablilty verzichtet werden muss. Scheint ja auch hier beim Fragesteller der Fall zu sein. Ich persönlich würde immer versuchen Klassen immutable zu machen, dann stellt sich das Problem mit dem Klonen eh gar nicht mehr, denn dann ist es doch eigentlich egal, ob mit der selben Instanz oder mit einem gleichweritgen Objekt gearbeitet wird.