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.