mardi 16 octobre 2012
Pattern Visitor, ne baissons pas les bras
Suite au post très intéressant de Xavier Nopre sur le Single Responsibility Principle et son approche beans+services, Nicolas Capponi a animé une séance du dojo du club agile pour explorer différents solutions qui s'offrent à nous pour ce problème.
Personnellement j'ai choisi d'utiliser le temps pour m'affuter en Visitor, car comme dis Xavier ce n'est pas le pattern le plus facile. D'autres personnes ont essayé d'autres solutions.
Voici deux variantes du Visitor pattern. L'un qui expose les objets métier (et donc utilise des getters) l'autre qui fait passer des primitives pour résoudre ce problème (pas forcément mieux, juste différent).
Extrait de la solution avec objets métier:
Les autres solutions explorés, dont j'aimerais bien voir le résultat, était délégation à une autre classe ou introduction d'une petite interface pour gérer le cas d'utilisation en question (par exemple Mailer pour contenir computeMailContent()). Ces deux solutions me semblent être des bonnes solutions temporaires en attendant de les extraire pour de bon. Par contre une fois extraite il me semble qu'on va tomber sur soit le visitor soit la solution que mentionne Xavier: beans+services. Non?
Conclusion
Les visitor qu'on trouve ici, est-ce vraiment trop complexe? Personnellement je pense que nous gagnerions à simplement pratiquer ce pattern pour savoir le mettre en oeuvre avec aise quand cela est préférable. Certes il faut le faire plusieurs fois pour avoir l'impression de maitriser, mais nous sommes nombreux à être informaticiens plus de 10 ans, alors qu'il suffit avec ~10h de pratique étalé sur quelques mois pour le maitriser en profondeur. Qu'en pensez-vous?
Inscription à :
Publier les commentaires (Atom)
Même solution quasiment par Marc Nazarian, et Laurent Vaills https://github.com/marcnazarian/single-responsability-principle-dojo
RépondreSupprimerEn effet la solution est la même que celle que nous avons implémenté avec Marc.
RépondreSupprimerJe pense, comme toi, qu'avec un peu de pratique et de démystification ce pattern n'est pas si compliqué que ça.
Il faut bien comprendre qui appelle les méthodes visit et accept; et qui doit les implémenter.
Le seul défaut de cette implémentation du pattern est qu'elle "fige" le parcours de l'arbre...défaut que tu contournes habilement par la concaténation inversée des 2 chaînes de caractères à la fin.
Salut Johan,
RépondreSupprimerPlus je regarde le code, et plus je regrette mon absence ... c'est comme ça ... une autre fois j'espère ...
Je viens de regarder tes codes. J'aurai tendance à préférer la version "objet" qui a pour avantage de limiter les impacts lorsqu'on ajoutera des attributs à Product et Cart.
J'ai également regardé le code de Laurent et Marc (merci à vous pour tous ces partages), effectivement, c'est la même solution.
Tout cela est très intéressant. Effectivement, vu comme ça, ça n'est pas si compliqué, du moins à comprendre (pour commencer). Bien sûr, tout cela me convient, mais qu'en est-il pour une équipe peu expérimentée ... ?
J'avais relevé un point embêtant, également relevé par Laurent : l'ordre de parcours des objets (appel aux méthodes "visit") dans Cart.accept(), effectivement habillement contourné par Johan en séparant les résultats pour les assembler dans le bon ordre ... ;-)
Finalement, cet exemple que j'ai pris est assez intéressant, surtout avec les compléments de fonctionnalités proposés (par Rémi je pense) : getProductsNames, totalPrice, validate, ... Il faudrait pousser les implémentations plus loin ...
Nous pourrions lancer un petit jeu, pour pousser l'expérience jusqu'au bout : écrire des tests unitaires d'intégration pour exprimer un résultat global attendu, faisant appel à toutes ces fonctionnalités, et voir différentes solutions complètes d'implémentation .... ;-)
Xavier
Salut Johan,
RépondreSupprimerMon premier commentaire s'étant perdu dans les limbes (j'ai du rater quelque chose, il était un peu tard...), je recommence.
Avec Guillaume nous allons présenter à Agile grenoble 2012 un sujet sur le Single Responsability Principle (http://sessions.agile-grenoble.org/program#session_detail_37), et ce dojo a été l'occasion pour nous de préparer ce sujet.
Nous avons donc prévu de décliner toutes les solutions possibles, au moins pour la préparation, même si notre présentation ne les aborde pas toutes.
Nous pourrons les publier avant la conf pour avoir vos retours.
Concernons le pattern visiteur, il y a peut être des moyens de le rendre plus compréhensible, par exemple en adaptant le nom des méthodes au contexte. A suivre donc...
Nicolas