instanceof ou mauvais polymorphisme ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

31/07/2007, 13h41
bulbo

Citation:

Envoyé par Djakisback

Je vais réfléchir à ce que je vais faire (et peut-être tester les 2 soluces en termes de vitesse, ca ajoute quand même quelques pointeurs pour chaque instance d'objet, je suis pas un rapace mais bon :D), merci encore ^^

Si tu peux sans tests (par design) maintenir des listes differentes, il est probable que cette methode soit plus rapide vu que tu fais un appel direct pour faire le calcul.
Au niveau design c'est moins sexy mais pourquoi pas si ca fait ce qu'on lui demande.

Qu'entends tu par "ca ajoute quand même quelques pointeurs pour chaque instance d'objet" ??
Le code des differentes classes sera plus volumineux mais ca ne vas en aucun cas augmenter la taille des instances.

Bulbo ;)
31/07/2007, 13h55
Djakisback

Je pensais aux pointeurs sur fonction (méthode) qui doivent sans doute être stockés dans chaque instance (comme dans les autres langages), enfin c'est possible que je me plante.
31/07/2007, 13h58
bulbo

Citation:

Envoyé par Djakisback

Je pensais aux pointeurs sur fonction (méthode) qui doivent sans doute être stockés dans chaque instance (comme dans les autres langages), enfin c'est possible que je me plante.

Les pointeurs de fonctions sont au niveau de la classe (dans tout les langages que je connais en tout cas).

Le design est particulier a java car la resolution de la signature de la methode est faite a la compilation, c'est pourquoi chaque sous-classe doit implementer la methode collideWith(solid aSolid), sinon ce sera celle de Solid et non de la sous-classe qui sera appelee et ca ne fera pas ce que l'on veut.

Voilou,

Bulbo ;)
31/07/2007, 14h03
Djakisback

Oui, effectivement ce serait stupide de stocker ca dans chaque instance je sais pas où je suis aller chercher ca :D

c un peu hors sujet mais en réflechissant je vois pas trop d'autre methode que de stocker les pointeurs dans les instances. Gérer ca au niveau de la classe ca me semble possible en interprété mais pas trop en compilé. si kkun a plus d'infos ^^ (ou un bon vieu tutout)
01/08/2007, 09h44
bulbo

Citation:

Envoyé par Djakisback

c un peu hors sujet mais en réflechissant je vois pas trop d'autre methode que de stocker les pointeurs dans les instances. Gérer ca au niveau de la classe ca me semble possible en interprété mais pas trop en compilé. si kkun a plus d'infos ^^ (ou un bon vieu tutout)

L'instance a un pointeur sur le descripteur de sa classe.

La classe a une table de ses methodes. 2 indirections et hop on peut appeler une methode sur l'instance.

Apres suivant les langages tu as differentes approches pour ce qui est mis dans la table des methodes et comment on accede a une methode de la super classe mais en gros c'est le principe.
Je ne connais pas exactement l'approche de java pour ca.

Les champs (non static) sont presents dans l'instance mais pourquoi voudrais-tu y mettre les methodes, elles sont propres a la classe et non a l'instance. 2 objets de meme type appelle la meme methode et n'ont pas une version specialisee juste pour eux.

[Edit]
Si ce genre de questions fondamentales te tracassent tu as les specs de la machine virtuelle disponible chez Sun ainsi que pas mal de documents techniques decrivant la gestion de la memoire en java et ce genre de choses.

Ici par exemple: http://java.sun.com/docs/books/jvms/
[/Edit]

Bulbo ;)
01/08/2007, 13h11
Djakisback

Ah c'est donc comme ca que ca marche. J'avais pas pensé aux 2 indirections, donc rien à voir avec un langage compilé ou interprété.
Je vais aller jeter un coup d'oeil au site, merci pour les infos :)

Citation:
Envoyé par bulbo
Pourquoi ne pas essayer une approche du type Visitor comme mentionne plus haut ?
Ca parait la solution adequate, exemple avec du code:
Code:

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 public abstract class Solid { private String _name; /** Creates a new instance of Solid */ public Solid(String aName) { _name = aName; } public abstract boolean collideWith(Solid aSolid); public boolean collideWith(SolidCircle aSolid) { return false; } public boolean collideWith(SolidRectangle aSolid) { return false; } public String toString() { return _name; } public static void main(String args[]) { try { Solid a = new SolidCircle("A"); Solid b = new SolidRectangle("B"); a.collideWith(b); b.collideWith(a); b.collideWith(b); } catch (Exception e) { e.printStackTrace(); } } }
Bulbo ;)
Bonjour, je suis tombé sur ce post qui m'interesse pour un probleme similaire, je vais voir comment l'adapter à mon code. Cependant, une chose me turlupine:
- Est ce convenable d'un point de vue objet qu'une classe connaisse l'existence des ces sous classe, ici SolidCircle et SolidRectangle?
- De plus, quelle est l'utilité de ces deux methodes collideWith qui retourne "false" sachant qu'elles sont surchargés dans les sous classes de Solid?

Guams

24/10/2007, 10h19
bulbo

Citation:

Envoyé par guams

Bonjour, je suis tombé sur ce post qui m'interesse pour un probleme similaire, je vais voir comment l'adapter à mon code. Cependant, une chose me turlupine:
- Est ce convenable d'un point de vue objet qu'une classe connaisse l'existence des ces sous classe, ici SolidCircle et SolidRectangle?
- De plus, quelle est l'utilité de ces deux methodes collideWith qui retourne "false" sachant qu'elles sont surchargés dans les sous classes de Solid?

Guams

D'un point de vue objet je dirais qu'une classe qui doit connaitre ses sous-classes, c'est pas la joie niveau design, mais d'un point de vue java on a pas trop le choix, vue que la résolution de la signature de la méthode est faite lors de la compil, si ces méthodes ne sont pas présentes, le compilo choisira la méthode utilisant la classe mère et après ça on peut oublier la liaison dynamique ..
C'est pourquoi l'implémentation du pattern visitor est si merdique en java.

Bah l'utilité des 2 méthodes c'est juste d'exister dans la classe mère. Ainsi comme dit plus haut le compilo résout la bonne signature et a l'exécution la liaison dynamique fait le reste.
Elles retournent false car c'est le comportement par défaut dans ce cas, c'est tout.

Bulbo ;)
24/10/2007, 11h26
guams

Apres execution du code avec ou sans ses deux methodes et un joli StackOverflowError dans le deuxieme cas, j'ai compris l'utilité de ces deux methodes, merci! ;)

Citation:

Envoyé par bulbo

D'un point de vue objet je dirais qu'une classe qui doit connaitre ses sous-classes, c'est pas la joie niveau design, mais d'un point de vue java on a pas trop le choix, vue que la résolution de la signature de la méthode est faite lors de la compil, si ces méthodes ne sont pas présentes, le compilo choisira la méthode utilisant la classe mère et après ça on peut oublier la liaison dynamique ..
C'est pourquoi l'implémentation du pattern visitor est si merdique en java.

Encore moi, je me triture les meninges et me fais des noeuds au cerveau avec cette histoire de visiteur... apres diverses lectures, j'ai l'impression que le code que tu proposes n'implemente pas le pattern visitor puisqu'il n'y a pas de classe specifique visitor, je me trompe?

Avec une classe visitor et deux sous classes CircleVisitor et RectangleVisitor, on pourrait justement resoudre ce probleme de classe mere qui appelle des methodes avec des arguments de type de ces classes filles, non?

Je m'y perd un peu et je vois meme pas vraiment comment implementer cette solution, il faudrait que j'arrive à lever le brouillard qui s'est abattu sur mon cerveau... :aie:
24/10/2007, 15h05
bulbo

Si tu relis ce que j'avais proposé, il s'agissait d'une solution basée sur le Visitor ..

Alors c'est sur si tu essayes de matcher ça a la lettre sur le pattern, ça va te faire bizarre.

Le fait d'avoir un RectangleVisitor et CircleVisitor ne va rien simplifier, tu vas devoir doubler les classes a maintenir, il est sur que ta classe solide ne connaitras plus ses sous classes ,yeeppee.. enfin maintenant c'est ton SolidVisitor qui doit les connaitre. Je ne vois aucun gain dans tout ça..

Bulbo ;)
24/10/2007, 15h24
guams

Ca, c'est clair que ca simplifie pas l'affaire, j'ai generalement tendance à m'enfermer (à torts ou à raison) dans certains preceptes de la POO, ce qui me complique parfois la tache...
Mais je sais quand j'ai pas trop de temps pondre du code tout pourri sans me poser de question existentielle! :lol:

J'ai tout de meme une question subsidiaire:
Dans quel cas est il donc bon/mieux d'utiliser le VRAI pattern visitor, puisque ta solution semble le simplifier tout en gardant ses avantages?
24/10/2007, 15h44
bulbo

Citation:

Envoyé par guams

J'ai tout de meme une question subsidiaire:
Dans quel cas est il donc bon/mieux d'utiliser le VRAI pattern visitor, puisque ta solution semble le simplifier tout en gardant ses avantages?

La faut regarder la théorie sur le pattern, moi je sais que les patterns j'utilise pas trop, le visitor je connais car une fois j'ai proposé une soluce avoisinante et je me suis fait incendié car je n'implémentais pas a la lettre et aussi j'ai lu un article (merci la recap sur le blog java) d'un gars qui présente les patterns qu'il hait/aime..

Tient c'est ici pour la lecture: http://tech.puredanger.com/2007/07/16/visitor/

[Edit]
En fait ma solution n'est pas un visitor mais uniquement la seule technique possible pour utiliser la liaison dynamique dans ce genre de cas en java.
Disons que mentionner le visitor aide a faire accepter la chose :aie:
[/Edit]

Bulbo ;)

Merci pour le lien, c'est tres instructif et j'en ai profité pour lire le lien sur le double dispatch dont je me suis inspiré pour adapter ton code en utilisant une interface:

Code:

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
 
abstract class Solid
{
 
  private String _name;
 
  /** Creates a new instance of Solid */
  public Solid(String aName)
  {
    _name = aName;
  }
 
  public String toString()
  {
    return _name;
  }
 
  public static void main(String args[])
  {
    try
    {
      Collidable a = new SolidCircle("A");
      Collidable b = new SolidRectangle("B");
 
      a.collideWith(b);
      b.collideWith(a);
      b.collideWith(b);
    }
    catch (Exception e)
    {
      e.printStackTrace();
    }
  }
}

Code:

1
2
3
4
5
6
7
8
9
 
interface Collidable
{
   boolean collideWith(Collidable aSolid);
 
  boolean collideWithSolidCircle(SolidCircle aSolid);
 
  boolean collideWithSolidRectangle(SolidRectangle aSolidRectangle);
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
class SolidCircle extends Solid implements Collidable
{
  /** Creates a new instance of SolidCircle */
  public SolidCircle(String aName)
  {
    super(aName);
  }
 
  public boolean collideWith(Collidable aSolid)
  {
    return aSolid.collideWithSolidCircle(this);
  }
 
  public boolean collideWithSolidCircle(SolidCircle aSolid)
  {
    return PEngine.computeCircleCircleCollision(this, aSolid);
  }
 
  public boolean collideWithSolidRectangle(SolidRectangle aSolidRectangle)
  {
    return PEngine.computeCircleRectangleCollision(this, aSolidRectangle);
  }
}

Code:

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
 
class SolidRectangle extends Solid implements Collidable
{
 
  /** Creates a new instance of SolidRectangle */
  public SolidRectangle(String aName)
  {
    super(aName);
  }
 
  public boolean collideWith(Collidable aSolid)
  {
    return aSolid.collideWithSolidRectangle(this);
  }
 
  public boolean collideWithSolidCircle(SolidCircle aSolidCircle)
  {
    return PEngine.computeCircleRectangleCollision(aSolidCircle, this);
  }
 
  public boolean collideWithSolidRectangle(SolidRectangle aSolidRectangle)
  {
    return PEngine.computeRectangleRectangleCollision(this, aSolidRectangle);
  }
}

La classe PEngine restant inchangée.

Bon, je suis pas sur que Collidable existe en anglais, mais ca permet d'avoir une interface qui gere les collisions qui me permet de ne pas franchir cette barriere psychologique qui a la peau dure!

Vois tu des contre indications à un tel code?

24/10/2007, 17h20
bulbo

J'en vois une..

Si tu veux ajouter un triangle tu dois recoder ton interface et toute tes classes même celles qui ne collideront (moi aussi je me met au neologisme :aie:) jamais avec un triangle..

Et tu ne peux pas avoir d'implémentation par défaut pour les méthodes qui ne t'intéressent pas.

Si tu as 10 formes différentes, tu dois a chaque fois écrire 10 implémentations différentes.

Bulbo ;)
24/10/2007, 17h32
guams

Les memes defauts qu'avec le pattern visitor, donc :mrgreen:

Mais je ne peux de toute maniere pas implementer cette solution vu que je dois effectuer un traitement sur un tableau de Solid (pour rester sur cette exemple) qui possede dans mon cas 8 classes filles et ma classe "Solid" est deja suffisamment chargée, ca m'embete vraiment d'y rajouter encore 8 methodes, d'autant que je risque de me faire taper dessus par la qualiticienne :sm:
24/10/2007, 17h36
bulbo

Citation:

Envoyé par guams

Les memes defauts qu'avec le pattern visitor, donc :mrgreen:

Mais je ne peux de toute maniere pas implementer cette solution vu que je dois effectuer un traitement sur un tableau de Solid (pour rester sur cette exemple) qui possede dans mon cas 8 classes filles et ma classe "Solid" est deja suffisamment chargée, ca m'embete vraiment d'y rajouter encore 8 methodes, d'autant que je risque de me faire taper dessus par la qualiticienne :sm:

C'est ça ou faire des tests a la con avec une implémentation et une maintenance beaucoup moins propre.

Le seul design objet permit dans ce cas est celui proposé. Tout solution a base d'instanceof ou de test équivalent sur le nom de la classe ou que sais-je encore serait juste de la bidouille pour ne pas utiliser la liaison dynamique .. sans compter que les performances seraient aussi moins bonne bien évidemment ...

C'est quoi le but de la qualiticienne ? Compter le nombre de méthodes, de lignes par méthode, de return par méthode et casser les pieds au gens ?

Bulbo ;)
24/10/2007, 17h42
guams

Citation:

Envoyé par bulbo

C'est ça ou faire des tests a la con avec une implémentation et une maintenance beaucoup moins propre.

Le seul design objet permit dans ce cas est celui proposé. Tout solution a base d'instanceof ou de test équivalent sur le nom de la classe ou que sais-je encore serait juste de la bidouille pour ne pas utiliser la liaison dynamique .. sans compter que les performances seraient aussi moins bonne bien évidemment ...

C'est quoi le but de la qualiticienne ? Compter le nombre de méthodes, de lignes par méthode, de return par méthode et casser les pieds au gens ?

Bulbo ;)

C'est une qualiticienne, donc oui! :mrgreen:

Mais ca doit pouvoir se gerer...
24/10/2007, 19h09
deltree

Citation:

Envoyé par guams

Les memes defauts qu'avec le pattern visitor, donc :mrgreen:

mmm oui, tout à fait, vu que la surcharge permet finalement de faire des méthodes différente mais simplement de même nom, tu met en valeur le faire que la surcharge n'est pas le polymorphisme. (ça m'a demandé une grosse réflexion quand même pour suivre le cheminement d'exécution :D )

N'importe comment qu'on retourne ce pattern, c'est un système où tout le monde connait tout le monde, donc pas génial niveau maintenance.

Il ne faut donc l'appliquer que si vraiment on ne trouve pas d'interface à partager avec une factory classique:
je m'explique, dans le cas présent, j'aurais essayé de faire une interface "Shape" qui renvoie la "forme" du dessin sous forme soit d'une liste de pixel pour faire une intersection, soit d'argument polynomiaux du 2nd ordre (qui permet de faire des cercles. .. droites) pour calculer les intersection des contours.
bref en adaptant l'algorithme au fonctionnel.
24/10/2007, 19h52
guams

Citation:

Envoyé par deltree

mmm oui, tout à fait, vu que la surcharge permet finalement de faire des méthodes différente mais simplement de même nom, tu met en valeur le faire que la surcharge n'est pas le polymorphisme. (ça m'a demandé une grosse réflexion quand même pour suivre le cheminement d'exécution :D )

N'importe comment qu'on retourne ce pattern, c'est un système où tout le monde connait tout le monde, donc pas génial niveau maintenance.

En fait je crois pas, dans le veritable pattern visitor c'est le visitor qui connait tout le monde, les autres ne se connaissent pas.
Dans le cas present, tout le monde se connait puisque le but est d'avoir des operations specifiques entre deux objets de types particuliers, je ne vois pas trop comment remedier à ca, ta solution peut etre une piste.

Pour mon cas particulier, je crois que le pattern visitor "classique" sera beaucoup plus propre que toutes les solutions proposées ici, sachant que ma hierarchie d'objet ne devrait pas bouger (ou tres rarement).

Oui, enfin il faut que tes objets connaissent le Visitor de base (la superClasse ou l'interface).

Le "vrai" pattern Visitor a une autre utilité, c'est de pouvoir ajouter d'autres comportements que le collide sans modifier les objets "Visités": en créant une classe par comportement ajouté...

Là ça ne s'adapterait pas bien au cas présent, qui demande une interraction entre 2 objets Visités:

Sur la méthode "visit()" il faudrait donc passer en paramètre les 2 objets visités? ça ne se fait pas si simplement que ça...
explications:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 interface Visitor { .... } interface Visitable { void accept(Visitor visitor, ??); } //tous les Solid implémentent Visitable Class CollideVisitor implements Visitor { void visit(SolidCircle solid1, SolidCircle solid2); void visit(SolidCircle solid1, SolidRectangle solid2); void visit(SolidRectangle solid1, SolidRectangle solid2); }
Comment faire pour que le Visitor se fasse inviter par 2 Visitable?
La solution déjà donnée et qui revient à un Visitor-Visité (dans la même classe :D ) est quand même la plus simple pour cette problématique.

Voir 40 message(s) de cette discussion en une page