Frage zu Interfaces

[taotao]

Hallo,
ich dachte ich hätte dass mit dem Interfaces verstanden, aber in meinem Lehrbuch :### (Handbuch der Java-Programmierung) kam wieder was nicht verständliches.
Wiso muss ich bei einer abgeleiteten Klasse die Schnittstelle Cloneable implementieren, um das Objekt zu clonen?
Reicht es nicht wenn ich einfach die Methode clone in der abgeleiteten Klasse nur überlagere ohne Cloneable zu implementieren?
Die Klasse Object hat doch schon Cloneable implementiert.
Und was ist denn nun ein Flag?

 

[byte]

Nein, Object implementiert nicht Cloneable. Object stellt zwar die Methode clone() bereit, die hat aber nix mit dem Interface Cloneable zu tun. Das Interface enthält nämlich gar keine Methodensignatur, sondern dient einzig dem "markieren" von Klassen. Das bedeutet, nur Klassen die Cloneable implementieren, können die clone() von Object aufrufen. Ansonsten wird eine CloneNotSupportedException geworfen.

Eine Flag ist im Prinzip nix anderes als eine Hilfsvariable, z.B. vom Typ boolean, die sich einen Zustand merkt.

 

[Beni]

"Cloneable" ist der spezielle Spezialfall der zur absoluten Verwirrung führt...

Die "clone"-Methode von Object ist eine native Methode (native: nicht in Java implementiert), welche sehr schnell eine 1:1 Kpie von einem Objekt machen kann.
Das "Cloneable"-Interface sagt der "clone"-Methode lediglich, ob die Methode selbst ausgeführt werden darf. Wenn man "clone" aufruft, aber Cloneable nicht implementiert ist, gibts eine Exception.
Cloneable ist also nicht mehr als ein Zeichen (=Flag) für die "clone"-Methode.

Wie gesagt, "clone" ist da sehr ungewöhnlich, normalerweise setzt man Interfaces schon ein um bestimmte Methoden vorzuschreiben.

 

[AlArenal]

So manch ein "Guru" (Joshua Bloch) empfiehlt die Finger von Cloneable zu lassen, weils einfach Muckefuck ist. Alternativ kann z.B. ein Kopier-Konstruktor verwendet werden.

 

[byte]

Was soll denn an Cloneable so schlimm sein, mal abgesehen davon, dass es recht merkwürdig aussieht, dass die clone() in dem Interface gar nicht definiert ist? Ich finde, das Kopieren von eigenen Objektstrukturen ist mit Hilfe von clone() immernoch am komfortabelsten und schnellsten.

PS: Was ist ein Kopier-Konstruktor?

 

[Wildcard]

PS: Was ist ein Kopier-Konstruktor?

Ein Konstruktor dem man als Parameter ein Objekt der selben Klasse übergibt.
Der Konstruktor kopiert dann die Attribute des übergebenen Objekts bei der Instanzierung.

 

[byte]

Also das gleiche in grün wie mit clone(), bzw. Mehraufwand, weil man auch die primitiven Felder setzen muss, im Gegensatz zu clone().


Edit: Da ich grade selbst eine komplexere Objektstruktur mittels clone() kopiere, ist mir nun doch ein größerer Nachteil der Cloneable Methode aufgefallen: Das Debuggen fällt unter Umständen etwas schwer. Da clone() ja eine Shallow Copy erzeugt, zeigen alle (komplexen) Objektreferenzen des Clones auf die alten Objekte. Es ist demnach etwas mühseelig zu prüfen, ob man nun wirklich alle Felder für die Deep Copy richtig geclonet hat. Sollte sich irgendwo ein Fehler eingeschlichen haben, so fällt dieser nicht so leicht auf. Man sieht zwar im Debugger von Eclipse sehr schön die IDs der internen Objekte, doch so schnell fällt da ja nun nicht auf ob das eine ID vom Clone oder vom Original ist.

Da wäre der Kopie-Konstruktor ja doch einfacher. Die Implementierung ist zwar nahezu identisch wie bei clone() (wobei man zusätzlich auch die primitiven Felder noch setzen muss), aber das Debuggen dürfte doch wesentlich einfacher Fallen, weil es keine "Cross-Referenzen" zwischen Original und Clone gibt.

Und die Performance müsste ja nahezu identisch sein, denke ich mal... Mein Cloning funktioniert jetzt soweit, aber beim nächsten Mal werde ich wohl auch mal die Copy-Konstruktoren einsetzen.

 

[Leroy42]

Ich schätze mal, das dies ein paar der Gründe sind, worauf AlArenal hinwies.