Discussion :

[Warest]

Bonjour,

Je développe une application client/serveur et je me pose la question de la bonne gestion du polymorphisme avec les objets provenant du serveur :

Voici le contexte :

J'ai plusieurs fruits qui implémentent l'interface fruit :

Code :

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

1
2
3
4
5
6
7
8
9
10
public interface Fruit{
 
	float getPoid();
        //...
}
 
public class Orange implements Fruit{
	private float poid;
	//...
}

J'ai un service sur le serveur qui me renvoie un fruit :

Code :

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

1
2
3
public interface Service{
	private Fruit getFruit( ...);
}

J'ai une interface sur le client qui me permet d'afficher un fruit et ses implémentations :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public interface FruitClient{
 
	void afficherLeFruit();
}
 
public class OrangeClient implements FruitClient{
 
	public void afficherLeFruit() {
		// afficher une orange
	}
}

Comment puis-je passer du fruit que j'ai reçu du serveur (et dont je ne connais pas la class exacte) en fruit "affichable"

Les deux solutions qui me viennent à l'esprit sont soit d'utiliser des "instanceof" :

Code :

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

1
2
3
4
5
6
public FruitClient convertFruit(Fruit fruit) {
	Fruit fruit = service.getFruit(...);
	if (fruit instanceof Orange) return new OrangeClient((Orange)fruit);
	else if (fruit instanceof Pomme) return new PommeClient((Pomme)fruit);
	else...
}

soit de mettre des méthodes dans mon interface fruit pour générer les class désirées

Code :

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

1
2
3
4
5
6
public interface Fruit{
 
	float getPoid();
 
	FruitClient generateClientObject();
}

Dans le premier cas, je trouve que ça ne fait vraiment pas propre (on m'a toujours exliqué de limiter les instanceof le plus possible)

Dans le second cas, je suis obligé d'embarquer la logique client sur le serveur ce qui n'est pas terrible non plus.

Tout ça me porte à croire que quelque chose cloche dans ma conception .

Il y a-t-il une manière élégante de résoudre ce problème?

[thelvin]

Hello,

je dirais que la première chose qui cloche, c'est l'ordre dans lequel tu vois les choses.

Quand tu as un objet Fruit qui arrive, d'où vient-il ? Il vient d'un appel à getFruit() de la classe Service, n'est-ce pas ?

Dans ce cas, comment donc peux-tu construire un client adapté à la bonne classe du Fruit, en te basant sur l'objet Fruit en question ?

Après tout, si tu as un objet Fruit qui existe et que tu peux inspecter, c'est que tu l'as obtenu auprès du serveur, après avoir appelé le serveur, ce que tu as fait à l'aide d'un client adapté, n'est-ce pas ? Or, apparemment pour obtenir ce client adapté, tu avais besoin d'un objet Fruit... Celui que tu as obtenu grâce au client que tu es en train d'essayer d'avoir.

Ça se mord la queue. Il faudrait que tu nous démêles tout ça.

[Warest]

Bonjour thelvin et merci pour l'aide.

Je vais tenté d'éclaircir un peu :

Quand tu as un objet Fruit qui arrive, d'où vient-il ? Il vient d'un appel à getFruit() de la classe Service, n'est-ce pas ?

Oui c'est bien ça.

Dans ce cas, comment donc peux-tu construire un client adapté à la bonne classe du Fruit, en te basant sur l'objet Fruit en question ?

C'est bien là tout le problème. Je ne connais pas le type concret du Fruit que je reçois.

Après tout, si tu as un objet Fruit qui existe et que tu peux inspecter, c'est que tu l'as obtenu auprès du serveur, après avoir appelé le serveur, ce que tu as fait à l'aide d'un client adapté, n'est-ce pas

Je pense qu'il y a eu confusion quand j'ai appelé mon interface"fruitClient", je voulais parler de la class fruit dans le soft client, j'aurais plutot du l'appeler fruitDisplay ou quelque chose comme ça.


Il faut imaginer que les fruits contiennent beaucoup de données, sur mon client j'ai donc une liste de "fruit simple" avec juste l'id du fruit et quelques informations essentielles pour l'utilisateur. Si un utilisateur décide d'afficher les détails d'un fruit, j'appelle donc getFruit(idFruit) de la classe Service qui me renvoie le fruit avec toutes ses données. Les données et leur type peuvent être très variables d'un fruit à l'autre. Pour faire tout ça, je n'ai pas besoin de connaître le type réel du fruit, juste que c'est un fruit.


Ce que je voudrais, c'est a partir du fruit que je reçois, le transformer en objet utile pour le soft client, comme par exemple un objet capable d'afficher l'image du fruit ou d'afficher un graphique sur la manière dont il a poussé, et ce graphique contiendra des données différente suivant si c'est une banane ou une orange.

Mais dans mon interface, j'ai juste besoin de savoir que je peux afficher un graphique, je n'ai pas besoin de savoir ce qu'il contient ou à quoi il ressemble. D'où l’intérêt du polymorphisme...

Après avoir creuser sur le net j'ai trouvé le Pattern Visitor qui pourrait correspondre à mon besoin. Ce qui pourrait donner :

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
 
 public interface Fruit{
 
	<T> T accept (FruitVisitor<T> v);
	// ...
}
 
public interface FruitVisitor<T>{
 
	T visit(Orange o);
 
	T visit(Fraise f);
 
	//...
}
 
public interface FruitDisplay{
 
	Chart getChart();
 
	Image getImage();
 
	//...
}
 
public class FruitVisitorDisplay implements FruitVisitor<FruitDisplay>{
 
	@Override
	public FruitDisplay visit(Orange o) {
 
	}
 
	@Override
	public FruitDisplay visit(Fraise f) {
		//
	}
 
}

Penses tu que ce soit une bonne idée? Même si c'est plus long, ça me parait quand même plus propres et plus fiable que les autres solutions évoquées dans mon premier post.