Discussion :

[dabeuliou]

Bonsoir à tous,

Je découvre Java depuis quelques jours et mes lectures ne répondent pas à une question existentielle sur l'utilité de la méthode clone dans Object. Je m'explique :

- La méthode clone(), si elle est définie dans Object ne peut pas être utilisée sur une objet dont la classe n'implémente pas l'interface Cloneable.
- Cette interface est vide.
=> pourquoi ne pas déclarer la méthode clone dans Cloneable et la virer de Object puisque bien que cette méthode fasse partie de l'interface de la classe Object, on ne peut pas s'en servir tant que l'interface Cloneable n'est pas implémentée... Peut-être y a-t-il une bonne raison à cela et je suis curieux de la connaître !

Je suis sans doute un peu trop formaté par mon C# quotidien qui suit le schéma que je décris.

Merci pour vos éclaircissements.

[herve91]

Parce que la méthode clone() de la classe Object n'est pas une méthode abstraite mais dispose bel et bien d'une implémentation, la méthode clone() est d'ailleurs native, donc non écrite en Java. Par défaut, la méthode clone() crée une nouvelle instance de l'objet et effectue une copie "physique" des attributs de l'objet.
Lorsque la méthode clone() est redéfinie dans une sous-classe, la première chose à faire est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
try {
   Object cloned = super.clone();
} catch (CloneNotSupportedException ex) {
   // ne peut pas arriver si la classe implémente Cloneable
}

pour être sûr que les attributs de l'objet sont bien copiés. Ensuite, libre au programmeur de définir un comportement spécifique de la méthode, par exemple pour dupliquer un attribut en profondeur (collection, ...).
Si la méthode clone() était spécifiée par l'interface Cloneable, il serait impossible de s'appuyer sur l'implémentation par défaut disponible dans la classe Object.

[dabeuliou]

Effectivement, ça paraît être une raison valable, merci pour l'explication.

[adiGuba]

Salut,


De même, cela permet d'implémenter Cloneable tout en laissant la méthode clone() en protected, et donc utilisable seulement par les méthodes d'instances ou les classes filles...

Plus de détail dans "Penser en Java" : Pourquoi cet étrange design ?

A noter que de nos jours on utiliserait surement un autre pattern (avec des annotations on pourrait faire quelque chose de bien plus propre).

Mais de toute manière le cloneage n'est pas vraiment utile en java...

a++

[dabeuliou]

De même, cela permet d'implémenter Cloneable tout en laissant la méthode clone() en protected, et donc utilisable seulement par les méthodes d'instances ou les classes filles...

Effectivement, c'est un autre argument. Sur le même sujet, j'en profite pour chercher la confirmation de ce que je lis : je n'ai vu nulle part la possibilité d'implémenter une interface de manière explicite comme le permet C#. J'en déduis que ce n'est pas possible en Java.
Sans en détailler la syntaxe qui n'a pas d'intérêt ici, l'implémentation explicite permet de masquer les méthodes de l'interface lorsque la référence n'est pas downcastée dans le type de l'interface => ça permet à une classe d'implémenter une interface sans polluer cette dernière et c'est souvent très élégant.

Merci pour le lien, il explique plutôt bien la relative étrangeté de ce design.

[_Mac_]

Mais de toute manière le cloneage n'est pas vraiment utile en java...

Ben justement, j'en ai besoin aujourd'hui même, donc ça arrive ! Vous allez dire que mon pattern est assez bizarre, mais j'ai besoin de clone() pour "synchroniser" 2 beans (1 form bean Struts et un bean User tout simple que je clone). En gros, dans mon form bean Struts, j'ai une methode setUser(User) qui clone le bean User avant de l'affecter à une propriété d'instance. Ensuite, sur chaque méthode setXxx() de mon form bean, j'appelle la méthode équivalente sur mon clone de User. Comme ça, lorsque je fait un getUser() sur mon form bean, je suis sûr (modulo l'ordre d'appel des méthodes setUser() et autres setXxx()) de récupérer un User avec les dernières bonnes infos du formulaire.

Ca vous paraît crédible ?

[zekey]

Ben justement, j'en ai besoin aujourd'hui même, donc ça arrive ! Vous allez dire que mon pattern est assez bizarre, mais j'ai besoin de clone() pour "synchroniser" 2 beans (1 form bean Struts et un bean User tout simple que je clone). En gros, dans mon form bean Struts, j'ai une methode setUser(User) qui clone le bean User avant de l'affecter à une propriété d'instance. Ensuite, sur chaque méthode setXxx() de mon form bean, j'appelle la méthode équivalente sur mon clone de User. Comme ça, lorsque je fait un getUser() sur mon form bean, je suis sûr (modulo l'ordre d'appel des méthodes setUser() et autres setXxx()) de récupérer un User avec les dernières bonnes infos du formulaire.

Ca vous paraît crédible ?

J'ai rien compris Pourquoi fais tu un clone et pourquoi n'utilises tu pas directement l'instance originale de ton bean user ?
[mode evangelist]Passe à spring tes forms pourront être des pojo et donc tu pourra utiliser tes pojo dans ta couche web[/mode evangelist] <-- je vais encore me faire des ennemis j'adore ca.

[_Mac_]

[mode evangelist]Passe à spring tes forms pourront être des pojo et donc tu pourra utiliser tes pojo dans ta couche web[/mode evangelist] <-- je vais encore me faire des ennemis j'adore ca.

Ouais, ben on choisit pas toujours sa technologie !!

Pourquoi je fais un clone ? C'est simplement parce que mon bean User initial peut être référencé ailleurs dans une sorte de cache (le bean est issue d'une recherche donc j'ai optimisé) et je ne veux pas que les modifs non "commitées" apparaissent quand on réaffiche la recherche.

[zekey]

Ouais, ben on choisit pas toujours sa technologie !!

Pourquoi je fais un clone ? C'est simplement parce que mon bean User initial peut être référencé ailleurs dans une sorte de cache (le bean est issue d'une recherche donc j'ai optimisé) et je ne veux pas que les modifs non "commitées" apparaissent quand on réaffiche la recherche.

Naturellement je plaisantais, je sais bien que l'on ne fait pas toujours ce que l'on veut. Cependant cette idée de cache me dérange un peu mais bon je ne connais pas votre architecture et vos use cases. Il faut avoir de gros problèmes de performances pour mettre en place un cache de ce type, c'est une mine de bugs potentiels et de problèmes de synchronisation(pas au sens java). Pas en fait ce que tu fais c'est une sorte de système de versioning de beans....

[adiGuba]

Sans en détailler la syntaxe qui n'a pas d'intérêt ici, l'implémentation explicite permet de masquer les méthodes de l'interface lorsque la référence n'est pas downcastée dans le type de l'interface => ça permet à une classe d'implémenter une interface sans polluer cette dernière et c'est souvent très élégant.

Tiens je ne savais pas que c'était possible en .NET ! C'est un concept intéressant mais cela n'existe pas en Java...

En général on utilise une classe interne ou une classe anonyme pour cela...

a++

[_Mac_]

Il faut avoir de gros problèmes de performances pour mettre en place un cache de ce type, c'est une mine de bugs potentiels et de problèmes de synchronisation(pas au sens java). Pas en fait ce que tu fais c'est une sorte de système de versioning de beans....

Perf, oui : faut que je croise des infos entre un annuaire LDAP et une base de données en récupérant un max d'info des 2. Je suis assez partisan de l'optimisation alors ce que j'ai récupéré une fois, j'essaie de ne pas aller le récupérer une seconde fois.

Sinon, j'ai fait plus "simple" sans clone, ce qui revient au même fonctionnellement et en plus allège la mémoire.