abstract + clone() = BUMM!

[Tobias]

*grummel*

Hi,

nur aus reiner Frustration: Ich habe einen ziemlich fetten Objektbaum, den ich ab und zu (zumindest teilweise) klonen muss. Ok, kein Problem, überschreibt man clone(), implementiert Cloneable, fügt ein bißchen eigene Logik hinzu - alles wird gut. Pustekuchen! Zur Laufzeit fliegt einem das ganze um die Ohren mit einem höchst aussagekräftigen "ClassFormatError: Code attributes in abstract method or interface in class file ..."-Error! Bißchen gegoogelt, das hier gefunden. Ok, Problem liegt in der clone()-Methode. Wenn die von einem Interface als

public MeineKlasse clone() throws CloneNotSupportedException

deklariert oder gar von einer abstrakten Klasse implementiert wird, passiert obige Katastrophe.

Ich bin begeistert.

Meine Fragen:
- Warum passiert das? Einfach ein Bug oder hat das einen Sinn, der sich mir noch nicht erschlossen hat?
- Und viel wichtiger: Was mache ich denn jetzt? Kopierkonstruktoren kommen nicht in Frage, ein Umbenennen der Methode wäre möglich, aber irgendwie blöd (ich will ja schönen Code abliefern ) ...

mpG
Tobias

*/grummel*

 

[maki]

kurz: Vergiss Clone und cloneable, beides Missgeburten.
Benutze lieber Copy-Konstruktoren oder statische factory Methoden, in deinem Falle wohl letzteres.

clone und cloneable sind kein schöner Code.

 

[quippy]

Meine Fragen:
- Warum passiert das? Einfach ein Bug oder hat das einen Sinn, der sich mir noch nicht erschlossen hat?
- Und viel wichtiger: Was mache ich denn jetzt? Kopierkonstruktoren kommen nicht in Frage, ein Umbenennen der Methode wäre möglich, aber irgendwie blöd (ich will ja schönen Code abliefern ) ...

Frage a) von abstrakten Klassen kann man keine Instanz erzeugen. Wenn der Clone also in der abstrakten Klasse steckt, kann das nicht klappen! Daher gibt es auch keine Clone-Methode in Object die für alle ableitenden Objekte funktionieren würde.

Frage b) Copy-Constructors oder eine Methode "getCopyInstance" sind da besser. Das funktioniert auch dann mit der abstrakten Klasse in der Form

public abstract class A
{
   private int x;

   public abstract Object getCopyInstance();
   public void fillCopyInstance(A whatToFill)
   {
      // super.fillCopyInstance(whatToFill); // Gibt es hier nicht
      whatToFill.x = x;
   }
}

public class B extends A
{
   private int y;

   public Object getCopyInstance()
   {
      B result = new B();
      fillCopyInstance(result);
      return result;
   }
   public void fillCopyInstance(B whatToFill)
   {
      super.fillCopyInstance(whatToFill)
      whatToFill.y = y;
   }
}

so irgendwie... Aber das Konstruktorzeug fände ich da echt eleganter.

PS: statische Methoden würde ich in diesem Fall nicht verwenden, da die nicht überladbar sind. Da müßte man immer alle Copys der Oberklassen kopieren oder aber mit "B::A.getNewInstance" in die Oberklasse referenzieren. Wenn man dann mal Klassen umhängt, bricht gleich das Chaos los...

 

[Tobias]

Ja, so gesehen macht das Sinn. Nur blöd, dass die Exception erst zur Laufzeit fliegt und nicht einfach schon der Compiler mosert. Ums Umbenennen der Methode werde ich wohl nicht herumkommen ...

mpG
Tobias