Discussion :

[Gargamail]

Bonjour les gens,

je vais poser une question qui a sans doute déjà été discutée, mais je n'arrive pas à trouver les bons mots-clefs pour faire ma recherche.

Je voudrais votre avis sur l'utilisation des Generics pour /typer/ des objets. Je m'explique. J'ai des méthodes qui utilisent des objets de même classe mais qui n'ont rien à voir. Je veux éviter d'utiliser un objet pour un autre, et cela, en leur donnant un type différent. Par exemple, j'ai deux objets de classe A, je voudrais les spécifier de classe B extends A pour le premier et C extends A pour le second, de telle manière que je ne puisse plus utiliser l'un à la place de l'autre (impossible d'ajouter des objets C dans une liste de B). En pratique, B et C sont tous les deux la même classe A.

Exemple plus complet : Je souhaite tester la bisimilarité entre deux graphes. Chaque graphe a un ensemble de nœuds, et je veux leur donner un type différent parce qu'à chaque fois que je manipule un nœud, je sais de quel graphe il provient. D'où le bout de code qui suit : je type les graphes par N1 extends Node et N2 extends Node et je ne peux plus confondre un nœud de type N1 avec un nœud de type N2. Ça donne ça :

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
import java.util.*;
 
// Classe permettant de tester la bisimilarite entre deux graphes
public class Bisimil {
 
    public boolean areBisimilar(Graph g1, Graph g2) {
	return new InternalBisim<Node,Node>(g1,g2).bisim();
    }
 
    // Classe interne pour cacher le typage des nodes a un utilisateur externe.
    class InternalBisim<N1 extends Node, N2 extends Node> {
	private TypedGraph<N1> _g1;
	private TypedGraph<N2> _g2;
 
	public InternalBisim(Graph g1, Graph g2) {
            // les noeuds de g1 sont de type N1 et ceux de g2 de type N2
	    _g1 = new TypedGraph<N1>(g1);
	    _g2 = new TypedGraph<N2>(g2);
	}
 
	public boolean bisim() {
	    // Test standard de bisimilarite. 
	    // Puisque les nodes de g1 et les nodes de g2 sont types, 
	    // il est impossible de les confondre.
 
	    return true;
	}
    }
 
}
 
// Typage de graphe : 
// permet de specifier un pseudo-type pour les noeuds de ce graphe.
class TypedGraph<N extends Node> {
    private Graph _g;
 
    TypedGraph(Graph g) {
	_g = g;
    }
 
    @SuppressWarnings("unchecked")
    public Set<N> getNodes() {
	return (Set<N>)_g.getNodes();
    }
 
    @SuppressWarnings("unchecked")
    public Set<N> succ(N n) {
	return (Set<N>)_g.succ(n);
    }
 
    @SuppressWarnings("unchecked")
    public Set<N> init() {
	return (Set<N>)_g.init();
    }
 
    public boolean isInit(N n) {
	return _g.isInit(n);
    }
 
    // etc.
}

D'où mes questions :
1- Pensez-vous que cette technique rende le code plus facile à lire ?
2- Existe-il une autre manière de faire qui ait les mêmes avantages ?

Merci.

[djo.mos]

Bonjour,

1- Pensez-vous que cette technique rende le code plus facile à lire ?

Perso, je ne le pense pas. Au contraire, introduire des types synthétiques qui n'ont pas de sens sémantique ne faciliterait pas la compréhension du code.

2- Existe-il une autre manière de faire qui ait les mêmes avantages ?

Quelques pistes :
1- Ne pas stocker les noeuds des 2 graphes dans une même liste si possible
2- Si 1 n'est pas possible, ajoute un champ à Noeud qui indique à quel graphe ça apartient.
3- Après, c'est ton code, joue sur l'ordre et le nom des arguments et des variables pour faire la distinction entre les 2 ensembles de noeuds.

[Gargamail]

Merci pour ta réponse djo. Malgré tout, je reste moyennement convaincu.

Perso, je ne le pense pas. Au contraire, introduire des types synthétiques qui n'ont pas de sens sémantique ne faciliterait pas la compréhension du code.

Je ne conteste pas que le code puisse être plus difficile à comprendre. Par contre, je pense qu'on peut attribuer une valeur sémantique à ces types artificiels. De la sorte, on indique qu'on a des nœuds qui portent sur des graphes différents et qu'on ne peut donc pas comparer ou échanger de manière triviale.

Quelques pistes :
1- Ne pas stocker les noeuds des 2 graphes dans une même liste si possible

Ça ne répond malheureusement pas à ma question. En effet, la technique que je propose n'est pas censée résoudre ce type de problème : si je stocke des N1 et des N2 dans une liste, alors c'est une liste de Node. Et quand je vais (par exemple) itérer sur la liste, je vais extraire des Node, pas des N1 ou des N2.
(Ceci étant, je me place dans un contexte où j'évite de mettre des nœuds de graphes différents dans la même liste. Brrr, quelle horreur.)

2- Si 1 n'est pas possible, ajoute un champ à Nœud qui indique à quel graphe ça appartient.

Je n'ai pas vraiment ce problème ici puisque 1 n'a pas lieu d'être. Remarque cependant
1- Je me refuse à toucher à la classe Graph : je considère en gros que c'est une librairie externe.
2- Mon but est de réduire la possibilité d'erreur quand je code. Si je dois ajouter des champs et des vérifications pendant l'exécution, non seulement c'est coûteux, mais en plus ça ne résout pas mon problème puisque je ne suis pas plus assuré que mon code est bon.

3- Après, c'est ton code, joue sur l'ordre et le nom des arguments et des variables pour faire la distinction entre les 2 ensembles de nœuds.

Justement, c'est là mon problème. Les algo que je veux utiliser sont des machines à erreurs. Typiquement, je dois faire des doubles boucles sur deux graphes. J'ai donc un itérateur nodeIt1 sur les nœuds de g1 et un itérateur nodeIt2 sur les nœuds de g2, etc. Pour chaque graphe, on définit le même ensemble de variables. À mon avis, c'est mauvais de remplacer les noms des itérateurs par it et autreIterator juste pour qu'on les différencie rapidement ; sans compter que je ne suis pas certain que ça évitera les erreurs.

[Rei Ichido]

Des classes créées juste pour différencier deux objets dans un morceau de code me semble une très mauvaise idée, notamment en terme d'évolution future. De bonnes conventions de nommage de tes variables devraient parfaitement faire l'affaire !