109 votes

Pourquoi devrais-je implémenter ICloneable dans c #?

Pouvez vous m’expliquer pourquoi je devrais hériter de et mettre en œuvre la méthode ?

Si je veux faire une copie complète, ne peux pas juste appliquer ma méthode ? Disons que `` ?

Pourquoi je devrais hériter de `` ? Quels sont les avantages ? Est-ce juste une question de rendre le code « plus lisible » ?

116voto

Matt Hamilton Points 98268

Vous ne devriez pas. Microsoft recommande de mettre en œuvre car il n’y a pas d’indication claire de l’interface si votre méthode exécute un clone « profond » ou « superficielle ».

Voir ce billet de blog de Brad Abrams en 2003(!) pour plus d’informations.

29voto

supercat Points 25534

L' ICloneable interface en elle-même n'est pas très utile, c'est à dire qu'il n'y a pas beaucoup de situations où il est utile de savoir qu'un objet est clonable sans savoir quoi que ce soit d'autre. C'est une situation très différente, par exemple, d' IEnumerable ou IDisposable; il y a de nombreuses situations où il est utile d'accepter un IEnumerable sans connaître autre chose que de la façon de les énumérer.

D'autre part, ICloneable peut être utile lorsqu'il est appliqué comme une contrainte générique avec d'autres contraintes. Par exemple, une classe de base peut utilement soutenir un certain nombre de produits dérivés, dont certains pourraient utilement être cloné, et certains qui ne le pouvaient pas. Si le type de base lui-même exposé à un public de clonage de l'interface, alors que tous les dérivés de type qui n'a pas pu être cloné serait violer le Principe de Substitution de Liskov. La façon d'éviter ce problème est d'avoir le type de base de soutien de clonage à l'aide d'une méthode Protégée, et de permettre les types dérivés pour mettre en œuvre un public de clonage de l'interface comme ils l'entendent.

Une fois que cela a été accompli, une méthode qui se veut à accepter un objet d'un WonderfulBase type, et doit être en mesure de cloner, peut être codé pour accepter un WonderfulBase objet qui prend en charge le clonage (à l'aide d'un paramètre de type générique avec base-type et ICloneable contraintes). Bien que l' ICloneable interface ne serait pas lui-même indiquer profonds ou de clonage, de la documentation pour WonderfulBase permettrait de savoir si clonable WonderfulBase doit être profonde ou peu profonde cloné. Essentiellement, l' ICloneable interface ne serait pas accomplir quoi que ce soit qui ne serait pas accompli par la définition d' ICloneableWonderfulBase, sauf qu'il permettrait d'éviter d'avoir à définir des noms différents pour chaque clonable de la classe de base.

18voto

JoshBerke Points 34238

ICloneable est l'un de ces artefacts dans la BCL qui a été controversée. Il n'y a pas de véritable raison à mon humble avis, pour la mettre en œuvre. Avec ce dit, si je vais créer un clone de la méthode puis-je faire mettre en oeuvre ICloneable, et je fournir mon propre forte dactylographié de Clone.

Le problème avec l' ICloneable est-il n'a jamais indiqué si Clone a été un peu profonde ou d'une copie en profondeur, qui sont des choses très différentes. Le fait qu'il n'y a pas d' ICloneable<T> pourrait être une indication sur Microsoft pensées sur ICloneable

9voto

John Rasch Points 28874

Matt est correct, ne l’utilisez pas. Créez votre propre `` méthode (ou nom similaire) et le rendre parfaitement clair dans votre API publique si votre méthode crée une copie superficielle ou profonde de votre objet.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X