G
Bashar schrieb:
Warum?
Um clone und Cloneable richtig anzuwenden muss man einen relativ komplizierten, dürftigen Vertrag einhalten, der schlecht dokumentiert ist. Der Mechanismus, mit dem dann das Objekt erzeugt wird, ist zudem relativ kompliziert. Hier kommen mal einige diesbezügliche Stellen aus "Effektiv Java Programmieren":
Wenn sie ein Interface implementieren, sagen Sie dadurch normalerweise etwas darüber aus, was eine Klasse für ihre Clients tun kann. Bei Cloneable hingegen ändern Sie dadurch das Verhalten einer geschützten Methode in einer Oberklasse.
Damit die Implementierung des Interface Cloneable sich auf eine Klasse auswirkt, müssen die Klasse und alle ihre Oberklassen ein relativ komplexes, nicht erzwingbares und größtenteils nicht dokumentiertes Protokoll einhalten. Dadurch ergibt sich ein außersprachlicher Mechanismus: Dieser erzeugt ein Objekt, ohne einen Konstruktor aufzurufen.
Der allgemeine Vertrag der Methode clone ist dürftig.
In der Praxis erwartet man von einer Klasse, die Cloneable implementiert, dass sie eine ordentlich funktionierende öffentliche clone-Methode bereitstellt. Normalerweise ist dies nur dann möglich, wenn alle Oberklassen der Klasse eine öffentliche oder geschützte clone-Implementierung mit gutem Verhalten bereitstellen.
Die clone-Architektur ist mit der normalen Benutzung von final-Feldern, die sich auf veränderliche Objekte beziehen, nicht vereinbar.
Wenn Sie eine Klasse erweitern, die Cloneable implementiert, haben Sie gar keine andere Wahl als eine clone-Methode mit gutem Verhalten zu implementieren.
Bashar schrieb:
Und wie soll das mit Polymorphie zusammen funktionieren?
Interessantes Problem. Vermutlich muss man das dann mit Hilfe von Reflection lösen.