:: Enseignements :: ESIPE :: E4INFO :: 2013-2014 :: Programmation Orientée Objet - Design Pattern ::

Visitor

Rappels et visiteur

Exercice 1 - Hierarchie d'expressions

Les 3 classes suivantes permettent de parser une expression en polonaise inverse, de créer l'arbre de dérivation correspondant et de calculer la valeur de l'arbre en parcourant celui-ci.

Ecrire dans une classe Main, une méthode main de test qui permet de prendre une expression en polonaise inverse en tant qu'arguments de ligne de commande (un operateur/valeur par argument) et affiche le résultat correspondant.
Par exemple, pour l'expression + * 2 4 5 le résultat est 13.
Il y a un bug dans la classe BinOp, indiquer une expression en polonaise inverse qui permet de voir le bug.
Modifier la classe BinOp pour que le bug ne puisse plus se re-produire. Il s'agit donc non pas de fixer le bug mais de faire en sorte que ce type de bug ne puisse pas ce produire.
La méthode parseExpr semble avoir le même problème, comment corriger celui-ci.
Vérifier en ajoutant une opération modulo ('%').
On souhaite maintenant publier le code sous forme d'une librairie (un jar si vous préférez) ré-utilisable par d'autre. Le problème est que si par exemple, quelqu'un veut ajouter à la librairie une nouvelle opération comme par exemple l'affichage, cela ne sera pas possible car il faut ajouter l'implantation de la méthode toString et dans la classe Value et dans la clase BinOp or c'est impossible car le code est publié sous forme d'une librairie, il n'est donc ni accessible ni modifiable.
Pour résoudre ce problème, ajouter un visiteur ExprVisitor et pour tester, supprimer la méthode eval et ré-écrivez la en utilisant le principe du visiteur.
Note: le visteur devra pouvoir prendre un argument et retourner une valeur de retour.
Expliquer pourquoi utiliser un enum pour Operator pose un problème en terme d'extensibilité.
Comment peut-on faire pour remplacer l'enum ?
Faite les changements qui s'impose
Est-il toujours logique de déclarer parseExpr dans Expr ?
Pourquoi ?
Faire les changements qui s'impose.
Le visiteur résoud le problème de pouvoir ajouter des fonctionnalités à une hierarchie déjà écrite et fermée, mais le visiteur fige la hiérarchie, il est donc impossible d'ajouter d'autre opérateur à la librairie sans changer celle-ci.
Expliquer pourquoi le visiteur fige la hierarchie.
On peut remarquer qu'un visiteur est quelquechose qui associe à une classe un code à exécuter.
Il est donc possible d'implanter le même mécanisme que celui du visiteur en utilisant une table de hachage pour associer à une classe le code à exécuter (sous-forme de lambda).
Ecrire le code correspondant.
Enfin, le code n'est pas explicite à propos de ces dépendances, on souhaite corriger ce problème et rendre les dépendances explicites, donc pas de variable static (même final), pas de méthode statique.
Tester en ajoutant de façon externe et une nouvelle opération binaire et une méthode permettant d'afficher les élements dans l'ordre usuelle et ce de façon externe.