this-Zeiger im Copy-Konstruktor überschreiben?

[Vereth]

Wenn ich eine Klasse myClass habe, die das Interface Cloneable implementiert, kann ich dann einen Copy-Konstruktor folgendermaßen schreiben?

public myClass (myClass m)
{ this = (myClass)m.clone(); }

 

[Matthias Reitinger]

Hallo,

das wird so nicht klappen. this ist keine Variable, deshalb darf es nicht auf der linken Seite einer Zuweisung auftreten.

Grüße,
Matthias

 

[Vereth]

Ist es denn überhaupt üblich, bzw. sinnvoll, einen Copy-Konstruktor zu implementieren? Eigentlich ist er redundant, wenn es eine passende clone()-Methode gibt.
Und warum muss clone() immer Object zurückgeben?

 

[Vincentius]

Hallo,

ich würde statt dem Konstruktor eine statische Factory-Methode verwenden:

public static MyClass clone( MyClass source ) throws CloneNotSupportedException
{
  MyClass clone = ( MyClass ) source.clone();
  return clone;
}

Grüße
Vincent

 

[deepthroat]

Hi.

Hallo,

ich würde statt dem Konstruktor eine statische Factory-Methode verwenden:

public static MyClass clone( MyClass source ) throws CloneNotSupportedException
{
  MyClass clone = ( MyClass ) source.clone();
  return clone;
}

Wozu sollte das gut sein? Um dann

MyClass b = MyClass.clone(b);

statt einfach nur:

MyClass b = a.clone();

schreiben zu können? Find ich nicht sinnvoll.

Ein Kopierkonstruktor ist in Java nicht üblich. Diesem Konstruktor kommt ja auch keine besondere Bedeutung (wie z.B. in C++) zu.

Gruß

 

[CPoly]

Wenn ich mich recht erinnere hat der Prof in der Vorlesung gesagt, man sollte möglichst immer einen Kopierkonstruktor schreiben. Wenn man dann noch eine clone() Methode will, besteht der Rumpf der Methode nur aus "return new MyClass(original);"

 

[Kai008]

Es gibt ja schon einige vorgefertigte Klassen mit Copykonstructoren. (Denke ich, habe ich noch nie verwendet.)
z. B. Font, also unüblich ist es wohl eher nicht.

Aber warum drehst du es nicht einfach um?
Also statt dass du in clone die Variablen überträgst, und es im Constructor aufrufst, übertrage doch im Constructor die Variablen auf das neue Objekt und rufe in clone beim erzeugen dieses den Konstructor auf.

 

[deepthroat]

Hi.

Es gibt ja schon einige vorgefertigte Klassen mit Copykonstructoren. (Denke ich, habe ich noch nie verwendet.)
z. B. Font, also unüblich ist es wohl eher nicht.

Du hast recht. Siehe z.B. http://www.javapractices.com/topic/TopicAction.do?Id=12

Man sollte wohl die clone Methode lieber in Ruhe lassen: http://www.javapractices.com/topic/TopicAction.do?Id=71

Gruß

 

[Vincentius]

Hi.
Wozu sollte das gut sein?

Das könnte schon sinnvoll sein, um dort z.B. das Exception-Handling einzubauen, die source-Instanz auf null zu prüfen, eventuell um bestimmte Felder der source-Instanz ebenfalls durch eine clone() Methode zu kopieren. Man kann sich auch vorstellen, einige Felder wieder auf default-Wert zu setzen. Das kommt immer auf die konkrete Implementierung an. Mit einer Factory-Metzode vermeidet man redundanten Code.

Grüße
Vincent

 

[Vereth]

Wenn ich mich recht erinnere hat der Prof in der Vorlesung gesagt, man sollte möglichst immer einen Kopierkonstruktor schreiben. Wenn man dann noch eine clone() Methode will, besteht der Rumpf der Methode nur aus "return new MyClass(original);"

Dies war auch der Ansatz, den ich intuitiv verfolgt habe (mir war gar nicht bewusst, wie viele Gründe es noch gibt, diese Vorgehensweise zu wählen). Ich dachte aber, ich könnte das shallow copy nutzen, um mir das Kopieren von Variablen primitiver Datentypen zu ersparen, wenn ich die Vorgehensweise umkehre. Es wird übrigens empfohlen, den Copy-Konstruktor als protected zu deklarieren. Eine genauere Diskussion zu dem Thema habe ich in Why Copying an Object is a terrible thing to do? gefunden. Dort wird übrigens auch erklärt, warum es sinnvoll ist, clone() weiterhin zu unterstützen.