Generische Schnittstelle "ICloneable<T>"

[KeinBockZuCasten]

Hi @ all,

ganz einfach: Warum gibt es keine generische ICloneable-Schnittstelle in .NET, sondern nur die einfache?

Beispiel:

public interface ICloneable<T>
{
  T Clone();
}

Gäbe es nämlich, dieses Interface könnte ich mir jegliches Gecaste sparen wie z.B.

TextBox txtBox = new TextBox();
object obj = txtBox.Clone();
TextBox neueTxtBox = (TextBox)obj;

Es wäre ja kein Problem selbst so ein Interface zu schreiben...aber wahrscheinlich haben sich die .NET-Entwickler irgendetwas dabei gedacht, es nicht zu tun?! Ich bin bloß am Grübeln was ;-)!

[hajb]

http://bytes.com/forum/thread469671.html

Grantopalen

[Konrad Rudolph]

Die Erklärung ist Quark, aus zwei Gründen:

1. 'ICloneable' gab's einfach schon, bevor es Generics gab. Dass die Entwickler „decided to err on the side of caution“ ist daher einfach falsch.

2. Generische Schnittstellen wie die von `ICloneable` sind ein oft verwendetes Idiom, z.B. sichtbar in `IEquatable<T>` und `IComparable<T>`. Wenn die .NET-Designer sich hier für das Idiom entschieden haben, wieso sollten sie es dann an anderer Stelle ablehnen?

Der Grund ist in Wahrheit ein anderer. Und zwar hat die Cloneable-Interface generelle Probleme, die leider noch nicht behoben werden konnte. Aus diesem Grund hat man sich dagegen entschieden, die problematische Interface in einer generischen Version neu aufzulegen.

Das Problem der Cloneable-Interface ist, dass die Interface eigentlich nichts darüber aussagt, *wie* der Klon produziert wird, und daher ein wenig nutzlos ist. Es gibt im wesentlichen zwei Möglichkeiten, ein Objekt zu kopieren: Als shallow copy oder als deep copy. Bei der letzten Variante werden alle Mitglieder der Klasse geklont. Bei der ersten Variante werden sie nicht geklont sondern lediglich zugewiesen.

Da die Interface nichts darüber aussagt, welche der beiden Semantiken das Objekt implementieren soll, kann man sie eigentlich kaum sinnvoll einsetzen und muss daher eh andere Wege gehen. Ein häufig verwendeter Weg ist, das Objekt zu serialisieren und danach wieder zu deserialisieren. Total behindert, aber hey. Kopiersemantik wird in den modernen OO-Sprachen einfach nicht für wichtig genug befunden.

[THE_ONE]

Konrad Rudolph schrieb:

Ein häufig verwendeter Weg ist, das Objekt zu serialisieren und danach wieder zu deserialisieren. Total behindert, aber hey. Kopiersemantik wird in den modernen OO-Sprachen einfach nicht für wichtig genug befunden.

Sollte man Clone() also nicht verwenden?

Wie würde eine Clone(Kopie) mit Hilfe von Serialisieren und Deserialisieren aussehen? Könnte mir da jemand etwas Beispielcode posten.

Lg _THE_ONE_