Archiv verlassen und diese Seite im Standarddesign anzeigen : Generics als Objekte ?
hallo erstmal,
ich habe folgendes Problem :
ich arbeite in Java mit Generics und kann aber für genersiche Datentypen Funktionen der Klasse Objects wie zB clone nicht aufrufen.(-> the method clone() from Object is not visible).
Wie ist das möglich ?
Monger
2006-05-16, 18:11:23
Das hat imho überhaupt nichts mit Generics zu tun.
Viele Methoden von Object (wie eben clone) sind final, d.h. werden nicht weitervererbt. Manche Klassen haben nochmal eine eigene, ganz explizite Implementierung von clone. Aber das ist die Ausnahme, nicht die Regel. Wenn du irgendein Objekt einer Klasse hast, ist die Wahrscheinlichkeit groß dass du eben keine clone Methode aufrufen kannst.
dann gibt es also keine Möglichkeit eine deep copy von zB einem Binärbaum zu machen ausser den gnazen Baum zu durchlaufen und nach dessen aufbau einen neuen Binärbaum zu erzeugen ?
Monger
2006-05-16, 20:15:02
Gast[/POST]']dann gibt es also keine Möglichkeit eine deep copy von zB einem Binärbaum zu machen ausser den gnazen Baum zu durchlaufen und nach dessen aufbau einen neuen Binärbaum zu erzeugen ?
Das Problem an einer Kopie ist, dass man fast nie weiß was diese Kopie eigentlich bedeutet. Ist die Kopie eines Verzeichnisses nur eine Kopie der Struktur, oder auch aller Inhalte?
Dieses Problem hat man immer wieder, und es gibt keine Universallösung dafür. Du musst regelmäßig selbst definieren, was du dir unter einer Kopie vorstellst.
Monger
2006-05-16, 20:30:12
Mir fällt da grade ein ganz blödes Beispiel ein...
Stell dir einen Baum vor. Wenn du jetzt genau den selben Baum nebenan setzen möchtest, brauchst du da nur den Baum? Oder auch die Erde in der er wächst? Und Luft, Wasser, Wärme?
Wo fängt ein Ding an, und wo hört es auf? Wir Menschen ziehen da einfach zwischendrin mal eine Grenze, aber es gibt kein Naturgesetz was zweifelsfrei festlegt, was ein "Ding" abgrenzt, und einem dann auch sagen könnte was eine Kopie davon ist.
Dass Java keine automatisierten, tiefen Kopien von beliebigen Objekten zulässt, hat durchaus seinen Grund.
HellHorse
2006-05-16, 23:37:32
Monger[/POST]']
Viele Methoden von Object (wie eben clone) sind final, d.h. werden nicht weitervererbt.
#clone final? Seit wann denn bitte?
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#clone()
Es liegt wohl eher daran, dass #clone protected ist.
dann gibt es also keine Möglichkeit eine deep copy von zB einem Binärbaum zu machen ausser den gnazen Baum zu durchlaufen und nach dessen aufbau einen neuen Binärbaum zu erzeugen ?
In den Nodes rekursiv #clone implementieren.
Du kannst sicher auch Code schreiben, der per Reflection stur ein deep copy macht. Sollte recht einfach sein. Bloss ist das halt einfach keine allgemeine Lösung.
Monger
2006-05-17, 08:21:26
HellHorse[/POST]']#clone final? Seit wann denn bitte?
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#clone()
Es liegt wohl eher daran, dass #clone protected ist.
Hö? Hab ich mich da so verkuckt? :|
Offenbar. Aber warum ist Clone dann nicht für alle Objekte sichtbar? Ich dachte, JEDE Klasse erbt von Object?!?
In den Nodes rekursiv #clone implementieren.
Ich kann ja clone für überhaupt keine von mir selbst erstellte Klasse benutzen...
Offenbar. Aber warum ist Clone dann nicht für alle Objekte sichtbar? Ich dachte, JEDE Klasse erbt von Object?!?
Womit wir wieder bei der Ausgangsfrage wären....
HellHorse
2006-05-17, 09:55:04
Monger[/POST]']Aber warum ist Clone dann nicht für alle Objekte sichtbar?
Weil es protected ist.
Monger[/POST]']
Ich dachte, JEDE Klasse erbt von Object?!?
Nicht wirklich. All die hässlichen, gehackten (Integer.TYPE und Konsorten) z.B. nicht.
protected bedeutet nur von Klassen des gleichen Verzeichnisses zugreifbar.
Meine Klasse ist eine Unterklasse von Objects und deshalb geht er solange in der Klassenhierarchie hoch bis er eine Funktion clone findet -> bei Objects und von Objects ist clone aufrufbar ?
sry, falls Verständnisfehler.....
HellHorse
2006-05-17, 10:11:55
Gast[/POST]']Ich kann ja clone für überhaupt keine von mir selbst erstellte Klasse benutzen...
Deshalb schrieb ich ja auch implementieren.
protected bedeutet nur von Klassen des gleichen Verzeichnisses zugreifbar.
Nö, das ist package protected (default modifier). Und der bezieht sich nicht auf das Verzeichnis sonder das package. Das kann das Gleiche sein, muss aber nicht.
Wenn der Datentyp bekannt ist kann man deep copy ja sehr leicht implementieren, zB
String s = new String(c);
welche Möglichkeiten hat man aber bei der Verwendung von Generics ?
Ich kann ja nicht schreiben C s = new c(..);
Monger
2006-05-17, 13:43:53
Stimmt, ab da wirds langsam hässlich. Du kannst deine Generics aber einschränken, so à la
class <E extends Klonbar> Blablabla{
// ...
}
Ich weiß gar nicht, wie das mit Interfaces ist, aber im Prinzip müsste man darauf ja genauso einschränken können.
Im Interfeace Cloneable steht aber nur der Name der Funktion clone, implementieren muss man sie selbst.
Das Problem ist wie man deep copy mit Generics machen soll, wenn man Generics nicht instanziieren kann....
SGT.Hawk
2006-05-17, 22:51:44
Ist doch einfach: protected darst du nur in der SubKlasse benutzen, ist natürlich ein Problem, wenn du es aus anderen Klassen aufrufen willst, deshalb würde ich es mit public overriden.
mithrandir
2006-05-18, 07:54:26
@Hawk ???
@Gast
Ich denke, Monger meint, du solltest eine abstrakte Elternklasse fuer deine Generics erstellen, die das Clonable-Interface implementiert. Oder?
bye, Peter
Monger
2006-05-18, 11:53:33
mithrandir[/POST]']@Hawk ???
@Gast
Ich denke, Monger meint, du solltest eine abstrakte Elternklasse fuer deine Generics erstellen, die das Clonable-Interface implementiert. Oder?
bye, Peter
Ich dachte jetzt eher daran, ein eigenes Interface zu machen, das mit dem normalen Cloneable gar nichts zu tun hat. Cloneable ist nicht generisch. Ich glaube es wäre schwierig, damit generische Typen zu klonen.
Und ich hab sowieso eine Abneigung gegen clone(), deshalb würde ich vorschlagen, (wenn es denn notwendig ist) ein eigenes Interface zu deklarieren, und clone() komplett zu vergessen.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.