clone(), Clonable und Felder von Interfacetypen

[Biesterfeld]

Hej,

wozu ist eigentlich dieses dämliche Interface Clonable da, wenn es mir keinen Pups weiterhilft?

Ich verwende grundsätzlich für Klassenvariablen Typen von Interfaces. Wenn ich aber nun z.B. ein Set clonen möchte geht etwas wie das nicht:

public class Klasse{
  
  private final Set meinSet;

  public Klasse(){
    this.meinSet = new HashSet();
  }
  
  public Klasse( Set set ){
    this.meinSet = set;
  }

  public Set cloneMeinSet(){
    return ( Set ) this.meinSet.clone()
// -------------------------------^^^^
  }
}

Natürlich könnte ich vor dem Aufruf von clone() nach HashSet casten, allerdings wähle ich ja bewusst die Interfacedeklaration um z.B. im Falle des zweiten Konstruktors unabhängig von der konkreten Implementierung zu bleiben. Und mit instanceOf alle möglichen Sets abzufragen und entsprechend zu casten kann ja auch nicht im Sinne der OOP sein.

Und Clonable bringt mir eben in einem solchen Fall herzlich wenig, dadurch wird clone() auch nicht sichtbarer.
Meine Frage: Wie umgeht ihr solche Probleme?

Herzlichen Dank und Beste Grüße
Biesterfeld

 

[Beni]

Nicht alles was dir nicht weiterhilft, ist dämlich... :wink:

Clonable gibt einfach an, dass diese Objekt tatsächlich die clone-Methode implementiert hat. Laut API sollten Klassen, die nicht Cloneable implementieren, auch kein clone implementiert haben.
Theoretisch könnte man dann mit "object instanceof Cloneable" testen, ob ein Objekt geklont werden kann.

Wie sinnvoll das ist...
Wieso eine Methode in allen Objekten haben, die man doch nicht implementiert, bzw. wenn mans implementiert, dann soll ein Interface daher? Dann würde die Methode auch in das Interface gehören, und nicht in Object. Wenn es einen tieferen Sinn hat, ich kenne ihn nicht :wink:

Ich mache lieber Copykonstruktoren. Da übergibt man dem Konstruktor ein "Original", und die Kopie kopiert sich das, was sie benötigt. Manchmal mach ich auch ein "Copyable"-Interface, mit einer public Methode "copy".

 

[Biesterfeld]

Hej,

Wieso eine Methode in allen Objekten haben, die man doch nicht implementiert, bzw. wenn mans implementiert, dann soll ein Interface daher? Dann würde die Methode auch in das Interface gehören, und nicht in Object.

Naja, das mein ich ja! Was nützt mir ein Vertrag ohne eine einzige Klausel? Und was nützt mir eine Klausel ohne Vertrag?
clone() hätte ganz klar nach Clonable gehört. Erst recht wenn Object schon clone() beherrbergt aber nicht rausrückt.

Ich mache lieber Copykonstruktoren. Da übergibt man dem Konstruktor ein "Original", und die Kopie kopiert sich das, was sie benötigt. Manchmal mach ich auch ein "Copyable"-Interface, mit einer public Methode "copy".

Genau das mache ich auch. Aber es bringt mir eben bei meinem konkreten Problem nichts, wo ich auf Objekte der Standard-API zugreife und die entsprechende clone()-Implementation auch gIch mache lieber Copykonstruktoren. Da übergibt man dem Konstruktor ein "Original", und die Kopie kopiert sich das, was sie benötigt. Manchmal mach ich auch ein "Copyable"-Interface, mit einer public Methode "copy".
nau das ist was ich benötige.

Dank dir trotzdem und Beste Grüße
Biesterfeld

 

[Biesterfeld]

Hej,

und nochmal im ganzen Satz, da is vorhin was schief gelaufen:

Genau das mache ich auch. Aber es bringt mir eben bei meinem konkreten Problem nichts, wo ich auf Objekte der Standard-API zugreife und die entsprechende clone()-Implementation auch gIch mache lieber Copykonstruktoren. Da übergibt man dem Konstruktor ein "Original", und die Kopie kopiert sich das, was sie benötigt. Manchmal mach ich auch ein "Copyable"-Interface, mit einer public Methode "copy".
nau das ist was ich benötige.

Hätte heissen müssen:

Genau das mache ich auch. Aber es bringt mir eben bei meinem konkreten Problem nichts, wo ich auf Objekte der Standard-API zugreife und die entsprechende clone()-Implementierung auch genau das ist was ich benötige.

Beste grüße
Biesterfeld