Design pattern Visitor : oui ou non ?

Il y a quelques mois j’ai publié un billet sur le Filter Pattern qui permet de filtrer un arbre d’objets facilement. Une autre manière de faire est évidemment d’utiliser le design pattern Visitor.

Avantages du Filter Pattern

      Les classes existantes ne sont pas modifiées. Le pattern permet de traverser un arbre sans pour autant que les noeuds de notre arbre implémentent une interface particulière. Il est donc possible d’appliquer ce pattern dans une application déjà existante ou sur des objets d’un framework tiers.
      Créer un nouveau filtre est très simple puisqu’il suffit de définir une nouvelle méthode passes()
      Imbriquer des filtres est très facile
      Seul la logique du filtre est porté par la classe filtre, le reste de l’algorithme de traitement est laissé à la classe appelante. Un même filtre peut donc être appelé plusieurs fois pour des traitements diverses.

Avantages du pattern Visitor

Afin de préparer ce billet, j’ai créé des exemples dans eclipse et… j’ai vraiment du mal à trouver les points positifs à ce pattern. Tout n’est pas mauvais bien sur, il fait énormément de chose mais je vois surtout des points négatifs :

RobertDiFalco a écrit un article très intéressant (en anglais) sur le design pattern Hierarchical Visitor Pattern qui est un amélioration du design pattern Visitor.

      Les noeuds de l’arbre doivent tous implémenter une méthode accept(Visitor v). Cela implique que les classes sont porteuses de la logique de parcours de l’arbre puisque c’est elles qui doivent itérer sur leur fils pour propager le visiteur dans les noeuds enfants.

      Les avantages sont surtout qu’il n’y a pas besoin de modifier les classes pour appliquer un filtre sur notre arbre.

    Le commentaires sont fermés.