clone() und Referenzen

[ich2]

Hallo,
soweit ich es von clone() verstanden habe, müssen alle Felder, die Referenzen sind, dort auch kopiert werden, ansonsten zeigen die Felder vom neuen Objekt weiterhin auf die Werte, vom geklonten.
Ziehe daraus den Schluss, dass wenn man dies nicht macht, und dann im neuen Objekt den Wert einer diesen Felder ändert, sich dann auch den Wert im geklonten Objekt ändern sollte.
Ist aber nicht passiert, warum?
Hier der Kode:

public class Clone implements Cloneable{
	Integer i;
	
	Clone(Integer i){
		this.i=i;
	}
	
	@Override
	public Object clone(){
		try {
			return super.clone();
		} catch (CloneNotSupportedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
			return null;
		}
	}
	public static void main(String args[]){
		Clone c = new Clone(new Integer(2));
		Clone d = (Clone)c.clone();
		System.out.println(d.i); //ausgabe 2, klar
		d.i = new Integer(-1);
		System.out.println(c.i); //noch 2??
		
	}
}

 

[maki]

Vergiss clone(), nimm lieber Copy Konstruktoren oder factories.

 

[Janus]

java verwendet pointer, keine referenzen. soll heissen: wenn du irgendeinem bezeichner ein neues objekt zuweist, dann zeigt ausschließlich dieser bezeichner auf das neue objekt. in deinem fall zeigt i des ursprünglichen objekts weiterhin auf die Integer(2) instanz.

 

[ich2]

java verwendet pointer, keine referenzen. soll heissen: wenn du irgendeinem bezeichner ein neues objekt zuweist, dann zeigt ausschließlich dieser bezeichner auf das neue objekt. in deinem fall zeigt i des ursprünglichen objekts weiterhin auf die Integer(2) instanz.

ähm...

http://www.all2know.com/de/wikipedia/r/re/referenz__programmierung_.html
Eine Referenz repräsentiert einen Verweis auf ein Objekt. Wie der Zeiger stellt eine Referenz damit einen Aliasnamen für eine Entität dar, d. h. eine Variable, die die Speicheradresse einer anderen Variablen enthält. Im Gegensatz zu expliziten Zeigern ist die Adresse selbst nicht mehr änderbar und verborgen, insbesondere sind Operationen auf der Adresse (Zeigerarithmetik), die oft fehlerträchtig sind, nicht möglich. Referenzen werden häufig zur Parameterübergabe genutzt, wenn durch eine Unterfunktion die Werte eines Objektes dauerhaft geändert werden sollen, siehe auch Call by reference.
In der Programmiersprache Java unterscheidet man zwischen starken und schwachen Referenzen.

Außerdem, wenn es auch Zeiger wären, sollte sich doch auch den Wert ändern, für alle die auf diese Adresse zeigen, oder?

 

[Janus]

das wort referenz hat sich in der java welt leider durchgesetzt, auch wenn es sie in java schlicht nicht gibt.

der von dir zitierte text ist auch fehlerhaft. eine referenz ist ein alias, ein zeiger nicht. ein zeiger ist schlicht eine speicheradresse. wenn ich den zeiger auf einen anderen speicherbereich weisen lasse, dann ändert das verweise auf den alten speicherbereich in keiner weise.

eine referenz ist ein alias für die adresse. ändere ich die referenz, dann wirkt sich diese änderung auf alle bezeichner aus, die auf die ursprüngliche stelle im speicher verwiesen haben. und genau sowas kennt java (aus gutem grund ) nicht.

 

[Janus]

ungefähr das, was du in deinem code getan hast mal als c++ code, vielleicht wirds dann deutlicher

int main()
{
	int *c = new int;
	int *d = c;
	
	*c = 2;
	c = new int;
	*c = -1;
	
	// c == -1, d == 2
}

 

[ich2]

Stimmt, auch mit einem einfacheren Beispiel

String s = new String("a");
		String t = s;
		t = new String("b"); 
		System.out.println(s) //a;

wird es klar. Wieso muss man dann aber die "Referenzen" in clone() kopieren? Die Variablen werden eh automatisch kopiert, und wenn man sie mit dem Klon nicht mehr ändern kann...

 

[ich2]

Zu Probleme kann es kommen, wenn man z.B.

Clone d = c;
		d.i = new Integer(3);
		System.out.println(c.i) //3;

macht, dann verändert sich doch c.i, wenn man d.i verändert. Mit Zeigern würde ich das so erklären,dass c und d auf dasselbe Object, bzw. das selbe Feld i zeigen, bei der anlage vom neuen Object 3, wird dann seine Adresse in i geschrieben, so dass c.i und d.i auf dieselbe Stelle zeigen.

Da hilft dann zu klonen, da man c kopiert, und so c.i und d.i im speicher getrennt sind.
Wozu man dann die Felder beim Klonen dann auch selbst kopieren soll, ist mir aber immer noch nicht klar.

 

[Pappenheimer++]

Du bist hier auf das klassische Problem "Gleichheit vs. Tiefengleichheit" gestoßen. Da kannst du ja mal nach googlen - da findest du sicher ne Menge.

 

[JavaFred]

Ziehe daraus den Schluss, dass wenn man [...] im neuen Objekt den Wert einer diesen Felder ändert, sich dann auch den Wert im geklonten Objekt ändern sollte.

Falsch. Jedes Objekt hat seine eigenen Variablen, auch geklonte Objekte. Wenn Du einer Variablen einen neuen Wert zuweist, dann betrifft das wirklich nur die eine Variable des Objekts und keine anderen Variablen.

Eine andere Frage ist, was passiert, wenn die Variable eine Referenzvariable ist. Dann speichern die beiden unterschiedlichen Variablen (Original und Kopie) Referenzen auf DASSELBE OBJEKT. Das heisst, dass eine Änderung am referenzierten Objekt über eine Variable Auswirkungen hat auf das referenzierte Objekt der anderen Variablen - schließlich ist es ja dasselbe Objekt.

Beispiel: ich habe eine Kontonummer, und Du hast auch eine Kontonummer. Wenn diese Kontonummern gleich sind, dann haben wir beide dasselbe Konto. Das heißt, wenn ich etwas einzahle, siehst Du das auf Deinem Kontoauszug. Wenn ich aber morgen beschließe, mir ein neues Konto zuzulegen, dann ändert sich zwar meine Kontonummer, Deine aber nicht.
Die Kontonummern sind hier die Referenzen, und die Konten die Objekte.

 

[ich2]

Ziehe daraus den Schluss, dass wenn man [...] im neuen Objekt den Wert einer diesen Felder ändert, sich dann auch den Wert im geklonten Objekt ändern sollte.

Falsch. Jedes Objekt hat seine eigenen Variablen, auch geklonte Objekte. Wenn Du einer Variablen einen neuen Wert zuweist, dann betrifft das wirklich nur die eine Variable des Objekts und keine anderen Variablen.

Eine andere Frage ist, was passiert, wenn die Variable eine Referenzvariable ist. Dann speichern die beiden unterschiedlichen Variablen (Original und Kopie) Referenzen auf DASSELBE OBJEKT. Das heisst, dass eine Änderung am referenzierten Objekt über eine Variable Auswirkungen hat auf das referenzierte Objekt der anderen Variablen - schließlich ist es ja dasselbe Objekt.

Beispiel: ich habe eine Kontonummer, und Du hast auch eine Kontonummer. Wenn diese Kontonummern gleich sind, dann haben wir beide dasselbe Konto. Das heißt, wenn ich etwas einzahle, siehst Du das auf Deinem Kontoauszug. Wenn ich aber morgen beschließe, mir ein neues Konto zuzulegen, dann ändert sich zwar meine Kontonummer, Deine aber nicht.
Die Kontonummern sind hier die Referenzen, und die Konten die Objekte.

Ich schätze mal, du hast nur den ersten Beitrag gelesen. Und auch nicht ganz richtig, glaube ich, da ich mich schon auf Referenzvariablen bezogen hatte.

 

[ich2]

Übrigens glaube ich schon dass man in Java den Begriff "Referenz" im Sinne vom Alias anwenden kann, ist nämlich dann ein Alias, von der Adresse von der Adresse (keine Wortwiederholung!), wo das Object liegt.
Wobei man nur ein Alias (nicht mehr) für jede Adresse haben kann.

 

[maki]

Übrigens glaube ich schon dass man in Java den Begriff "Referenz" im Sinne vom Alias anwenden kann, ist nämlich dann ein Alias, von der Adresse von der Adresse (keine Wortwiederholung!), wo das Object liegt.
Wobei man nur ein Alias (nicht mehr) für jede Adresse haben darf.

Ich glaube du bist verwirrt..

"Referenz" ist ganz klar definiert in Java, in C++ ist es etwas anderes.

Was ist jetzt die Frage?
Etwas zu clone()?

 

[Janus]

klar ist das wort referenz in java definiert. es macht sich halt schlecht, von zeigern zu sprechen und im gleichen atemzug zu erwähnen, dass es doch keine vollwertigen zeiger sind, weil in java keine zeigerarithmetik möglich ist.

aber im grunde wäre das die antwort auf das problem: java kennt nur zeiger, nichts anderes, aber man kommt nicht an die adresse. für jemanden mit c++ kenntnissen erklärt das so ziemlich alles

 

[Wildcard]

aber im grunde wäre das die antwort auf das problem: java kennt nur zeiger, nichts anderes

Das sorgt nur für Verwirrung, da man in Java nunmal von Referenzen spricht und keine Zeiger zur Verfügung hat.

 

[maki]

klar ist das wort referenz in java definiert. es macht sich halt schlecht, von zeigern zu sprechen und im gleichen atemzug zu erwähnen, dass es doch keine vollwertigen zeiger sind, weil in java keine zeigerarithmetik möglich ist.

aber im grunde wäre das die antwort auf das problem: java kennt nur zeiger, nichts anderes, aber man kommt nicht an die adresse. für jemanden mit c++ kenntnissen erklärt das so ziemlich alles

Für Leute mit C++ Kenntnissen ist das verwirrend, schliesslich neigen diese dazu, die C++ Referenzen mit den denen aus Java zu vergeichen, was schiefgeht.
Sicherlich sind Zeiger in C++ "ähnlicher" zu Referenzen in Java, aber wem nutzt das?

Lassen wir C++ doch einfach C++ sein und beschränken uns auf Java
Jede Sprache hat auch ihre Kultur, kann schon sein das sich Begriffe aus unterschiedlichen Sprachen ähneln oder gar gleich sind, aber wenn andere Konzepte dahinterstecken, kann es sehr verwirrend sein zu versuchen Rückschlüsse aus der Bedeutung eines Begriffes in einer Sprache auf eine andere Sprache zu übertragen.

 

[ich2]

Übrigens glaube ich schon dass man in Java den Begriff "Referenz" im Sinne vom Alias anwenden kann, ist nämlich dann ein Alias, von der Adresse von der Adresse (keine Wortwiederholung!), wo das Object liegt.
Wobei man nur ein Alias (nicht mehr) für jede Adresse haben kann.

Also dies wird wohl richtig sein, man hat nur im Unterschied zu normalen Zeiger keinen Zugriff auf die Speicherstelle, wo die Adresse vom Objekt steht.

Ich glaube auch, das mit clone() rausgefunden zu haben. Wenn die Referenzvariable vom geklonten Objekt wiederum Referenzvariablen enthält, kann man ihren Inhalt überschreiben.

 

[maki]

Ich glaube auch, das mit clone() rausgefunden zu haben. Wenn die Referenzvariable vom geklonten Objekt wiederum Referenzvariablen enthält, kann man ihren Inhalt überschreiben.

Da täuscht du dich.

In Java werden alle Objekte immer per Referenz angesprochen, d.h. sobald es keine sog. primitives sind, wirst du immer Referenzen auf Objekte haben.

Dazu kommt, dass String, INteger und viele andere Java Datentypen als sog. immutables implmentiert sind, d.h. man kann ihren Wert nicht ändern, stattdessen bekommt man bei Änderungen ein neues Objekt zurück.
Triel & Error führen hier zu falschen Schlussfolgerungen.

clone() und clonable sind übrigens missgeburten, sollte man nicht verwenden/implmentieren.

 

[ich2]

Jede Sprache hat auch ihre Kultur, kann schon sein das sich Begriffe aus unterschiedlichen Sprachen ähneln oder gar gleich sind, aber wenn andere Konzepte dahinterstecken, kann es sehr verwirrend sein zu versuchen Rückschlüsse aus der Bedeutung eines Begriffes in einer Sprache auf eine andere Sprache zu übertragen.

In diesem Fall ist es aber schon wichtig zu wissen, dass man im Grunde genommen mit Zeiger arbeitet, sonst kann man zum Beispiel clone() nicht richtig verstehen. :wink:

 

[ich2]

Ich glaube auch, das mit clone() rausgefunden zu haben. Wenn die Referenzvariable vom geklonten Objekt wiederum Referenzvariablen enthält, kann man ihren Inhalt überschreiben.

Da täuscht du dich.

In Java werden alle Objekte immer per Referenz angesprochen, d.h. sobald es keine sog. primitives sind, wirst du immer Referenzen auf Objekte haben.

Dazu kommt, dass String, INteger und viele andere Java Datentypen als sog. immutables implmentiert sind, d.h. man kann ihren Wert nicht ändern, stattdessen bekommt man bei Änderungen ein neues Objekt zurück.
Triel & Error führen hier zu falschen Schlussfolgerungen.

clone() und clonable sind übrigens missgeburten, sollte man nicht verwenden/implmentieren.

Ob es Sinn macht, sie zu verwenden, weiß ich nicht, zur Zeit muss ich sie aus didaktischem Zweck verstehen.

Ich täusche mich da nicht. Es geht darum, wann es sinnvoll ist, die Referenzen vom Object in clone() zu kopieren. Die primitive Typen kann man nicht überschreiben, da der Wert mitkopiert wird, und Immutables kann man eh nicht ändern, also muss man für sie keinen neuen Speicherplatz anlegen.

Der Punkt hier war das wenn das geklonte Objekt "einfache" Referenzenvariablen hat (z.B. Integer, was ich auch im ersten Beitrag benutzt habe), und man dann im Klon den Wert von dieser Variable ändert, das keine Auswirkungen auf das ursprüngliche Integer-Objekt hat (warum, siehe vorige Beiträge).
Wenn man allerdings ein Objekt mit Referenzvariablen klont, die wiederum andere Referenzvariablen enthalten, besteht die Gefahr, dass der Klon letztere doch ändert. Und deswegen muss man die Referenzvariablen beim Klonen selber kopieren, dafür dass dies nicht passieren kann.

 

[maki]

Ja, die Immutables sind sicher, braucht man nicht mitzukopieren, ganz im Gegenteil.
Alls was nicht immutable ist, muss extra kopiert werden für eine sog. "deeep copy".

Was macht clone, wenn man versucht eine "final" Property zu kopieren?

Die Standardimplementierung in Object von clone() wirft eine CloneNotSupportedException.

Musst also schon genau sagen, von welcher Klasse du die clone Methode versuchst zu verstehen.

 

[ich2]

Ja, die Immutables sind sicher, braucht man nicht mitzukopieren, ganz im Gegenteil.
Alls was nicht immutable ist, muss extra kopiert werden für eine sog. "deeep copy".

Was macht clone, wenn man versucht eine "final" Property zu kopieren?

Die Standardimplementierung in Object von clone() wirft eine CloneNotSupportedException.

Musst also schon genau sagen, von welcher Klasse du die clone Methode versuchst zu verstehen.

Hm, also mir ging es hier nur darum... na ja, wonach ich gefragt habe.
Gelöst hat es sich auch schon, wenn du etwas genauer auf meinen letzen Beitrag schaust.
Danke an alle für die Antworten!

 

[JavaFred]

clone() und clonable sind übrigens missgeburten, sollte man nicht verwenden/implmentieren.

Ich kann nicht ganz nachvollziehen, warum das Cloneable-Interface nicht so aussieht:

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

Wäre das nicht deutlich eleganter?

 

[ich2]

Ich habe auch noch eine Frage dazu, obwohl es keinen Sinn machen würde, wieso kann man clone() nicht mit jedem Object aufrufen, ohne es überschrieben zu haben? Sollte eigentlich, wenn es eine protected Methode ist und alle Unterklassen von Object sind... oder wurde das für diesen Fall speziell eingeschränkt?

 

[maki]

Wäre das nicht deutlich eleganter?

Tja, leider hat man es beim ersten mal nicht so gemacht, und Interfaces im nachhinein ändern ist immer so eine Sache, wenn sie mal veröffentlicht wurden...
Dazu kommt, dass es zuerst die clone Methode gab, später dann das clonable interface, leider sind beides "Missgeburten".

Das ist aber nicht das einzige Problem von clone und cloneable.

clone müsste, um richtig zu funktionieren, denselben Zugriff haben wie ein Konstruktor.

Hast du nur eine einzige final property in dem Objekt, versagt clone, kann sie ja nicht ändern.

Ausserdem müsste immer erst die clone() Methode der superklasse aufgerufen werden, muss ja schliesslich alles geklont werden, geht aber nicht.

Es gibt noch mehr gute Gründe warum weder clone noch cloneable verwendet werden sollten bzw. es sehr schlechter Stil ist, es doch zu tun.

Ist halt eine Altlast in Java, leider fallen Anfänger drauf rein, weil es allzu logisch erscheint sie zu verwenden.

Wenn man Objekte kopieren möchte, nimmt man Copy Konstruktoren, oder factory Methoden.

Natchtrag: Lesenwrt imho: http://www.artima.com/intv/bloch13.html

 

[ich2]

Letzte Frage hat sich auch schon erledigt.
Edit, ne hat sich nicht. Ich verstehe das immer noch nicht.
Auf protected Methoden einer Klasse darf man zugreifen, solange man im selben Package ist, oder in einem anderen Package, wenn man eine Unterklasse ist.
Nach dieser definition sollte prinzipiell jedes Object clone() sehen können, oder? (Es geht nicht darum, ob es funktioniert, nur um die Sichtbarkeit).
Wenn ich selbst eine Klasse erstelle, kann man clone() sehen. Mit Objekte aber aus der Library, klappt das aber nicht, noch nicht mal wenn ich versuche, es mit Objekte von Klassen aus java.lang aufzurufen.
Was übersehe ich da?