Discussion :

[alex2746]

Bonjour,
j'ai une classe représentant une Personne, les attributs sont:
nom, prénom et sexe.

Je dois surcharger la méthode clone() en faisant un deep copy..
Je ne vois vraiment pas comment écrire cette méthode.

Pouvez vous m'aider?

Merci

[Alkhan]

bonjour,
La réponse est la : clonage

[marcel_kobain]

Il te suffit simplement d'implémenter la méthode clone dans ta Classe Personnes :

Code :

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

1
2
3
4
5
	@Override
	protected Object clone() throws CloneNotSupportedException {
		// TODO Auto-generated method stub
		return new Person(this.name, this.lastName, this.sexe);
	}

[adiGuba]

Salut,

Il te suffit simplement d'implémenter la méthode clone dans ta Classe Personnes :

Code :

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

1
2
3
4
5
	@Override
	protected Object clone() throws CloneNotSupportedException {
		// TODO Auto-generated method stub
		return new Person(this.name, this.lastName, this.sexe);
	}

Sauf que ceci est incorrect puisque tu ne respectes pas les règles du cloneage !

Il ne faut pas utiliser un constructeur mais appeler la méthode clone() hérité de Object, en implémentant Cloneable.

Exemple "basique" :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class Person implements Cloneable {
 
	private String nom;
	private String prenom;
	private Date birthDay;
	private char sexe;
 
	@Override
	protected Object clone() throws CloneNotSupportedException {
		return super.clone();
	}
 
}

Il est inutile de dupliquer la valeur pour le "sexe", puisqu'il s'agit d'un type primitif et que le clone copiera alors sa valeur.
Pour les références c'est un peu plus compliqué car c'est la copie de la référence qui est effectué. Donc les deux références pointent vers le même objet en mémoire et il faut donc protéger cela par une copie explicite... sauf pour les types immuables (comme String) où cela est inutile et même contre-productif !

Donc cela devrait plutôt ressembler à ceci :

Code :

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

1
2
3
4
5
6
7
8
9
	@Override
	protected Object clone() throws CloneNotSupportedException {
		Person cloned = (Person) super.clone();
 
		// On duplique l'attribut birthDay, car il n'est pas immuable :
		cloned.birthDay = (Date) cloned.birthDay.clone();
 
		return cloned;
	}

Maintenant on peut encore améliorer cela de trois manière :

1. En supprimant l'exception de la déclaration de méthode. En effet cette dernière ne remontera que dans le cas où l'on implémente plus Cloneable. Inutile de se trainer une tel exception. Il est préférable de la cacher :
   

   Code :

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

   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   	@Override
   	public Object clone() {
   		try {
   			Person cloned = (Person) super.clone();
    
   			cloned.birthDay = (Date) cloned.birthDay.clone();
    
   			return cloned;
   		} catch (CloneNotSupportedException e) {
   			// On remonte l'exception englobé dans une RuntimeException,
   			// afin d'être quand même averti d'un éventuel problème :
   			throw new RuntimeException(e);
   		}
   	}

2. Selon les besoins, en déclarant le classe public afin de faciliter son utilisation depuis l'extérieur (ce qui est autorisé par le langage).
3. Enfin, depuis Java 5.0 il est possible de changer le type de retour, afin d'éviter un nouveau cast en sortie...

Ce qui donnerait au final :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
	@Override
	public Person clone() {
		try {
			Person cloned = (Person) super.clone();
 
			cloned.birthDay = (Date) cloned.birthDay.clone();
 
			return cloned;
		} catch (CloneNotSupportedException e) {
			// On remonte l'exception englobé dans une RuntimeException,
			// afin d'être quand même averti d'un éventuel problème :
			throw new RuntimeException(e);
		}
	}

a++

[alex2746]

Merci pour votre aide, donc si ma classe contient des attributs qui sont uniquement des String, des int, des char et des double, je peux me contenter de:

Code :

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

1
2
3
4
5
 
@Override
protected Object clone() throws CloneNotSupportedException {
	return super.clone();
}

?????????

Autre question: en quoi cette méthode utilise le DEEP COPY?

Merci d'avance.

[tchize_]

comme tu n'as que des types primitif, elle n'utilise pas le deep copy. Comme la javadoc le dit, l'implémentation dans Object utilise le "shallow copy". Pour chaque attribut mutable de ton objet, tu devra donc après faire, à la main, une nouvelle instance, comme adiguba te l'a montré avec un date.

[alex2746]

Merci pour la réponse.
Mais si on me demande de faire une méthode clone() en utilisant une deep copy et que ma classe contient que des attributs de type double et string... Je fais quoi?

[LittleBean]

En supprimant l'exception de la déclaration de méthode. En effet cette dernière ne remontera que dans le cas où l'on implémente plus Cloneable. Inutile de se trainer une tel exception. Il est préférable de la cacher :
Code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
	@Override
	public Object clone() {
		try {
			Person cloned = (Person) super.clone();
 
			cloned.birthDay = (Date) cloned.birthDay.clone();
 
			return cloned;
		} catch (CloneNotSupportedException e) {
			// On remonte l'exception englobé dans une RuntimeException,
			// afin d'être quand même averti d'un éventuel problème :
			throw new RuntimeException(e);
		}
	}

Bon je m'incruste mais je comprends pas en quoi ce qu'il y a dessus est une bonne pratique ???

CloneNotSupportedException peut être remonté dans le cas où l'objet n'implémente pas l'interface clonable mais aussi dans le cas où la méthode a été overridé et que l'objet ne devrait pas être cloné.

Dans le deuxième cas ne vaudrait il mieux pas laisser le throws CloneNotSupportedException ??

Merci de m'éclairer

[adiGuba]

CloneNotSupportedException peut être remonté dans le cas où l'objet n'implémente pas l'interface clonable mais aussi dans le cas où la méthode a été overridé et que l'objet ne devrait pas être cloné.

Il n'est pas très correct que le type courant soit cloneable mais qu'un type enfants ne le soit plus. Et si c'était le cas le type fils pourrait utiliser une RuntimeException...


L'idée est d'éviter de se trainer une exception inutile dans 99% des cas, et qui risque d'être ignorée, ce qui pourrait s'avérer bien pire.

a++

[tchize_]

Merci pour la réponse.
Mais si on me demande de faire une méthode clone() en utilisant une deep copy et que ma classe contient que des attributs de type double et string... Je fais quoi?

Rien de particulier, une deep copy dans ce cas là est exactement la même chose qu'un shallow copy. Le clone sera bien entièrement indépendant de son créateur. Pour faire simple, tes attributs n'ayant aucune "profondeur" je vois pas quelle profondeur tu voudrais cloner

[alex2746]

D'accord.
Si Personne ne contenait que des types primitifs et String, je pourrais me contenter de ceci:

Code :

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

1
2
3
4
5
 
@Override
protected Object clone() throws CloneNotSupportedException {
	return super.clone();
}

Ou il vaut mieux faire ceci:

Code :

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

1
2
3
4
5
6
7
 
@Override
protected Object clone() throws CloneNotSupportedException {
	Person cloned = (Person) super.clone();
 
	return cloned;
}

??

Merci d'avance.

[tchize_]

le type casting ne sert à rien.

[alex2746]

Merci

Dernière chose: est ce mieux de mettre la méthode en protégé:

Code :

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

1
2
3
4
5
 
@Override
protected Object clone() throws CloneNotSupportedException {
	return super.clone();
}

Ou en public:

Code :

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

1
2
3
4
5
 
@Override
public Object clone() throws CloneNotSupportedException {
	return super.clone();
}

??

[tchize_]

tout dépend de qui a besoin de cloner ton objet. Mais a priori, en public ce serait quand meme le plus propre

[alex2746]

D'accord

Deux toutes dernières choses:

- pourquoi mettre protected Object clone()...
et non protected Person clone()... ?

- ma classe Person doit obligatoirement impémenter cloneable()?

Merci

[hibour]

La covariance de type de retour d'une méthode est une fonctionnalité valable qu'à partir de java 5, Avant et par principe on ne peut redéfinir une méthode qui a la même signature où on change juste le type de retour:
càd avant java 1.5

Code :

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

1
2
3
4
5
6
7
class A{
public A method();
}
class B extends A{
public B method();
}
//Génère une erreur de compilation

Il est préférable d'utiliser cette fonctionnalité qui va t'éviter de faire des cast inutile..
Enfin OUI il faut implémenter Cloneable sinon on aura une CloneNotSupportedException quand tu va appeler Person.clone()

[dingoth]

Oui, ta classe doit impérativement implémenter Cloneable. Sans quoi tu auras à coup sûr une CloneNotSupportedOperation.

La méthode clone() est protected dans Object afin d'avoir une implémentation par défaut invisible à l'extérieur. Tu peux la rendre accessible en la marquant public lorsque tu implémentes clone();

Je te conseille vraiment de prendre la méthode telle qu'Adiguba l'a écrite, bien que je remplacerais "throw new RuntimeException" par "throw new UnsupportedOperationException", mais bon, les goûts et les couleurs...

[adiGuba]

bien que je remplacerais "throw new RuntimeException" par "throw new UnsupportedOperationException", mais bon, les goûts et les couleurs...

Ca c'est juste un détail puisque cette exception ne devrait jamais remonter !
L'important étant de bien remonter une exception "au cas où", afin de détecter immédiatement une éventuelle erreur de développement...

a++

[hibour]

Je te conseille vraiment de prendre la méthode telle qu'Adiguba l'a écrite, bien que je remplacerais "throw new RuntimeException" par "throw new UnsupportedOperationException", mais bon, les goûts et les couleurs...

Moi je suis d'accord avec adiGuba pour l'exception RuntimeException qui va encapsuler l'exception non runtime juste pour éviter d'avoir des try catch inutiles en appelant clone()
UnsupportedOperationException va induire l'utilisateur à l'erreur en croyant qu'on ne peut appeler clone() alors qui a eu peut être une erreur interne c'est tout!

[dingoth]

Comme je le disais, les goûts et les couleurs... La réponse d'adiguba suffisait amplement, mais tu désires que j'argumente donc


Petit exercice de comparaison de String :

• CloneNotSupportedException
• UnsupportedOperationException

Indice, cela se trouve en gras

Le choix qu'on a entre RuntimeException et UnsupportedOperationException est plus sémantique qu'autre chose : préfère-t-on lancer une IOException ou une Exception ? Je suis partisan de l'IOException, d'autres en ont rien à faire et lancent une Exception. C'est pareil ici, sauf qu'elle ne sera a priori jamais lancée.

À y réfléchir, ne serait-il pas plus correct de lancer une Error dans ce cas ?