Bonjour,
Dans son dernier cours, M. Douin a présenté le patron Interpreteur : j'en ai surtout retenu qu'il était d'une utilisation laborieuse !
D'après ce que j'ai compris, un Visiteur peut toujours avantageusement remplacer un Interpreteur, puisqu'il est une sorte d'Interpreteur plus générique.
D'où ma question : existe-t-il des cas où l'utilisation de l'Interpreteur est préférable à celle du Visiteur ?
Question INTERPRETEUR
Modérateur : douinj
Re: Question INTERPRETEUR
Bonjour,
Composite + Interpreteur
Un traitement et son contexte "stables" associés à une grammaire qui pourrait évoluer, (une nouvelle sous-classe, redéfinition du traitement) par exemple l'API AWT a tenu plus de 10 ans, le traitement de l'affichage d'une figure sur un écran graphique était plutôt constant
https://en.wikipedia.org/wiki/Interpreter_pattern
Composite + Visiteur
Un traitement et son contexte "variés" associés à une grammaire qui évolue peu, par exemple l'API Java-Compiler et ses visiteurs, le traitement est laissé à l'initiative des utilisateurs
https://en.wikipedia.org/wiki/Visitor_pattern
à suivre
Composite + Interpreteur
Un traitement et son contexte "stables" associés à une grammaire qui pourrait évoluer, (une nouvelle sous-classe, redéfinition du traitement) par exemple l'API AWT a tenu plus de 10 ans, le traitement de l'affichage d'une figure sur un écran graphique était plutôt constant
https://en.wikipedia.org/wiki/Interpreter_pattern
Composite + Visiteur
Un traitement et son contexte "variés" associés à une grammaire qui évolue peu, par exemple l'API Java-Compiler et ses visiteurs, le traitement est laissé à l'initiative des utilisateurs
https://en.wikipedia.org/wiki/Visitor_pattern
à suivre
Re: Question INTERPRETEUR
Je pose la question car je crois n'avoir jamais rien vu de vraiment 'stable' dans les programmes sur lesquels je travaille, c'est même souvent une grande source de régressions et de contresens : on a voulu graver quelque chose dans le marbre, et quelques années plus tard ça n'a plus le même sens.
D'où ma conclusion (peut-être hâtive) de privilégier systématiquement le Visiteur lors d'un refactoring, puisqu'il n'est pas plus compliqué à coder que l'Interpreteur.
D'où ma conclusion (peut-être hâtive) de privilégier systématiquement le Visiteur lors d'un refactoring, puisqu'il n'est pas plus compliqué à coder que l'Interpreteur.