Referenzen

[Foermchen82]

Hallo zusammen.

Ich plage mich grade mal durch das leidige Thema der Referenzen.

Hierzu meine Frage:

Ich habe eine Datenstrukur z.b. Map<String, Integer>

wenn ich damit jetzt ein Objet erzeugte (z.b. object1) und der Map was hinzufüge ist alles OK.

Erzeuge ich jetzt davon ein Zweites Object (z.b. object 2) und weise object 2 das object1 zu (object2 = object1) dann sind object1 und object2 identisch.
Nehme ich jetzt an object1 veränderungen vor, haben die automatisch auswirkungen auf objetc2.

Will ich das vermeiden muss ich object2 mit "= new Map<String,Integer>(object1)" erzeugen (Das ist das Kopierkonstruktorprinzip).

ICh hoffe mal bis hierhin ist alles richtig.

Wie schaffe ich eine sinnvolle kopierzuweisung bei Komplexeren datentypen?

z.b. List<SelbstDefinierteContainerClasse>

Da müsste ich ja sowohl die Liste kopieren (geht über den standartkopierkonstrukor) und auch noch die inneren objecte. Heißt dass, ich müßßte im extremfall eine koplett neue Liste bauen, per iteration die inneren objekte einfügen, und dabei jeweils die Kopierkonstruktoren aufrufen??

Danke im vorraus

 

[SlaterB]

> müßßte im extremfall eine koplett neue Liste bauen

so in der Art, aber wozu? habe ich in 10 Jahren noch nie gebraucht,
also gar nicht so schlimm

 

[Foermchen82]

mir gehts auch mehr um das prinzip.

kann mir aber jemand sagen, bei welchen datentypen in java ich keinen CopyConstructor verwenden muss, um eine Kopie zu erstellen?

also Primitive typen wie int, double, char ist klar.

Map, List usw geht nicht.

Integer, String gehen aber glaube ich. Wenn ja, wieso eigentlich?

Danke im voraus

 

[SlaterB]

alle Objekte gehen erstmal nicht,
Integer und String sind insofern besonders, als dass sie unveränderlich sind,
ein String "abc" bleibt immer "abc", da kann man keine Buchstaben verändern oder ähnliches,
jede Manipulation erzeugt einen neuen String, das ist dem alten schnuppe

 

[Foermchen82]

und welche sind noch unveränderlich? kann ich die erkennen? es gibt ja noch Double, Long uws

 

[SlaterB]

dass alle anderen Wrapperklassen zu primitiven Datentypen ähnlich sind, kann man ja annehmen,
allgemein wüßte ich grad kein zwingendes Erkennungsmittel,
einfach genau anschauen womit man so hantiert, dann ergibt sich das von selbst

Color fällt mir grad ein:
http://java.sun.com/javase/6/docs/api/java/awt/Color.html

wenn es von einem Objekt statische Konstanten wie
Color.RED
gibt, dann ist das immer ein guter Hinweis, aber nicht zu 100% sicher

Locale hat viele statische Konstanten,

BigInteger, BigDecimal sowie alles was von Number erbt

Pattern

 

[Foermchen82]

mir ist noch grad was aufgefallen:

wurde es helfen, wenn ich bei meiner List<SelbstDefinierterContaier> einfach ein clone auf das Object mache? oder sind dann die inneren objecte dann nicht wirklich kopiert?

 

[SlaterB]

ich persönlich benutzte clone nicht so sehr, um darauf zu antworten,
aber nochmal ein Hinweis auf eine einfache Art des Clones,
die es doch schon gibt:

http://www.informatik-student.de/2006/12/10/deep-copy-von-java-objekten/

alle Objekte müssen serialisierbar sein, was bei Java-Collections usw. normalerweise der Fall ist,
eigene Objekte müssen java.io.Serializable implementieren,
solange nur andere einfache Objekte wie Strings und Collections enthalten sind, kein Problem