Formules, opérandes, opérateurs. Et leur persistence.

Bonjour,
Je travaille sur un site web interne en javaEE gérant des formules appliquées à des grands nombres. Ces formules sont évaluées dans certains contextes. Je ne travaille pas avec des informaticiens capables de me répondre.
a et b sont des opérandes.
+ et - sont des opérateurs.
a+b et a-b sont des formules.
Je veux créer des listes mixtes de formules et d'opérandes que je puisse stocker en base de données.

Les opérandes et les formules peuvent être évaluées. J'ai pensé à une structure composite. Cependant les opérateurs ne peuvent être évalués.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

opérande formule________ | | | | | | \/ \/ | élément évaluable | | | \/ | élément<>-------| /\ | opérateur

---

Cette structure est-elle correcte ? Même si les opérateurs sont en nombre fini/réduit ?

Des listes de formules doivent être gardées en base de données. Y a-t-il plus simple que de stocker dans une table les opérandes avec des identifiants et dans une autre table des chaines représentant les formules ; ex : "(id1)+(id2)-(id3)" ?

J'espère que ce problème en intéressera quelques-uns.
Quelques réponses nous aideraient à nous situer et nous éclairaient sur ce problème qui nous embêtent dpeuis quelques mois maintenant (heureusement nous avons d'autres projets sur lesquels travailler).
Merci de votre attention,
Proph

Bonjour,

Pour le pattern composite, j'ai l'habitude de me représenter la structure sous forme d'arbre.
Et pour représenter une équation, c'est souvent de la façon suivante :
Toutes les feuilles sont des opérandes, et les noeuds sont des opérateurs.

Code:

---

1 2 3 4 5 6 7 8

+ / \ A * / \ B - \ C

---

ici : A + B * (-C)

Donc je ferais la structure Java de la façon suivante :

Code:

---

1 2 3 4 5

Evaluable ---------| ^ ^ | | | | Operande Formule <>-|

---

Operande et Formule sont donc tous deux évaluables.
Et votre objet Formule contiendrait un membre "opérateur" et une liste de membres "Evaluables" (dépendant si l'opérateur est unaire, binaire, etc...)
Éventuellement vous pouvez dériver autant de classe Formule qu'il y a d'opérateurs : FormulePlus, FormuleMoins, FormuleMoinsUnaire, etc...

L'avantage d'utiliser le pattern composite est que vous pourrez faire l'évaluation ou la représentation en chaine de caractère en déclarant les méthodes adéquates dans Evaluable :
Evaluable::evalue()
Evaluable::afficheFormule() (attention aux parenthèses qui sont implicites dans la structure Java)
Evaluable::afficheOperandes()
voire même Evaluable::stockeEnBdd() (Mais cela risque d'engendrer des dépendances au système de BDD choisi, qui ne sont pas forcément souhaitables)

Concernant le stockage en base de données, je dirais que ça dépend du besoin par rapport aux données stockées.
Par exemple s'il faut pouvoir recréer les objets Java à partir de la base de donnée, il y aura un gros travail de parsing à faire (et non trivial) si vous stockez de la façon indiquée.
Dans un tel cas il vaut peut-être mieux réfléchir à une façon de stocker qui soit plus proche de la structure Java.
Si par contre il s'agit juste d'afficher la chaine, c'est très bien comme ça.