Pourquoi pas ICloneable<T>?

Est-il une raison particulière pour laquelle un générique ICloneable<T> n'existe pas?

Il serait beaucoup plus à l'aise, si je n'aurai pas besoin de le lancer à chaque fois que je clone quelque chose.

Non! avec tout le respect dû à la 'raisons', je suis d'accord avec vous, ils doivent avoir mis en place!
Il aurait été une bonne chose pour Microsoft d'avoir défini (le problème avec brew-votre-propre interfaces interfaces dans les deux assemblées seront incompatibles, même si elles sont sémantiquement identiques). Si j'avais été la conception de l'interface, il aurait trois membres, Clone de Soi, et CloneIfMutable, qui serait de retour T (le dernier membre soit de retour Clone ou le Soi, selon le cas). L'Auto membre ferait-il possible d'accepter une ICloneable(de Foo) en tant que paramètre et ensuite l'utiliser comme un Toto, sans avoir besoin d'un transtypage.
Ce qui permettrait une bonne clonage hiérarchie de classe, où héritables classes exposent protégés "clone" de la méthode, et ont scellé des instruments dérivés que d'exposer un établissement public. Par exemple, on pourrait avoir des Tas, CloneablePile:Pile, EnhancedPile:Pile, et CloneableEnhancedPile:EnhancedPile, aucun ne serait brisé si cloné (même si pas tous les exposer à un public méthode de clonage), et FurtherEnhancedPile:EnhancedPile (qui serait brisé si cloné, mais n'est pas d'exposer la méthode de clonage). Une routine qui accepte un ICloneable(de la Pile) pourrait accepter une CloneablePile ou un CloneableEnhancedPile...
...même si CloneableEnhancedPile n'hérite pas de CloneablePile. Notez que si EnhancedPile hérité de CloneablePile, FurtherEnhancedPile aurait pour exposer un public méthode de clonage et peut être transmis à un code qui attendent pour le Clone, en violation de la Liskov Substituabilité Principe. Depuis CloneableEnhancedPile serait la mise en œuvre ICloneable(De EnhancedPile) et par voie de conséquence ICloneable(De la Pile), il pourrait être passée à une routine attend à une clonable dérivé de la Pile.

InformationsquelleAutor Bluenuance | 2009-02-11

107

ICloneable est considéré comme un mauvais API maintenant, car il ne précise pas si le résultat est d'une profondeur ou d'une copie. Je pense que c'est pourquoi ils n'améliorent pas cette interface.

Vous pouvez probablement le faire tapé le clonage de la méthode d'extension, mais je pense qu'il aurait besoin d'un nom différent, puisque les méthodes d'extension ont moins d'importance que ceux d'origine.
- Je suis en désaccord, mal ou pas mal, c'est très utile parfois pour les clonning, et dans ces cas est vraiment nécessaire, le Clone<T>, pour enregistrer un inutile boxing et unboxing.
- Est-il une bonne alternative?
- Je pense que cela devrait être une question distincte. Une réponse peut être BinaryFormatter Sérialiser/Désérialiser profond de clonage, mais cela dépend vraiment de la tâche, la performance requise, etc.
- Qu'entendez-vous par les méthodes d'extension ont moins d'importance que ceux d'origine.
- Ce qui est pas clair à propos de deep vs peu profonde clonage? Si List<T> avait une méthode clone, je l'espère pour donner une List<T> dont les éléments ont la même identité en tant que personnes dans la liste d'origine, mais je m'attends à ce que toutes les structures de données internes seraient deux fois que nécessaire pour s'assurer de ne rien faire pour une liste va affecter le identités des éléments stockés dans l'autre. Où est l'ambiguïté? Le plus gros problème avec le clonage est livré avec une variation de la "diamond problème": si CloneableFoo hérite de [le public n'a pas clonable] Foo, devrait CloneableDerivedFoo de dériver à partir de...
- ou à partir de [le public n'a pas clonable] DerivedFoo? Je dirais que générique ICloneable<out T> pourrait résoudre le problème si elle dérive de ISelf<out T> qui contient un Self propriété de type T qui renvoie simplement lui-même. Dans ce cas, quelqu'un qui a besoin d'un clonable DerivedFoo pourrait accepter un paramètre de type ICloneable<DerivedFoo>.
- Je ne peux pas dire que je comprends votre attente pleinement, comme ce sera vous considérez qu'un identity de la liste elle-même, par exemple (dans le cas d'une liste de listes)? Cependant, ignorant que, votre attente n'est pas la seule idée possible que les personnes peuvent avoir lors de l'appel ou de la mise en œuvre de Clone. Que faire si la bibliothèque des auteurs mise en œuvre de certaines autres liste ne suivez pas vos attentes? L'API doit être trivialement sans ambiguïté, sans doute pas sans ambiguïté.
- Supposons qu'un atelier de réparation automobile a une liste de toutes les voitures qui sont en service à un moment donné. Une telle liste serait mutable. Quelqu'un est demandé de prendre un "instantané" de la liste des voitures dans la boutique à certains moment particulier. En écrivant "le tableau blanc dans le magasin" sur un bout de papier (faire un double référence à la liste) ne serait pas suffisant, car la prochaine fois que la liste est changé, ne représentent plus une liste des voitures que a été dans le magasin lorsque la capture a été censé être prises. D'autre part, ...
- demandé de faire un instantané de la liste ne serait pas prévu pour la fabrication des doubles de toutes les voitures à ce sujet. Les voitures elles-mêmes sont des objets mutables, avec de nombreux mutable propriétés, mais pas tous properies sont mutables. La marque et le modèle, par exemple, serait immuable, donc un instantané de la liste de capturer la marque et le modèle de la voitures laissé toute la nuit. On ne s'attendrait pas le double de la liste de capturer tout mutable propriétés (par exemple, la lecture du compteur kilométrique), cependant, à moins que la liste elle-même contenue explicite des copies.
- Une chose importante à noter, cependant, est que duplciate voitures et de mettre par écrit les VINs de ces dupliquer des voitures exigerait non seulement beaucoup de travail supplémentaire--il serait aussi fondamentalement mal. Compte tenu des listes quotidiennes de VINs, il est possible de déterminer combien de temps une voiture particulière a séjourné dans la boutique pour la nuit. Si chaque cliché de la liste contenait les VINs de voitures qui ont été conçus pour s'adapter aux voitures qui ont été mis en, toutefois, une telle analyse serait impossible, car une telle liste serait de ne plus enregistrer identité de voitures qui ont été amenés.
- Si vous parlez de la copie. Cependant, il n'y a rien de fondamentalement mauvais dans une copie en profondeur, par exemple si vous voulez faire un réversibles transaction sur des objets en mémoire. Votre attente est basé sur votre cas d'utilisation, d'autres personnes peuvent avoir des attentes différentes. Si elles mettez vos objets en objets (ou vice versa), les résultats sont inattendus.
- Le terme "copie" est parfois utilisé pour faire référence à ce que j'ai décrit, et parfois utilisé pour désigner le résultat de MemberwiseClone sur une classe ou la copie d'une structure. Bien qu'il existe des situations où les plus profondes de la copie serait approprié, de tels scénarios entraîne un resserrement de la copie de la collection et de son contenu que de façon implicite par quelque chose comme un List<T>, et si l'on va à ce niveau, il faut aller au-delà de Clone, à l'aide d'une interface avec les membres AsImmutable() et AsMutable(); appel AsImmutable sur un objet doit donner une immuable instantané.
- Immuable objet est un instantané de son propre état, et pourrait donc revenir lui-même. Un objet mutable devrait créer un immuable de l'instantané et de retour que. Si vous le souhaitez, il peut mettre en cache que de l'instantané et la prochaine fois AsImmutable est appelé, le retour de la mise en cache instantané si il était encore bon. Même si la seule façon de savoir si la mise en cache de l'instantané est toujours valide a été pour générer un nouveau immuable de l'objet et de le comparer, de retour en cache instantané permettrait d'accélérer les comparaisons entre elle et le plus tôt un. Une bonne faible stage de collecte pourrait améliorer encore les choses.
- Inconditionnel de profondeur-le clonage des objets mutables devrait à mon humble avis, être considéré comme un anti-modèle. Tout agressif de copie sur écriture approches ne sont pas bon pour la performance sur multi-thread systèmes, l'utilisation partagée des objets immuables de la partie d'une hiérarchie profonde qui sont en commun entre les instances peuvent être une grande victoire.
- vous ne prenez pas en compte, il est une partie de .NET framework, ne fait pas partie de votre application. donc, si vous faites une classe qui ne fait pas de profondeur de clonage, puis quelqu'un d'autre fait une classe qui ne font profonde clonage et les appels Clone sur toutes ses parties, il ne fonctionnera pas de façon prévisible, selon qu'elle a été mise en œuvre par vous ou cette personne qui aime profondément le clonage. votre point sur les motifs, c'est valable, mais ayant à mon humble avis, l'API n'est pas assez clair -- il soit devrait être appelé ShallowCopy insiste sur ce point, ou ne sont pas fournis à tous.
- Si j'avais un objet qui a mis en place IList<T> et ICloneable, et T était un type de classe, je m'attends à ce que le clonage devrait me donner une nouvelle liste qui a tenu les références à l'objet même cas que l'original. Je peux considérer un clone fonction qui n'a rien d'autre comme rompu. Pour qu'un objet clone plus profond que son contenu sémantique n'est pas "en option"--c'est une rupture de comportement.
- Je suppose que peut-être le plus gros problème est que Microsoft n'a pas simplement préciser que ICloneable devraient travailler dans le seul mode qui serait logique et utile dans le cas général (c'est ce que j'ai décrit), mais je ne vois aucune raison pourquoi il devrait en aucune autre façon. Bien sûr, on a du mal à être le seul cas où Microsoft a été à la hauteur dans sa sémantique des spécifications. Objet de l'égalité a le même problème. Il n'est pas difficile de définir une relation d'équivalence qui serait sans ambiguïté applicables à chaque type d'objet, mais...
- ...De Microsoft de mettre quelques bizarreries dans un couple de types de mise en œuvre de Equals. Une bonne relation d'équivalence permettrait de préciser que les deux objets doivent comparer "l'égalité" si et seulement si ils seraient indiscernables du point de vue sémantique, sauf par la vérification de référence de l'égalité. Avoir une relation d'équivalence disponible pour toutes les classes faciliterait les choses comme un stage de cours (étant donnés deux objets à comparer l'égalité, dont l'un est dans un stage dictionnaire, on serait capable de se substituer à l'autre en toute sécurité). Dommage que le Object.Equals des remplacements de float, double, et Decimal ne fonctionnent pas de cette façon.
- FWIW, je suis venu à cette question dans la recherche d'une méthode canonique pour cloner une liste, de sorte que je pouvais modifier les propriétés de ses membres, sans altérer les membres de la liste d'origine.
InformationsquelleAutor Andrey Shchekin
136

En plus de Andrey réponse (dont je suis d'accord avec, +1) - lorsque ICloneable est fait, vous pouvez également choisir la mise en œuvre explicite de rendre le public Clone() retour typé objet:
```
public Foo Clone() { /* your code */ }
object ICloneable.Clone() {return Clone();}
```
Bien sûr, il y a un deuxième problème avec un générique ICloneable<T> - héritage.

Si j'ai:
```
public class Foo {}
public class Bar : Foo {}
```
Et j'ai mis en place ICloneable<T>, alors dois-je mettre en œuvre ICloneable<Foo>? ICloneable<Bar>? Vous démarrez rapidement la mise en œuvre d'un lot à l'identique des interfaces...
Comparer à un casting... et est-il vraiment si mauvais?
- +1 j'ai toujours pensé que la covariance problème était la vraie raison
- Il y a un problème avec cela: l'interface explicite la mise en œuvre doit être privé, qui pourrait entraîner des problèmes de Foo à un certain point besoin d'être jeté à ICloneable... Suis-je manqué quelque chose?
- Pourquoi cela pose un problème, exactement? Je ne suis pas votre logique...
- Mon erreur: il s'avère que, en dépit d'être défini comme privé, la méthode est devrait être appelé Foo être jeté à IClonable (CLR via C# 2e Éd, p.319). Semble étrange décision de conception, mais il est. Donc Foo.Clone() donne la première méthode, et ((ICloneable) Foo).Clone() donne à la deuxième méthode.
- En fait, explicite implémentations d'interface sont, à proprement parler, partie de l'API publique. Ils sont disponibles publiquement via le moulage.
- Oui. A une mauvaise odeur bien que, à mon humble avis: des méthodes qui sont déclarées privé doit être privé, zut.
- OK; montrez-moi où il est ", a déclaré privé" ;-p
- De 20.4.1: interface Explicite membre implémentations ont différentes caractéristiques d'accessibilité que les autres membres. En raison d'interface explicite membre des implémentations ne sont jamais accessibles à travers une interface qualifiée nom de membre dans un appel de méthode ou de l'accès à la propriété, ils sont en un sens...
- ...privé. Toutefois, étant donné qu'ils peuvent être accessibles via une interface exemple, ils sont dans un sens aussi public.
- CQFD 😉 (pourquoi min 10 caractères pour un commentaire?)
- La solution proposée semble au début... jusqu'à ce que vous vous rendez compte que dans une hiérarchie de classe, vous voulez " public Foo Clone()' pour être virtuel et redéfinie dans les classes dérivées de sorte qu'ils peuvent retourner leur propre type (et clone leurs propres champs, bien sûr). Malheureusement, vous ne pouvez pas changer le type de retour dans une substitution (la covariance problème mentionné). Alors, vous venez cercle complet pour le problème d'origine à nouveau - la mise en œuvre explicite n'a pas vraiment vous acheter beaucoup (en plus de retourner le type de base de votre hiérarchie, au lieu de l '"objet"), et vous êtes de retour à la coulée de la plupart de votre Clone() résultats des appels. Beurk!
- En ce qui concerne vos réponses, sur la ligne d'objet ICloneable.Clone() {return Clone();}, comment est-ce que Foo Clone() sera appelée, et pas ICloneable.Clone() de manière récursive?
- parce que : implémentation d'interface explicite
InformationsquelleAutor Marc Gravell
19

J'ai besoin de demander, exactement ce que voulez-vous faire avec l'interface autres que mettre en œuvre? Les Interfaces sont généralement seulement utile lorsque vous lancez pour elle (c'est à dire est-ce à l'appui de classe 'IBar"), ou ont des paramètres ou des poseurs qui le prendre (c'est à dire je prends un 'IBar'). Avec ICloneable - nous sommes allés à travers l'ensemble de la structure et a échoué à trouver une seule utilisation qui était autre chose qu'une mise en œuvre. Nous avons également échoué à trouver toute utilisation dans le 'monde réel' qui n'est autre chose que de le mettre en œuvre (dans le ~de 60 000 applications que nous avons accès à l').

Maintenant, si vous souhaitez juste d'appliquer un modèle que vous voulez de votre "clonable" des objets à mettre en œuvre, c'est tout à fait amende à l'utilisation et à aller de l'avant. Vous pouvez également décider exactement ce que le "clonage" signifie pour vous (c'est à dire profonde ou peu profonde). Toutefois, dans ce cas, il n'y a pas besoin de nous (BCL) de la définir. Nous n'définir des abstractions de la BCL quand il y a un besoin d'échanger des instances de taper comme cette abstraction entre les indépendants bibliothèques.

David Kean (BCL Équipe)
- Non générique ICloneable n'est pas très utile, mais ICloneable<out T> pourrait être très utile si elle a hérité de ISelf<out T>, avec une méthode unique Self de type T. On n'a pas souvent besoin de "quelque chose qui est clonable", mais on peut très bien avoir besoin d'un T c'est clonable. Si un clonable objet implémente ISelf<itsOwnType>, une routine qui a besoin d'un T c'est clonable peut accepter un paramètre de type ICloneable<T>, même si pas tous de la clonable dérivés de T partagent un ancêtre commun.
- Merci. Semblable à la fonte de la situation je l'ai mentionné ci-dessus (à savoir " est-ce à l'appui de classe 'IBar'). Malheureusement, nous n'avons qu'à de très rares et isolés des scénarios où vous auriez fait utiliser le fait que T est clonable. Avez-vous des situations dans l'esprit?
- Une chose qui est parfois maladroit dans .net est la gestion mutable collections lorsque le contenu d'une collection sont censés être considérée comme une valeur (c'est à dire je veux savoir, plus tard, l'ensemble des éléments qui sont dans la collection). Quelque chose comme ICloneable<T> pourrait être utile pour cela, mais un cadre plus large pour le maintien parallèle changeant et immuable classes pourraient être plus utiles. En d'autres termes, le code qui a besoin de voir ce que certains type de Foo contient mais qui n'est ni va muter, ni s'attendre à ce que ça ne changera jamais pu utiliser un IReadableFoo, tandis que...
- ...code qui veut tenir le contenu de Foo pourrait utiliser un ImmutableFoo alors que le code qu'il veut manipuler un MutableFoo. Le Code donné n'importe quel type de IReadableFoo devrait être en mesure d'obtenir un mutables ou immuable version. Un tel cadre serait bien, mais malheureusement je ne trouve pas de bonne façon de mettre les choses en place d'une façon générale. Si il y avait un moyen cohérent de faire un wrapper en lecture seule pour une classe, une telle chose pourrait être utilisé en combinaison avec ICloneable<T> pour rendre immuable copie d'une classe qui détient T'.
- Si vous êtes désireux de cloner un List<T>, tels que la cloné List<T> est une nouvelle collection de portefeuille des pointeurs vers tous les mêmes objets dans la collection d'origine, il y a deux façons de le faire sans ICloneable<T>. La première est la Enumerable.ToList() méthode d'extension: List<foo> clone = original.ToList(); la seconde est La List<T> constructeur qui prend un IEnumerable<T>: List<foo> clone = new List<foo>(original); je soupçonne que la méthode d'extension est probablement juste d'appeler le constructeur, mais deux de ces à faire ce que vous demandez. 😉
- Compte tenu de tout IEnumerable<T>, on peut produire une séquence immuable en l'appelant ToList et puis habillage dans un ReadOnlyCollection<T> ou autrement s'assurer qu'il ne sera jamais exposé à tout ce qui pourrait les transformer. Mes plaintes qui sont (1) une List<T> est juste une sorte de chose; il n'y a pas d'interface standard qui permettent de faire un immuable copie de tout ce qui implémente l'interface sans avoir à connaître ce que c'est; (2) le "clonage" d'une instance qui est déjà immuable par simplement la copie de la référence peut être de plusieurs ordres de grandeur plus efficace...
- ...que de faire une copie de son contenu. Supposons, par exemple, que l'on a une IEnumerable<T> mySequence, and one wants wasSequence " pour désigner un objet qui retourne toujours la séquence d'éléments qui mySequence retourne maintenant. Si mySequence est Enumerable.Range(1,1000000), on pourrait dire wasSequence=new ReadOnlyCollection<int>(mySequence.ToList()); mais la copie de la référence pourrait être de plusieurs ordres de grandeur plus rapide.
- Je ne suis pas en désaccord avec vous, en soi, mais tient à souligner que ReadOnlyCollection<T> ne peut être construit à partir d'un IList<T>, de sorte que si vous voulez utiliser un autre immuable collection wrapper, vous êtes un peu coincé avec le convertir en un List<T> (ou un tableau) en premier. Je suis d'accord qu'il ne serait pas logique de faire un clone immuable de la collection, mais encore une fois, je ne sais ReadOnlyCollection<T>, de sorte qu'il serait trivial de prévoir une exclusion explicite pour ce cas. Comme pour Enumerable.Range(), j'ai eu à le regarder pour voir ce que c'est, mais...
- ...de la description, il retourne quelques type inconnu qui reporte l'exécution jusqu'à ce qu'il est énuméré. Donc, la seule chose que nous pouvons dire, c'est que vous pouvez énumérer parce qu'il met en œuvre IEnumerable<int>, donc il n'y a aucun moyen de savoir si c'est modifiable ou non, sans essayer de le convertir en une IList<int> ou quelque chose comme ça et essayer de le changer. La seule chose que vous pouvez faire dans cette situation est d'énumérer dans une liste ou d'une matrice, et de créer un ReadOnlyCollection<int> à partir de, si vous êtes désireux de vous assurer que vous avez un immuable de la collection.
- Ah, et juste faire une recherche rapide, il semble qu'il y a quelques autres moins utilisés immuable collections SynchronizedReadOnlyCollection<T>, ReadOnlyObservableCollection<T>, et ReadOnlyDictionary<TKey,TValue>. Et il ressemble à la BCL est de travailler sur l'ajout de plus (j'espère qu'ils vont tout mettre en œuvre IReadOnlyCollection<T> à taper facilement vérifier). J'ai seulement utilisé ReadOnlyCollection<T> à une occasion, donc je n'ai pas la prétention d'être un expert dans ce domaine. Et encore, je suis pas en train de débattre de vous, j'étais juste en pointant une solution simple pour le scénario, vous l'avez souligné. 😉
- Mon point était que le manque des interfaces standardisées liées à l'immutabilité signifie qu'il n'y a souvent pas d'autre alternative pour faire des copies redondantes des données immuables-un fait qui peut augmenter l'exécution de la taille et des exigences de la mémoire par des ordres de grandeur. L'a indiqué Enumerable.Range, btw, est immuable de l'objet qui encapsule la séquence {1, 2, 3, 4,..., 9999999, 10000000}. Compte tenu de cette séquence, on pourrait faire un immuable objet qui encapsule la même séquence par la construction de 10 000 000-élément du tableau, mais simplement la copie de la référence est un beaucoup moins cher.
- M. Kean s'est demandé ce que l'utilisation du clonage serait, et j'étais en train de suggérer que le clonage en lui-même n'est pas forcément utile, mais il pourrait être utile si il y avait également un certain soutien pour l'immutabilité. S'il existait un IConvertibleToImmutable avec un AsImmutable, puis avec des types immuables ou partiellement immuable la sauvegarde de magasins pourraient le mettre en œuvre de manière plus efficace qu'un straight-up clone.
- Encore une fois, je ne suis pas expert sur immuable des collections ou des objets, mais si je les utilise, je suis d'accord qu'il serait mieux d'avoir une sorte de drapeau sur eux pour indiquer qu'ils sont immuables. Malheureusement, il semble que même IReadOnlyCollection<T> échoue à cet égard puisqu'elle est mise en œuvre sur List<T>! [facepalm] peu importe, tout ce que je suggère est un moyen de cloner une liste, sans même parler de la mutabilité. Merci pour le débat bien. 😉
InformationsquelleAutor David Kean

Je pense que la question "pourquoi" est inutile. Il y a beaucoup d'interfaces/classes/etc... ce qui est très utile, mais n'est pas partie .NET Frameworku bibliothèque de base.

Mais, surtout, vous pouvez le faire vous-même.

public interface ICloneable<T> : ICloneable {
new T Clone();
}
public abstract class CloneableBase<T> : ICloneable<T> where T : CloneableBase<T> {
public abstract T Clone();
object ICloneable.Clone() { return this.Clone(); }
}
public abstract class CloneableExBase<T> : CloneableBase<T> where T : CloneableExBase<T> {
protected abstract T CreateClone();
protected abstract void FillClone( T clone );
public override T Clone() {
T clone = this.CreateClone();
if ( object.ReferenceEquals( clone, null ) ) { throw new NullReferenceException( "Clone was not created." ); }
return clone
}
}
public abstract class PersonBase<T> : CloneableExBase<T> where T : PersonBase<T> {
public string Name { get; set; }
protected override void FillClone( T clone ) {
clone.Name = this.Name;
}
}
public sealed class Person : PersonBase<Person> {
protected override Person CreateClone() { return new Person(); }
}
public abstract class EmployeeBase<T> : PersonBase<T> where T : EmployeeBase<T> {
public string Department { get; set; }
protected override void FillClone( T clone ) {
base.FillClone( clone );
clone.Department = this.Department;
}
}
public sealed class Employee : EmployeeBase<Employee> {
protected override Employee CreateClone() { return new Employee(); }
}

Tout réalisable méthode clone pour un héritées de la classe doit utiliser l'Objet.MemberwiseClone comme un point de départ (ou d'autre utilisation de la réflexion) car sinon il n'y a aucune garantie que le clone sera du même type que l'objet d'origine. J'ai une assez belle figure, si vous êtes intéressés.
pourquoi ne pas faire une réponse alors?
"Il y a beaucoup d'interfaces/classes/etc... ce qui est très utile, mais n'est pas partie .NET Frameworku de base de la bibliothèque." Pouvez-vous nous donner des exemples?
c'est à dire: avancée structures de données comme le b-arbre rouge-noir arbre, cercle de la mémoire tampon. En '09 il n'y avait pas de n-uplets, générique faible de référence, les collections simultanées ...

InformationsquelleAutor TcKs

10

Il est assez facile de écrire l'interface vous-même si vous en avez besoin:
```
public interface ICloneable<T> : ICloneable
where T : ICloneable<T>
{
new T Clone();
}
```
- Assez facile à inclure dans le answe...ah, attendez...
- Je préfère le lier à respecter le droit d'auteur...
- J'ai inclus un extrait de depuis en raison de l'honneur de la copie-droits le lien a été brisé...
- Et comment exactement est que l'interface censé fonctionner? Le résultat d'un clone de l'opération de moulage de type T, de l'objet cloné a tirer de T. Il n'y a pas moyen de mettre en place un tel type de contrainte. De manière réaliste, la seule chose que je peux voir le résultat de iCloneable retour est un type iCloneable.
- oui, c'est exactement ce que Clone() retourne: un T qui implémente ICloneable<T>. MbUnit a été à l'aide de cette interface pour ans, donc oui, il fonctionne. Comme pour la mise en œuvre, de prendre un coup d'oeil dans MbUnit de la source.
- Scheffer: je vois ce qu'il se passe. Pas de type en fait met en œuvre iCloneable(de T). Au lieu de cela, chaque type implémente iCloneable(de lui-même). Cela serait, je suppose, mais il n'est de déplacer un transtypage. C'est dommage qu'il n'y aucun moyen de déclarer un champ comme ayant un héritage de contrainte et d'une interface, il serait utile d'avoir une méthode de clonage de retour d'un objet d'une semi-clonable (clonage exposés en tant que méthode Protégée uniquement) type de base, mais avec un clonable type de contrainte. Qui permettrait à un objet à accepter clonable dérivés de semi-clonable dérivés d'un type de base.
- Scheffer: BTW, je dirais que ICloneable(T) prennent également en charge une readonly Auto propriété de type de retour T). Cela permettrait une méthode d'accepter une ICloneable(de Foo) et de l'utiliser (via l'Auto de propriété) Foo.
InformationsquelleAutor Mauricio Scheffer
8

Avoir lu récemment l'article Pourquoi la Copie d'un Objet est une chose terrible à faire?, je pense que cette question a besoin d'une plus clafirication. D'autres réponses ici de fournir de bons conseils, mais encore la réponse n'est pas complète - pourquoi pas ICloneable<T>?
1. Utilisation
  
  Donc, vous avez une classe qui l'implémente. Alors qu'auparavant vous aviez une méthode qui voulait ICloneable, il doit désormais être générique à accepter ICloneable<T>. Vous auriez besoin de les modifier.
  
  Ensuite, vous pourriez avoir obtenu une méthode qui vérifie si un objet is ICloneable. Que faire maintenant? Vous ne pouvez pas faire is ICloneable<> et que vous ne connaissez pas le type de l'objet lors de la compilation de type, vous ne pouvez pas faire la méthode générique. Premier vrai problème.
  
  Si vous avez besoin d'avoir à la fois ICloneable<T> et ICloneable, l'ancien œuvre de ces dernières. Ainsi, un opérateur devra mettre en œuvre les deux méthodes - object Clone() et T Clone(). Non, merci, nous avons déjà assez de plaisir avec IEnumerable.
  
  Comme l'a déjà souligné, il y a aussi la complexité de l'héritage. Alors que la covariance peut sembler pour résoudre ce problème, un type dérivé doit mettre en œuvre ICloneable<T> de son propre type, mais il y a déjà une méthode avec la même signature (= les paramètres, essentiellement) - le Clone() de la classe de base. Faire de votre nouveau clone de l'interface de la méthode explicite est inutile, vous perdrez l'avantage d'avoir demandé lors de la création de ICloneable<T>. Ajoutez la new mot-clé. Mais n'oubliez pas que vous aussi, vous avez besoin pour remplacer la classe de base Clone() (la mise en œuvre doit rester uniforme pour toutes les classes dérivées, c'est à dire le retour de l'objet même de chaque méthode clone, de sorte que la base de méthode clone doit être virtual)! Mais, malheureusement, vous ne pouvez pas à la fois override et new méthodes avec la même signature. Le choix du premier mot-clé, vous perdez l'objectif que vous avez voulu avoir lors de l'ajout d' ICloneable<T>. Sélections d'angle le second, vous vous souhaitez rompre l'interface elle-même, faisant les méthodes que doit faire la même déclaration des objets différents.
2. Point
  
  Vous voulez ICloneable<T> pour le confort, mais le confort n'est pas ce que les interfaces sont conçues pour, leur signification est (en général POO) pour unifier le comportement des objets (bien qu'en C#, il est limité à unifier le comportement extérieur, par exemple, les méthodes et les propriétés, pas de leur fonctionnement).
  
  Si la première raison n'a pas convaincu vous encore, vous pourriez objecter que ICloneable<T> pourrait également travailler de manière restrictive, afin de limiter le type retourné par la méthode clone. Cependant, les mauvais programmeur peut mettre en œuvre ICloneable<T> où T n'est pas le type qui est mise en œuvre. De sorte que, pour atteindre votre restriction, vous pouvez ajouter une belle contrainte pour le paramètre générique:
  
  public interface ICloneable<T> : ICloneable where T : ICloneable<T>
  
  Certainement plus restrictive que l'un sans where, vous ne pouvez toujours pas limiter cette T est le type qui implémente l'interface (que vous pouvez tirer d' ICloneable<T> de type différent qui l'implémente).
  
  Vous voyez, même ce but ne pouvait être atteint (l'original ICloneable échoue également à présent, aucune interface ne peut vraiment limiter le comportement de la mise en œuvre de la classe).
Comme vous pouvez le voir, cela prouve faisant l'interface générique est à la fois difficile à mettre pleinement en œuvre et aussi vraiment inutiles et inutiles.

Mais pour en revenir à la question, vraiment ce que vous cherchez est pour avoir le confort lors du clonage d'un objet. Il y a deux façons de le faire:

D'autres méthodes
```
public class Base : ICloneable
{
public Base Clone()
{
return this.CloneImpl() as Base;
}
object ICloneable.Clone()
{
return this.CloneImpl();
}
protected virtual object CloneImpl()
{
return new Base();
}
}
public class Derived : Base
{
public new Derived Clone()
{
return this.CloneImpl() as Derived;
}
protected override object CloneImpl()
{
return new Derived();
}
}
```
Cette solution fournit à la fois le confort et l'intention de comportement des utilisateurs, mais c'est aussi trop longue à mettre en place. Si nous ne nous en voulez pas "à l'aise" méthode retournant le type de courant, il est beaucoup plus facile d'avoir juste public virtual object Clone().

Donc, nous allons voir le "nec plus ultra" de la solution - ce qu'en C# est vraiment destiné à nous donner du réconfort?

Les méthodes d'Extension!
```
public class Base : ICloneable
{
public virtual object Clone()
{
return new Base();
}
}
public class Derived : Base
{
public override object Clone()
{
return new Derived();
}
}
public static T Copy<T>(this T obj) where T : class, ICloneable
{
return obj.Clone() as T;
}
```
Il est nommé Copie ne pas entrer en collision avec le courant Clone méthodes (compilateur préfère le type propre a déclaré méthodes sur l'extension de celles). Le class contrainte est-il pour la vitesse (ne nécessite pas de nulle vérifier etc.).

J'espère que cela clarifie la raison pourquoi ne pas faire une ICloneable<T>. Toutefois, il est recommandé de ne pas mettre en œuvre ICloneable à tous.
- Annexe n ° 1: Le seul usage possible d'un générique ICloneable est pour les types de valeur, d'où il pourrait contourner la boxe de la méthode Clone, et il implique que vous avez de la valeur "unboxed". Et que les structures peuvent être clonés (faiblement), il n'est pas nécessaire de le mettre en œuvre (à moins de faire que cela signifie copie en profondeur).
InformationsquelleAutor IllidanS4 wants Monica back
2

Bien que la question est très vieux (5 ans à partir de l'écriture de cet réponses 🙂 et a déjà été répondu, mais j'ai trouvé cet article répond à la question très bien, vérifier ici

EDIT:

Voici la citation de l'article qui répond à la question (assurez-vous de lire l'article au complet, il inclut d'autres choses intéressantes):

Il existe de nombreuses références sur Internet pointant vers un 2003 post de blog
par Brad Abrams - au moment de l'emploi à Microsoft, dans lequel certains
réflexions sur ICloneable sont discutés. L'entrée de blog peut être trouvé
à cette adresse: La Mise En Œuvre De ICloneable. Malgré le caractère trompeur
titre, cette entrée de blog les appels à ne pas mettre en œuvre ICloneable, principalement
en raison de la faible/la confusion profonde. L'Article se termine par une droite
suggestion: Si vous avez besoin d'un mécanisme de clonage, de définir votre propre Clone, ou
Copie de la méthodologie et de vous assurer de consigner clairement si c'est un
profonds ou de copie. Un modèle approprié est: public <type> Copy();

InformationsquelleAutor Sameh Deabes
1

Un gros problème, c'est qu'ils pourraient ne pas restreindre T à la même classe. Par exemple ce qui vous empêcherait de le faire:
```
interface IClonable<T>
{
T Clone();
}
class Dog : IClonable<JackRabbit>
{
//not what you would expect, but possible
JackRabbit Clone()
{
return new JackRabbit();
}
}
```
Ils ont besoin d'un paramètre de restriction comme:
```
interfact IClonable<T> where T : implementing_type
```
- Cela ne semble pas aussi mauvais que class A : ICloneable { public object Clone() { return 1; } /* I can return whatever I want */ }
- Je ne vois vraiment pas quel est le problème. Aucune interface ne peut forcer les implémentations de se comporter de façon raisonnable. Même si ICloneable<T> pourrait contraindre T pour correspondre à son propre type, ce qui n'aurait pas la force de mise en œuvre de Clone() de retourner quelque chose à distance ressemblant à l'objet sur lequel il a été cloné. De plus, je dirais que si l'on est en utilisant l'interface de covariance, il peut être préférable d'avoir des classes qui implémentent ICloneable être scellé, l'interface ICloneable<out T> comprennent un Self la propriété, qui est prévue pour retourner lui-même, et...
- ...ont les consommateurs de la fonte ou contraindre à ICloneable<BaseType> ou ICloneable<ICloneable<BaseType>>. Le BaseType en question devrait avoir un protected méthode de clonage, qui sera appelé par le type qui implémente ICloneable. Ce serait la possibilité que l'on pourrait le souhaiter avoir un Container, un CloneableContainer, un FancyContainer, et un CloneableFancyContainer, le dernier étant utilisable dans le code qui nécessite une clonable dérivés de Container ou qui nécessite une FancyContainer (mais ne se soucie pas si c'est clonable).
- La raison pour laquelle je serais favorable à une telle conception est que la question de savoir si un type peut être cloné intelligemment est un peu orthogonale à d'autres aspects. Par exemple, on pourrait avoir un FancyList type qui pourrait être cloné sensiblement, mais un dérivé peut automatiquement persistent son état dans un fichier de disque (spécifié dans le constructeur). Le type dérivé ne pouvait pas être cloné, parce que son état serait attaché à une mutable singleton (le fichier), mais cela ne devrait pas empêcher l'utilisation du type dérivé dans les endroits qui ont besoin de la plupart des fonctionnalités d'un FancyList mais n'aurait pas besoin de le cloner.
- +1 - cette réponse est le seul de ceux que j'ai vu ici qui répond vraiment à la question.
InformationsquelleAutor sheamus
0

C'est une très bonne question... Vous pourriez faire votre propre, cependant:
```
interface ICloneable<T> : ICloneable
{
new T Clone ( );
}
```
Andrey dit que c'est considéré comme un mauvais API, mais je n'ai rien entendu à propos de cette interface de devenir obsolète. Et ce serait casser des tonnes d'interfaces...
La méthode Clone doit effectuer une copie superficielle.
Si l'objet fournit également copie en profondeur, une surcharge du Clone ( bool profonde ) peut être utilisé.

EDIT: le Modèle que j'utilise pour le "clonage "" un objet, c'est le passage d'un prototype dans le constructeur.
```
class C
{
public C ( C prototype )
{
...
}
}
```
Ce qui supprime toute possibilité de code redondant de mise en œuvre de situations.
BTW, parler des limitations de ICloneable, n'est-il pas vraiment à l'objet lui-même de décider si un clone simple ou profond clone, ou même une partie peu profonde/partie profonde clone, doivent-ils être effectués? Doit-on vraiment s'en soucier, tant que l'objet fonctionne comme prévu? Dans certaines occasions, un bon Clone de la mise en œuvre pourrait très bien inclure à la fois superficiels et profonds de clonage.
- le "mauvais" ne veut pas dire obsolète. Il signifie simplement "vous êtes mieux de ne pas l'utiliser". Il n'est pas déconseillé dans ce sens que "nous allons supprimer l'interface ICloneable dans l'avenir". Ils ont juste vous encourager à ne pas l'utiliser, et ne pas le mettre à jour avec les médicaments génériques ou d'autres nouvelles fonctionnalités.
- Dennis: Voir Marc réponses. La Covariance / les problèmes de succession font de cette interface assez bien inutilisable pour tout scénario qui est au moins légèrement compliqué.
- Oui, je peux voir les limites de ICloneable, pour sûr... j'ai rarement besoin d'utiliser le clonage, si.
InformationsquelleAutor baretta

Vous devez vous connecter pour publier un commentaire.

D'autres méthodes

Les méthodes d'Extension!