Design pattern visitor - Page 1

Non mais serieux c'est quoi cette merde la, une dependence cyclique dans un pattern pfffffffffff.

accept(this)

T'as un problème psychologique avec les cycles ?

tu comptes poster un cdg chaque fois que tu n'es pas d'accord avec une méthode de conception universellement utilisée, ou ça va te lasser au bout d'un moment ?

Non mais c'est bien de philosopher un peu

une méthode de conception universellement utilisée
-> Non le design pattern Visitor et l'un des moins utilisé.
-> Si tu reflechis pas sur ce que tu utilises, tu ne te poses pas de question et tu ne fais pas evoluer les choses. On doit certainement pouvoir casser la dependance circulaire avec un peu de reflection (j'ai pas trouvé mieux qu une solution a base de down cast, ce qui n'est pas forcement mieux). je trouve scandaleux qu'il soit présenté telquel...

Ça n'était qu'à moitié sérieux, ça ne peut pas faire de mal de remettre un DP en cause. Ceci dit, Visitor est quand même quelque chose de très connu et très utilisé (même si c'est "l'un des moins utilisés", ce dont je doute d'ailleurs) et ça aurait pu être une bonne idée d'expliquer par exemple ce que tu lui reproches vraiment plutôt que de jeter trois mots sans justification

Non justement dans la littérature j'ai vu qu'il était justement défini en leftover... et très peu utilisé. En même temps on comprend pourquoi...

Le problème je l'ai dit plus haut. J'ai une dépendance cyclique et ça me gonfle vraiment :/

une fois j'ai essayé d'utiliser ce "bidule" pour générer un document xml... J'ai pas trouvé comment on pouvait... c'est moi le bouché ou le pattern?

la seule (et derniere) fois ou j'en ai entendu parle c'etait en compilation ou le prof disait que c'etait un super truc a connaitre et tout
la preuve, depuis j'ai jamais trouve de cas justifiant son utilisation, ni entendu quelconque mention de cette technique

même en compil, faut être tordu pour y penser

Bah, c'est juste une manière compliquée d'écrire ça:

class Foo : QObject {
  Q_OBJECT
};
class Bar : QObject {
  Q_OBJECT
};
class /* fake */ Visitor {
  void foo(QObject *toto) {
    if (toto->inherits("Foo"))
      visit(static_cast<Foo *>(toto));
    else if (toto->inherits("Bar"))
      visit(static_cast<Bar *>(toto));
    else
      qFatal("invalid parameter to foo");
  }
  void visit(Foo *);
  void visit(Bar *);
};

Ça donne ça:

class Foo;
class Bar;
class AbstractVisitor {
  virtual void visit(Foo *) = 0;
  virtual void visit(Bar *) = 0;
}
class Object {
  virtual void accept(AbstractVisitor *) = 0;
};
class Foo : Object {
  virtual void accept(AbstractVisitor *v) {v->visit(this);}
};
class Bar : Object {
  virtual void accept(AbstractVisitor *v) {v->visit(this);}
};
class Visitor : AbstractVisitor {
  void foo(Object *toto) {
    toto->accept(this);
  }
  virtual void visit(Foo *);
  virtual void visit(Bar *);
};

et c'est bien plus joli ^^ (c'est pas parfait, pas pr des histoires de "dépendance cyclique" juste de structuration de code, mais ça reste bien pratique parfois)

Non mais c'est pas parce qu'on a une forward declaration que ya pas de dépendance cyclique hein.
Perso j'utilise la forward declaration pour casser les dépendances de compilation (ie. eviter de propager une dépendance engendrant la recompilation de beaucoup de chose.). Ceci est très pratique et permet de gagner du temps à la compilation (crucial pour faire de l'intégration continue).

Je dirais même que l'impossibilité d'implémenter ça sans forward declaration démontre qu'il y a une dépendance cyclique.