Discussion :

[BRAUKRIS]

Juste pour info :

A quoi servent les Interfaces de marquage?
Si possible, me donner es exemples concret d'utilisation.

Merci.

[thibaut]

Ces interfaces ne servent à rien , mais juste pour préciser qu'un object rentre dans certaines conditions.
Dans le cas de la sérialization des objets, la classe ObjectOutputStream...

Code :

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

1
2
3
4
if (altobj != null && ! (altobj instanceof Serializable)) {
  String clname = altobj.getClass().getName();
  throw new NotSerializableException(clname);
}

[bouye]

Regle generale : une interface sert principalement a definir un type auquel on peut optionnellement attacher des signatures de methodes ou des constantes. Une interface ne definie pas un comportement, en effet il n'est pas possible de mettre du code dans une interface.

Pour definir un comportement generique, il faut utiliser une classe abstraites.

=> la methode clone() peut etre uniquement appelee sur des objets de type Cloneable. La serialisation peut uniquement s'effectuer sur des objets de type Serializable.

[mysteriousFreak]

=> la methode clone() peut etre uniquement appelee sur des objets de type Cloneable. La serialisation peut uniquement s'effectuer sur des objets de type Serializable.

Petite question au sujet de clone():

pourquoi peut-on définir une methode clone() du genre:

Code :

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

1
2
public Object clone() throws CloneNotSupportedException
{...}

...Et si c'est pas bien, pourquoi?...

[adiGuba]

Salut,

pourquoi peut-on définir une methode clone() du genre:

Code :

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

1
2
public Object clone() throws CloneNotSupportedException
{...}

Pourquoi ne pourrait-on pas définir une tel méthode ???

...Et si c'est pas bien, pourquoi?...

Pourquoi cela ne serait-il pas bien ???



Un peu plus de détail sur ta question serait peut-être utilise...

a++

[mysteriousFreak]

Pourquoi ne pourrait-on pas définir une tel méthode ???

...Je voulais dire sans implémenter l'interface Cloneable

Bon, ok, on peut définir une methode quelconque, là-dessus OK, mais en fait il me semblait que normalement on ne définissait cette methode qu'en implémentant l'interface Cloneable... du moins pour faire des choses propres, d'autant que d'apres la Javadoc:
"Invoking Object's clone method on an instance that does not implement the Cloneable interface results in the exception CloneNotSupportedException being thrown."

J'ai vu ce genre de trucs (clone() sans Cloneable), ça semble marcher, mais je trouve ça un peu étrange vu la Javadoc...

Pourquoi cela ne serait-il pas bien ???

Je voulais dire sans l'interface Cloneable, c'est pas très propre il me semble... non?...

PS: t'as raison, c'était quand meme pas très clair ma question, désolé, j'éspère que c'est mieux cette fois-ci

[adiGuba]

Oui tu peux très bien faire une méthode clone() qui renvoi une copie de ton objet. Seulement tu devras créer ton même cette objet, par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class MyObject {
	private int attrib1;
	private int attrib2;
	private int attrib3;
	private int attrib4;
 
	public MyObject(int attrib1, int attrib2, int attrib3, int attrib4) {
		this.attrib1 = attrib1;
		this.attrib2 = attrib2;
		this.attrib3 = attrib3;
		this.attrib4 = attrib4;
	}
 
	public Object clone() {
		return new MyObject(this.attrib1, this.attrib2, this.attrib3, this.attrib4);
	}
}

L'interface Cloneable te permet d'utiliser la méthode super.clone() à la place, et ainsi simplifier un peu la tâche (en particulier pour des classes complexes) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class MyCloneableObject implements Cloneable {
	private int attrib1;
	private int attrib2;
	private int attrib3;
	private int attrib4;
 
	public MyCloneableObject(int attrib1, int attrib2, int attrib3, int attrib4) {
		this.attrib1 = attrib1;
		this.attrib2 = attrib2;
		this.attrib3 = attrib3;
		this.attrib4 = attrib4;
	}
 
	@Override
	public Object clone() throws CloneNotSupportedException {
		return super.clone();
	}
}

La méthode super.clone() effectue automatiquement une copie des valeurs des attributs primitifs, et une copie des références des objets, en plus de créer la nouvelle instance en mémoire (sans passer par le constructeur).

Pour cela la méthode super.clone() vérifie que la classe implémente Cloneable. Si ce n'est pas le cas une CloneNotSupportedException est remonté (et seulement dans ce cas d'ailleurs).

Au passage, tu peux supprimer cette exception dans ta classe en la traitant, et avec Java 5.0 tu peux même changer le type de retour pour qu'il corresponde à ta classe (lire la FAQ : Quelles sont les règles à respecter pour redéfinir/implémenter une méthode ?), ce qui donnerait :

Code :

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

1
2
3
4
5
6
7
8
	public MyCloneableObject clone() {
		try {
			return (MyCloneableObject) super.clone();
		} catch (CloneNotSupportedException e) {
			// Logiquement, ceci ne devrait pas arriver ici :
			throw new RuntimeException(e);
		}
	}

a++

[professeur shadoko]

Certaines interfaces de marquages sont un pis-aller dans l'attente de l'apparition des annotations (c'est à dire dans le cadre pre 1.5).
En effet elles peuvent être utilisées en fait comme meta-annotation.
Je trouve (mais c'est une opinion très perso) que Serializable entre dans cette catégorie ... avec quelques inconvénients du type: une sous-classe d'une classe Serializable est-elle automatiquement Serializable? (alors que ça pourrait sérieusement se discuter).
mon impression: il faut tourner son clavier 7 fois entre ses mains avant de définir une interface marqueur (mais dans certains cas ça s'impose).