Discussion :

[geforce]

Bonjour,

Je suis en stage dans une Boîte dans la phase conception de mon application (avec le diagramme de classe).

L'idée pour réaliser la conception: Serait de faire une conception (ouvert à l'extension et fermer à la modification) en utilisant des patterns de conception.

on ce basant sur les cas suivant:

1. Sur le fait qu'on veut parser de l'OML (s’il y a une extension du méta langage OML il sera bon d’ajouter une autre classe parceur sans modifier le code existant)
2. Et aussi que l'on soit indépendante du fait que l'on parce de l'OML sous sa forme intermédiaire ou sous la forme vu client (vu ci-dessous) ?

Donc Quel Patron de conceptions utilisées ?


NB : OML est un méta langage propriétaire
Le Contenu du fichier txt : (l’OML pour nous est sous cette forme)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
//l'employer saisie la date le type du statu => des commentaires
//choisie un projet, l’activité et saisir la durée passé sur cette activité
 
set formOperation (grid,new,edit,search,delete,detail,order);
use table TSStatus;
DateStatus:field(textbox);
DateStatus:label("Date de saisie:");
Type:sfield(select,source(TSTypeStatus,TypeStatus));
Type:label("Type du status:");

Merci d'avance
Cordialement
GeForce

[JulienDuSud]

Le pattern Decorateur me semble une manière cohérente et correcte de résoudre ton problème de parsing.

En effet, si tu as un parser qui va traiter un certain bloc, et que tu veux étendre les fonctionnalités de ce bloc, tu n'auras qu'à le décorer avec le traitement de la nouvelle fonctionnalité.

Cependant, il faut faire attention à ce que les parsers ne soient pas éparpillés n'importe où. Il faut donc que tu aies une solide base sur laquelle tu peux décorer. Une interface dont hériterait tous tes paresers, par exemple.

Un parser va traiter une certaine partie du texte. Et il va dédier à un parser décoré différemment le parsing d'une zone de texte qu'il ne sait pas lui même traiter, et ainsi de suite, jusqu'à arriver aux parsers "bas niveau" qui ne sauront donc que parser des instructions simples et non des blocs.

Si jamais le langage à parser change d'une certaine manière (ajout d'une nouvelle instruction, par exemple), il suffira de créer un nouveau décorateur pour le parser de texte brut (qui sera ton parser le plus bas niveau) qui va donc retourner la nouvelle instruction parsée.

Pour ce qui est de la sélection du bon parser (avec donc la bonne décoration), le pattern Factory Method convient. Bien sûr, si tu ne veux pas devoir modifier le code existant du Factory Method, tu peux soit l'implémenter en utilisant le pattern Decorator, soit utiliser le pattern visitor associé à une map { Type => DecoratedParser } afin de générer le bon parser décoré.

Au final, lorsque tu voudras ajouter un nouveau parser, tu n'auras qu'à créer un nouveau Decorateur et ajouter le type d'instructions qui va parser dans la map. Tu ne fais donc effectivement que de l'ajout de code.

Par contre, il faut faire attention à ne jamais devoir intervenir directement dans la map elle-même: c'est à dire que ça devrait être le parser qui s'enregistre, par exemple, auprès d'un gestionnaire (Factory Method) de parser afin de déclarer qu'il est disponible et de lui déclarer le type d'instructions qu'il est capable de traiter.

Si tu ne comprends pas une partie de mon charabia, hésites pas à me le dire !