Discussion :

[hagane1]

Bonjour,

Je voudrais savoir pourquoi quand je doit cloner un objet en JAVA il faut implémenter
l'interface Cloneable malgré quelle ne contient pas la signature de la méthode clone()
J'ai trouver des articles qui parlent qu'il s'agit de l'interface de marquage et serve à
quelque chose à JVM.
Mon problème c'est que je savoir comment JVM traite l'interface de marquage
Cloneable et aussi la classe qui l'implémente car je n'est encore compris à quoi sert
réellement l'interface de marquage.

Merci.

[thelvin]

Hello,

clone() est une méthode de la classe Object, autrement dit, présente sur toutes les classes, toujours, tout le temps.
Mais certaines classes ne sont pas prévues pour être clonables et ne devraient pas l'être.

Donc, pour faire la différence entre celles qu'on peut cloner et celles qu'on ne peut pas, on utilise l'interface de marquage Cloneable. Si une classe implémente Cloneable ses instances peuvent être clonées, sinon non.


Pourquoi c'est fait comme ça, c'est-à-dire, pourquoi clone() est présent dans la classe Object alors qu'on veut pas pouvoir tout cloner mais seulement ce qui implémente Cloneable,
eh bien, le truc c'est plutôt que si on essaie de faire autrement ça ne va pas :
- Object.clone() fournit une fonctionnalité dont on a besoin pour cloner : créer un nouvel objet de même classe et copier tous les champs dedans.
- Une interface ne peut pas fournir cette fonctionnalité, donc c'est une classe qui doit le faire.
- Le clonage peut nécessiter un traitement en plus de ce que fournit Object.clone(), par exemple pour remplacer le shallow-copy par du deep-copy. clone() doit donc être redéfinissable par les classes clonables, pour appeler Object.clone() puis faire des traitements supplémentaires ensuite.
- Rendre le clonage possible ou non ne doit pas imposer de contrainte sur la hiérarchie de classe qu'on peut avoir. Par exemple Si on a une classe abstraite Fruit, on veut que Abricot soit clonable mais que FruitDefendu ne le soit pas car c'est un singleton.
- On ne peut hériter que d'une seule classe, donc rendre le clonage possible ne peut pas être par l'héritage d'une classe.
- Le clonage doit être accessible à quiconque décide de rendre sa classe clonable, donc la classe qui fournit Object.clone() doit être la classe mère de toutes les classes. Donc Object, et pas une autre.

Conclusion : avoir clone() dans la classe Object et rendre le clonage possible par moyen d'une interface de marquage, ça fonctionne.
Faire autrement, ça a l'air un peu vaseux.

Note en allant un peu plus loin : le clonage reste un mécanisme limité qui ne répond pas si souvent à un besoin réel. En général quand on veut copier des objets, on définit son propre mécanisme pour, parce que le clonage natif ne pouvait pas gérer ci ou ça. Il n'y a pas lieu de réfléchir trop longtemps au clonage en Java. Si ça fait le job, on s'en sert, sinon c'est pas grave.

[professeur shadoko]

je rajouterai un petit quelque chose: clone() de Object est protected.
qu'est ce que ça veut dire? que le code d'une classe qui hérite de Object peut décider d'invoquer clone sur l'instance courante .... mais qu'un autre code ne le peut pas!
Une interface n'a que des méthodes publiques mais l'objet Cloneable peut spécialiser clone() soit en le rendant public soit en le laissant protected (dans ce cas la limitation de protected reste : mais les opérations liées au clonage sont modifiées -par exemple copie en profondeur-)

[hagane1]

Bonjour,

merci pour le temps consacré à me répondre, j'aimerai bien que vous m'expliquer quelque points S.V.P :

- << Mais certaines classes ne sont pas prévues pour être clonables et ne devraient pas l'être >>. Pouvez-vous me donner des

exemples sur des classes qui ne soient pas clonables.

- << Donc, pour faire la différence entre celles qu'on peut cloner et celles qu'on ne peut pas, on utilise l'interface de marquage

Cloneable >>. Si j'ai bien compris, quelque part dans des bibliotheques JVM ou le compilateur il y a un IF cette classe instance of Cloneable donc

exécuter les operations de clonage, est ce que ce point de vu est correct ?

- << Rendre le clonage possible ou non ne doit pas imposer de contrainte sur la hiérarchie de classe qu'on peut avoir >> Je n'est pas

bien compris l'exemple,je ne voit pas de qu'elle contrainte il s'agit ?

- Pourquoi il faut toujours redéfinir clone() alors qu'ensuite on appelle super.clone() est ce que c'est à cause de shallow-copy et deep-copy ou autre chose ?

Au dernier point merci à vous : thelvin et professeur shadoko pour vos infos.

[thelvin]

Pouvez-vous me donner des exemples sur des classes qui ne soient pas clonables.

Bah là ce qui me passe par la tête :

- Tous les singletons, et pour la même raison tous les enums et trucs qui essaient de fonctionner comme un enum.
- Toutes les classes immutables. C'est pas que ce serait très gênant de les cloner, mais ça sert à rien, alors on les clone pas. String, Integer, Boolean, LocalDate...
- Tous les objets liés à une ressource unique :
-- Tous les InputStream, OutputStream, Socket, Connection...
-- Tous les objets managés, comme les entités Hibernate. Quand Hibernate enregistre l'état d'une entité côté Java, il ne faut pas qu'on lui refile ensuite un autre objet qu'il n'a pas enregistré mais qui se fait passer pour la même entité.

Si j'ai bien compris, quelque part dans des bibliotheques JVM ou le compilateur il y a un IF cette classe instance of Cloneable donc exécuter les operations de clonage, est ce que ce point de vu est correct ?

Dans la JVM, oui.

Je n'est pas bien compris l'exemple,je ne voit pas de qu'elle contrainte il s'agit ?

Supposons que pour montrer qu'une classe est clonable, on n'utilise pas une interface, mais une classe qui s'appellerait Cloneable.

Dans ce cas dans l'exemple que j'ai donné on pourrait imaginer deux possibilités :
- Abricot étend Cloneable. Mais ça ne va pas parce qu'alors il n'étend pas Fruit. On veut que Abricot étende Fruit.
- Fruit étend Cloneable. Dans ce cas Abricot, qui étend Fruit, est bien clonable. Mais FruitDefendu, qui étend aussi Fruit, devient aussi clonable. Ça ne va pas, il n'y a qu'un seul FruitDefendu, c'est un singleton, il ne doit pas être clonable.

=> Le marquage ne peut pas se faire au moyen d'une classe, ce serait trop de contraintes.

- Pourquoi il faut toujours redéfinir clone() alors qu'ensuite on appelle super.clone() est ce que c'est à cause de shallow-copy et deep-copy ou autre chose ?

Il ne faut pas toujours le faire, mais assez souvent il faudra le faire pour ces histoires de shallow-copy et deep-copy, oui.

[hagane1]

Bonjour,

merci infiniment pour vos explications vraiment vous m'avez éclerer beaucoup de points noirs, je sius trés reconaissants.

Merci encore 1000 fois et à la prochaine !!!!!!.