IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage Java Discussion :

instanceof ou mauvais polymorphisme ? [Débat]


Sujet :

Langage Java

  1. #21
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Février 2004
    Messages : 1 259
    Points : 1 937
    Points
    1 937
    Par défaut
    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 ), 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
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  2. #22
    Membre émérite Avatar de Djakisback
    Profil pro
    Inscrit en
    Février 2005
    Messages
    2 021
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 2 021
    Points : 2 278
    Points
    2 278
    Par défaut
    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.
    Vive les roues en pierre

  3. #23
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Février 2004
    Messages : 1 259
    Points : 1 937
    Points
    1 937
    Par défaut
    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
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  4. #24
    Membre émérite Avatar de Djakisback
    Profil pro
    Inscrit en
    Février 2005
    Messages
    2 021
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 2 021
    Points : 2 278
    Points
    2 278
    Par défaut
    Oui, effectivement ce serait stupide de stocker ca dans chaque instance je sais pas où je suis aller chercher ca

    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)
    Vive les roues en pierre

  5. #25
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Février 2004
    Messages : 1 259
    Points : 1 937
    Points
    1 937
    Par défaut
    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
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  6. #26
    Membre émérite Avatar de Djakisback
    Profil pro
    Inscrit en
    Février 2005
    Messages
    2 021
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 2 021
    Points : 2 278
    Points
    2 278
    Par défaut
    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
    Vive les roues en pierre

  7. #27
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 33
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par bulbo Voir le message
    Pourquoi ne pas essayer une approche du type Visitor comme mentionne plus haut ?
    Ca parait la solution adequate, exemple avec du 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
    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

  8. #28
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Février 2004
    Messages : 1 259
    Points : 1 937
    Points
    1 937
    Par défaut
    Citation Envoyé par guams Voir le message
    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
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  9. #29
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 33
    Points : 27
    Points
    27
    Par défaut
    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 Voir le message
    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...

  10. #30
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Février 2004
    Messages : 1 259
    Points : 1 937
    Points
    1 937
    Par défaut
    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
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  11. #31
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 33
    Points : 27
    Points
    27
    Par défaut
    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!

    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?

  12. #32
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Février 2004
    Messages : 1 259
    Points : 1 937
    Points
    1 937
    Par défaut
    Citation Envoyé par guams Voir le message
    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
    [/Edit]

    Bulbo
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  13. #33
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 33
    Points : 27
    Points
    27
    Par défaut
    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 : 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
     
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    interface Collidable
    {
       boolean collideWith(Collidable aSolid);
     
      boolean collideWithSolidCircle(SolidCircle aSolid);
     
      boolean collideWithSolidRectangle(SolidRectangle aSolidRectangle);
    }
    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
     
    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 : 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
     
    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?

  14. #34
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Février 2004
    Messages : 1 259
    Points : 1 937
    Points
    1 937
    Par défaut
    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 ) 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
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  15. #35
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 33
    Points : 27
    Points
    27
    Par défaut
    Les memes defauts qu'avec le pattern visitor, donc

    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

  16. #36
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Février 2004
    Messages : 1 259
    Points : 1 937
    Points
    1 937
    Par défaut
    Citation Envoyé par guams Voir le message
    Les memes defauts qu'avec le pattern visitor, donc

    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
    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
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  17. #37
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 33
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par bulbo Voir le message
    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!

    Mais ca doit pouvoir se gerer...

  18. #38
    Membre confirmé
    Inscrit en
    Mai 2007
    Messages
    335
    Détails du profil
    Informations forums :
    Inscription : Mai 2007
    Messages : 335
    Points : 511
    Points
    511
    Par défaut
    Citation Envoyé par guams Voir le message
    Les memes defauts qu'avec le pattern visitor, donc
    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 )

    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.

  19. #39
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 33
    Points : 27
    Points
    27
    Par défaut
    Citation Envoyé par deltree Voir le message
    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 )

    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).

  20. #40
    Membre confirmé
    Inscrit en
    Mai 2007
    Messages
    335
    Détails du profil
    Informations forums :
    Inscription : Mai 2007
    Messages : 335
    Points : 511
    Points
    511
    Par défaut
    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 : 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
     
    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 ) est quand même la plus simple pour cette problématique.

Discussions similaires

  1. instanceof c'est mauvais?
    Par pongping dans le forum Langage
    Réponses: 33
    Dernier message: 20/05/2007, 20h39
  2. Mauvais indicateur de connection
    Par calvin dans le forum Hibernate
    Réponses: 15
    Dernier message: 24/05/2004, 13h03
  3. [Tomcat][JSP] Mauvais fonctionnement
    Par gandalf_le_blanc dans le forum Tomcat et TomEE
    Réponses: 47
    Dernier message: 26/04/2004, 14h07
  4. Mauvais noms de colonnes lors d'une requête
    Par nmathon dans le forum Bases de données
    Réponses: 2
    Dernier message: 09/04/2004, 08h27
  5. mauvais code
    Par moumou dans le forum Autres SGBD
    Réponses: 3
    Dernier message: 17/04/2003, 16h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo