Discussion :

[Alcatîz]

Patron de conception "Interpréteur" avec Delphi 7
Un nouveau tutoriel de Jérémy Laurent

Après le singleton, Jérémy Laurent poursuit son exploration des patrons de conception avec Delphi.

Le patron de conception "Interpréteur" est un modèle visant à décrire et utiliser un langage spécifique pour réaliser des opérations en lien avec un domaine particulier. Ce langage est généralement propre au domaine auquel il est lié. Il est communément transmis dans une simple chaîne de caractères, car le texte brut est plus facile à lire et à manipuler. L’interpréteur est couramment utilisé pour analyser des chaînes algébriques et en renvoyer le résultat. Durant ce tutoriel, un projet tournant autour du JSON est créé petit à petit.

Lire le tutoriel

Et vous ?
Que pensez-vous de cet article ?

[gbegreg]

Bonjour,

Je profite de ce fil de discussion pour signaler (ou rappeler) le dépot Github de Jim Mc Keeth qui contient un projet regroupant des différents patterns de conceptions en Delphi :
https://github.com/jimmckeeth/DelphiPatterns

[popo]

Avant toute chose, je tiens à rappeler le contexte.

Il existe certainement des choses qui facilitent ou simplifient l'implémentation d'un pattern interpréteur avec un Delphi récent.
Ce tutoriel s'adresse donc à ceux qui, comme moi, n'ont pas le choix et doivent continuer à utiliser Delphi 7 mais ne veulent pas se priver des avantages des DP.

[ShaiLeTroll]

D7 ! un Challenge de "respecter" son style Delphi à l'ancienne, j'avoue que j'aime certains constructions modernes sans oublier mes bases.


Une question non D7 sur "LiveBindings - évaluateur d'expressions", est-ce que l'on peut assimiler cette fonctionnalité à un patron de conception "Interpréteur" sur chaîne algébrique et non dans ton exemple une structure JSON

Si l'on pousse la logique d'analyser et parser, par exemple pour du SQL ... peut-on y appliquer aussi le patron de conception "Interpréteur" ?
Je connais vaguement les notions de Lex & Yacc, je découvre totalement cette "Interpreter pattern"

[popo]

Bonjour ShaiLeTroll

J'ignore quels patterns se cachent derrière le Live Binding de cet article mais les lignes suivantes semblent s'en approcher.

Code :

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

1
2
3
Expression := TBindings.CreateExpression(Scope, maFormule.Text);
// récupération de l'évaluation de la formule
ValueInt := Expression.Evaluate;

On peut faire beaucoup de choses avec les patterns et notamment les combiner pour produire quelque chose d'encore plus souple et/ou de plus robuste.
Je citerai par exemple le pluggable factory qui combine abstract factory et prototype si je me souviens bien.
Donc ça ne m'étonnerais pas s'il y avait un petit bout d'interpréteur dans l'évaluateur d'expression du Live Binding.
Je commence d'ailleurs mon tuto en expliquant que "L’interpréteur est couramment utilisé pour analyser des chaînes algébriques et en renvoyer le résultat."

Et pour le SQL, on pourrait effectivement passer par un interpréteur pour analyser la syntaxe ou pourquoi pas carrément exécuter la requête.
Je soupçonne d'ailleurs que c'est le cas ou que ce fut le cas à un moment.

Cette syntaxe issue de la doc de Microsoft se rapproche beaucoup de l'EBNF que j'utilise pour décrire la grammaire du JSON.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<SELECT statement> ::=    
    [ WITH { [ XMLNAMESPACES ,] [ <common_table_expression> [,...n] ] } ]  
    <query_expression>   
    [ ORDER BY <order_by_expression> ] 
    [ <FOR Clause>]   
    [ OPTION ( <query_hint> [ ,...n ] ) ]   
<query_expression> ::=   
    { <query_specification> | ( <query_expression> ) }   
    [  { UNION [ ALL ] | EXCEPT | INTERSECT }  
        <query_specification> | ( <query_expression> ) [...n ] ]   
<query_specification> ::=   
SELECT [ ALL | DISTINCT ]   
    [TOP ( expression ) [PERCENT] [ WITH TIES ] ]   
    < select_list >   
    [ INTO new_table ]   
    [ FROM { <table_source> } [ ,...n ] ]   
    [ WHERE <search_condition> ]   
    [ <GROUP BY> ]   
    [ HAVING < search_condition > ]

ou encore la documentation de la librairie Microsoft.SqlServer.TransactSql.ScriptDom.
On y retrouve par exemple des classes SelectStatement ou WhereClause héritant d'une classe abtraite TSqlFragment, bref la base du pattern
On y retrouve des énumération comme SortOrder ou SetOptions qui ressemble étrangement aux expressions terminales que je présente et qui forment ensuite les token permettant de vérifier la grammaire.
On y retrouve aussi cette notion de token dans TSqlParserToken dont les propriétés ressemble assez à ce que je décrit dans ma propre classe de jeton.

Donc oui, si on voulait analyser ou exécuter du SQL, on pourrait certainement finir par y arriver avec un pattern interpréteur.