Cloner un Objet : clone() vs copie par constructeur

Bonjour,

Je suis en train de lire le livre "Java effective" de Joshua Bloch, et une des recommandations concerne la copie d'objets.

L'auteur y énonce qu'il est préférable d'utiliser une copie par constructeur, plutôt que d'utiliser la méthode clone() . J'ai relu plusieurs fois ces quelques pages et j'avoue que j'ai encore du mal à comprendre.

En fait, j'ai compris pourquoi les copies par constructeur étaient de bonnes choses (utilisation des champs finaux, etc), mais je ne comprends pas tellement les défauts de la méthode clone().

Pour moi, c'est une méthode comme une autre où il est possible d'y effectuer les actions que l'on veut (une copie profonde par exemple), et on peut donc faire la même chose que dans un constructeur. Et à mon avis, c'est là où je rate un point essentiel. :)

Si vous pouviez éclairer ma lanterne...

Lien : http://www.artima.com/intv/bloch13.html

Merci d'avance !

Citation:

---

Envoyé par Peps0u

Pour moi, c'est une méthode comme une autre où il est possible d'y effectuer les actions que l'on veut (une copie profonde par exemple), et on peut donc faire la même chose que dans un constructeur. Et à mon avis, c'est là où je rate un point essentiel. :)

---

Pourtant il en parle dans ce lien. En résumé :

- clone() n'apporte rien de plus que le mécanisme de constructeurs, et, non, quelque chose qui fait double emploi n'est pas une bonne chose, c'est une mauvaise chose qui ne fait que compliquer et n'a pas de bon point (car si elle en avait on ne parlerait pas de double emploi.)
On peut envisager des exceptions sémantiques, comme Math.sqrt() et Math.pow(), alors que la racine carrée n'est qu'une élévation à la puissance un demi, mais c'est parce que c'est plus clair pour les gens qui ne sont pas habitués à ça. clone() n'a pas de ce genre de considérations.

- clone() est cassé, non-intuitif et plein de pièges. Il encourage les bugs et le code sale. Non pas par son double emploi, mais par sa conception.

J'ajouterais quand meme que pour le débat cloner par constructeur ou cloner par fonction, il y a une limitation importante au clonage par constructeur : le polymorphisme. En effet, ca impose de connaitre la classe cible, ce qui n'est pas toujours le cas. En ce qui me concerne, je n'utilise pas non plus clone. En général, si j'en ai besoin, j'utilise plutot une méthode getCopy qui renvoie un clone de l'objet (mais bien fait). :)

En gros,

le clonage par constructeur permet de gérer les champs finaux
le clonage par une méthode spécifique (clone ou autre) permet de gérer le polymorphisme

Maintenant, tu peux combiner, une méthode clone() qui appelle un constructeur par copie...

En fait, je me rappelle être tombé sur un cas de clonage à faire il y a quelque temps.

En gros, tous les champs de type primitifs devaient avoir leur propre valeurs, mais le fait que les champs de type objet soient partagés ne me dérangeait pas du tout (pour mon cas particulier évidemment).

Dans ce cas là, la méthode clone() n'est elle pas la plus appropriée ? Car si on ajoute un nouveau champ de type primitif, tout est automatique.

Citation:

---

Envoyé par Peps0u

Dans ce cas là, la méthode clone() n'est elle pas la plus appropriée ? Car si on ajoute un nouveau champ de type primitif, tout est automatique.

---

C'est plus rapide, plus facile, plus automatique. Mais c'est fragile. Figé. Impossible à étendre. Susceptible d'introduire des bugs avec le temps.

Maintenant, c'est moi qui parle là, si on sait que ça va rester simple, ce n'est pas à proprement parler un problème

Citation:

---

Envoyé par Peps0u

Dans ce cas là, la méthode clone() n'est elle pas la plus appropriée ? Car si on ajoute un nouveau champ de type primitif, tout est automatique.

---

De toute facon, rien ne t'interdit de l'utiliser. Il faut juste savoir quelles sont les limites et les risques. Apres, ce n'est qu'une question de choix. C'est pour ca que developpeur, c'est un métier :)

Merci pour vos réponse, je pense avoir mieux cerner le "problème" (qui n'en était pas vraiment un) :) !