Quel est l'interet de ca ! CLONE()

Bonjour,

j'aimerais savoçir quel est l interet d'implémenter Cloneable.

par exemple quelle est la difference entre :

Méthode 1:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public static void main(String[] args) {   Rectangle a; // création d'une référence a = new Rectangle(10, 12); // instanciation de la classe Rect. Rectangle b = null; try { b = (Rectangle) a.clone();   } catch (CloneNotSupportedException e) { // TODO Auto-generated catch block e.printStackTrace(); } }// a et b ne contiennent pas la même réf. et pointent sur des objets différents

---

Méthode 2:

Code:

---

1 2 3 4 5 6

public static void main(String[] args) {   Rectangle a= new Rectangle(10, 12); Rectangle a= new Rectangle(10, 12); }

---

Le premier cas, on utilise la méthode clone pour créer une copie de b, c'est a dire un objet indépendant et identique de l'objet 'a'.

et la deuxieme, on passe cette fois pour créer notre objet b, par le contructeur de la classe rectangle.

Bon, au niveau de la mémoire c'est deux objets existent quelques soit la méthode 1 ou 2.

Alors j'aimerais comprendre quelle est l'interet d'avoir une méthode clone, vu qu'au niveau ressource mémo c'est idem ... ca sert à quoi ? 8O

Je reprend ton exemple :

Imagine maintenant que dans pour ton rectangle, dans une partie de ton code, tu modifies la largeur, puis encore plus loin la longueur en fonction de paramètres extérieurs.
Comment peux-tu récupérer une copie de ton rectangle sans utilisé clone ?
Vu que tu ne vas pas pouvoir le construire étant donné que tu ne connais plu la longueur et la largeur?

ah ouais !

supposons que 'a' est un objet de "test et de truc", 'b' est l'objet cloné de 'a', afin de faire d'autre traitement spécifique et 'c' un autre objet qui qui est cloné de 'a' afin de faire d'aaaaaautre traitement spécifique ...

et bien, je fais des clones.

ok ok.
merci.

Citation:

---

j'aimerais savoçir quel est l interet d'implémenter Cloneable.

---

à faire la guerre des clones ? :mouarf:

C'est aussi efficace qu'un contructeur par recopie (profonde ou pas, après c'est ta méthode clone() qui le dira)

Avec des tonnes d'opérations, ça permet de faire des résultats intermédiaires ou même des divergences pour comparer tes différents algos. (précision, efficacité, vitesse ... que sais-je, des performances quoi ^^)

Salut,


En effet, un clone consiste à fait une copie identique.
Un constructeur permet de créer un objet. Bien sûr si on connait tous les détails de l'objet on peut en créer une copie identique, mais ce n'est pas forcément le cas en particulier lorsqu'on manipule des classes filles (sans forcément le savoir).

Une erreur courante étant d'implémenter clone() de la manière suivante :

Code:

---

1 2 3 4 5 6 7 8

class MyClass implements Cloneable {   @Override protected Object clone() throws CloneNotSupportedException { return new MyClass(); }   }

---

:arrow: Le cloneage ne fonctionnera plus dans les classes filles !




Enfin petits rappels :

• La CloneNotSupportedException n'est remonté que si la classe n'implémente pas Cloneable. On peut ainsi "ignorer" cette exception (c'est à dire remonter une RuntimeException à la place).
• Ne pas oublier qu'on peut changer la visibilité de la méthode clone() et la passé de protected à public ;)
• Penser également qu'on a tout à faut le droit de "supprimer" une exception de la signature d'une méthode, ce qui peut simplifier la vie lorsqu'on sait qu'elle ne sera jamais remontée.
• Avec Java 5.0 et la covariance du type de retour on peut spécialiser le type de retour d'une méthode, et se débarrasser du cast.

Plus d'info : Quelles sont les règles à respecter pour redéfinir/implémenter une méthode ?


Ce qui peut donner comme implémentation :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class MyClass implements Cloneable {   @Override public MyClass clone() { try { return (MyClass) super.clone(); } catch (CloneNotSupportedException e) { // Ceci ne devrait jamais arriver : throw new RuntimeException("Clone fail", e); } }   }

---

a++

Hello,
Je rajouterai juste qu'il peut parfois être judicieux de préférer des constructeurs de clônage (manière de clôner sans utiliser Cloneable):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class MyClass { MyClass() {}   // Constructeur de clônage MyClass(MyClass toClone) { this(); // TODO : copier les champs de toClone dans this } }   // Classe fille class MyClass2 extends MyClass { MyClass2(MyClass2 toClone) { super(toClone); // ... } }

---

Perso, je n'ai jamais aimé Cloneable (en tout cas à l'époque où le cast était obligatoire).

Je préfère cette méthode ;)

Citation:

---

Envoyé par Pill_S

Je rajouterai juste qu'il peut parfois être judicieux de préférer des constructeurs de clônage (manière de clôner sans utiliser Cloneable):

---

Juste une remarque : on parle plutôt de constructeur de copie et ce n'est pas réellement une cloneage puisque le type n'est pas forcément le même.

Par exemple :

Code:

---

1 2	MyClass c1 = new MyClass2(); MyClass c2 = new MyClass(c1);

---

Mais cela n'enlève rien au fait que cela puisse être utile...

a++