¿Por qué debería implementar ICloneable en c #?

¿Puede explicarme por qué debería heredar ICloneablee implementar el Clone()método?

Si quiero hacer una copia profunda, ¿no puedo simplemente implementar mi método? Vamos a decir MyClone()?

¿Por qué debería heredar ICloneable? ¿Cuáles son las ventajas? ¿Es sólo una cuestión de hacer que el código sea "más legible"?

No deberías. Microsoft recomienda no implementar ICloneableporque no hay una indicación clara en la interfaz de si su Clonemétodo realiza un clon "profundo" o "superficial".

Consulte esta publicación de blog de Brad Abrams en 2003 (!) Para obtener más información.

La ICloneableinterfaz por sí sola no es muy útil, lo que quiere decir que realmente no hay muchas situaciones en las que sea útil saber que un objeto es clonable sin saber nada más sobre él. Esta es una situación muy diferente de eg IEnumerableo IDisposable; hay muchas situaciones en las que es útil aceptar un IEnumerablesin saber nada más que cómo enumerarlo.

Por otra parte, ICloneable puede ser útil cuando se aplica como una restricción genérica junto con otras restricciones. Por ejemplo, una clase base podría admitir de manera útil una serie de derivados, algunos de los cuales podrían clonarse de manera útil y otros no. Si el tipo de base expuso una interfaz de clonación pública, entonces cualquier tipo derivado que no pudiera clonarse violaría el principio de sustitución de Liskov. La forma de evitar este problema es hacer que el tipo base admita la clonación mediante un método protegido y permitir que los tipos derivados implementen una interfaz de clonación pública como mejor les parezca.

Una vez que se logró, un método que quiere aceptar un objeto de un WonderfulBasetipo, y necesita poder clonarlo, podría codificarse para aceptar un objeto WonderfulBase que admita la clonación (usando un parámetro de tipo genérico con tipo base y ICloneablerestricciones) . Aunque la ICloneableinterfaz en sí misma no indicaría una clonación profunda o superficial, la documentación de WonderfulBaseindicaría si la clonación WonderfulBasedebe ser profunda o superficial. Esencialmente, la ICloneableinterfaz no lograría nada que no se lograría mediante la definición ICloneableWonderfulBase, excepto que evitaría tener que definir nombres diferentes para cada clase base clonable diferente.

ICloneablees uno de esos artefactos en el BCL que ha sido controvertido. No hay ninguna razón real en mi humilde opinión para implementarlo. Dicho esto, si voy a crear un método de clonación, lo implemento ICloneabley proporciono mi propia versión de tipo fuerte Clone.

El problema ICloneablees que nunca se indicó si Cloneera una copia superficial o profunda, que son cosas muy diferentes. El hecho de que no exista ICloneable<T>podría ser una indicación de los pensamientos de Microsoft sobre ICloneable

Matt tiene razón, no lo uses. Cree su propio Copy()método (o un nombre similar) y deje perfectamente claro en su API pública si su método está creando una copia profunda o superficial de su objeto.