Discussion :

[AsPrO]

Bonjour,

Je suis actuellement entrain de concevoir une sorte de "framework" pour un gros logiciel écris en C++/MFC. Mise à part une petite problématique, je me pose surtout la question sur la qualité du modèle que je conçois. Je n'ai pas très grande expérience et c'est pour ça que je fais appel à vous.
Donc premièrement j’ai une question ( que je poserai en fin ), deuxièmement je suis avide d’avis, de critique et de conseils (car je sens qu'il y a moyen de faire mieux) et petit troisièmement dites-moi si vous reconnaissez un pattern appliqué ( car même après les avoir lu et relu, je les reconnais difficilement).

L'existant



Tout d'abord, il y a l'existant sur lequel je n'ai aucun controle ou presque. On a une classe Record héritant sur plusieurs classe ( final order, material unit, job, ...). Tout ces objets sont directement ou indirectement liés entre eux. Prenons l'exemple des material unit qui peuvent être lié à 0 ou N FinalOrder et à 0 ou N job. La method GetAttribute permet d’obtenir à base d’un nom n’importe quel attribut non calculé.

Le but de mon travail est de pouvoir obtenir des attributs calculé et non calculé, ainsi que d'obtenir des attributs d'une FinalOrder en partant de sa Material unit (ceci dans tous les sens de tous les type de record vers tout les type de record). Et tout ça de façon transparente.
De cette manière l'affichage, et l'export doivent se faire simplement.

Recherche du record



Ilookup est une interface contenant les getters vers tous les objets. Elle hérite sur FinalOrderLookup, JobLookup, ... De cette manière, une fois qu’on a un Ilookup on peut accéder à tous les objets liés de façon transparente.


Recherche d’attributs



LookupOperation contient un Ilookup qui permet d’obtenir le bon type de record. Et les classes filles connaisse les traitements exacte à effectuer. Par exemple MaterialUnitDefaultOperation connaitra le traitement pour tout les attributs non calculés ( c’est toujours le même traitement pour les non calculé). La methode BuildOperation de IOperation se débrouille de trouver la bonne instance.

ExportOperation, construit avec un IOperation et un flux de sortie, se débrouille pour exporter comme il faut.

Le but est de construire une list de IOperation. Cette liste représente toutes les colonnes d’une vue liste. Pour l’affichage il suffira de créer un nouveau Ilookup et de le setter pour chaque ligne de la liste.

Même chose pour ExportOperation, la différence est que je n’arrive pas à faire un ExportOperation qui fonctionne, génériquement, pour tous les IOperation ET qui me permette de setter un Lookup.
Je pourrais setter un IOperation mais ca implequerait que je doive RE-retrouver le bon type de LookupOperation. Ou je pourrais faire contenir à ExportOperation un LookupOperation mais ca engendrerait une moins bonne généricité.

Question :
Comment pouvoir garder une certaine généricité (garder IOperation) et garder une certaine flexibilité (pouvoir setter simplement un ILookup) ?
De façon à parourir une liste d’ExportOperation (la liste des différents attributs à exporter) et de pouvoir changer le ILookup pour chaque ligne à exporter.

Un grand merci d’avoir déja tout lu

[AsPrO]

Un petit up :p
Si quelque chose n'est pas clair, hésitez pas.

[ego]

ben le problème c'est que l'on ne connait pas ton problème.
Tu ne fais que présenter une solution à un problème que l'on ne connais pas.
Bref, qu'est ce que tu cherches réellement à faire ?


Pour te donner un exemple, je ne comprend pas pourquoi tu cherches à récupérer des attributs de manière générique (visiblement).

En conception, soit on cherche à faire un truc générique mais souvent on s'engouffre dans un truc pas possible enfin, complexe, soit on se définit des........patterns et on les appliques à chaque fois que cela est nécessaire. Dans ce dernier cas, on peut être amené à écrire du code à chaque nouveauté mais au moins on a des choses plus simples en général.
La généricité n'est pas toujours la bonne solution

[AsPrO]

Oui, j'ai mal posé le problème. Merci à toi de le souligner.

En fait étant donné l'existant (Record et et dérives). Il y a pour chaque dérivé de Record un tas d'attributs différents calculé et non calculé. Il y a derrière ça un fichier de format par type de record, qui permet de lire et interpréter un fichier contenant les données. Tout cela est dynamique, chaque client a son type de format. Il y a juste certains attributs qui seront toujours commun et qui sont nécessaire au modèle.

Le problème vient au moment de l'affichage et de l'export.
Il faut pouvoir afficher et exporter TOUS les attributs et également tout les attributs d'un autre type de record lié. Ex: job->GetMaterialUnit()->GetAttributeValue("Attribut1");

La généricité vient du fait qu'on a en input un fichier format d'export ou de configuration d'affichage.
La syntax est grossièrement comme ça :

Code :

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

1
2
3
4
5
6
"nomAttribut1"        of MaterialUnit
"nomAttribut2"        of MaterialUnit
"nomAttribut3"        of FinalOrder
"nomAttribut4"        of Job
"nomAttribut5"        of TypeRecord1

Le format ci-dessous peut s'appliquer à n'importe quel type de Record. Si on export des Job, alors ca revient à faire job->MaterialUnit()->GetAttributeValue("nomAttribut1"); et ainsi de suite.

En résumé, je dois développer une solution qui étant donné l'existant doit pouvoir, avec le fichier de format (ci-dessus), exporter et afficher les bons attributs.
Question: Comment répondre à cette demande sans avoir 2 switch et une infinité de "case" ?
Les images UML, me servent uniquement à présenter le problème, le problème n'est pas de comment le représenter en UML mais de le développer.

Je présente ma solution dans le premier post parce que j'ai du pondre quelque chose pour le boulot mais je ne suis pas convaincu que ça soit la -meilleure-. (De plus une petite question pour ma solution expliqué au post 1 au niveau de ExportOperation mais moins important pour le moment).

[ego]

il te faut des Builder qui connaissent eux la structure des données = un Builder par classe "fille" de Record.
Il te faut de plus un mécanisme qui sait lire une ligne et en fonction du "of" va savoir quel Builder appeler. Au Builder on passe la string et lui il sait quel "set" faire

[AsPrO]

Faire le set de quoi ? Je ne suis pas sur de comprendre.
Le builder me faisant pensé au pattern factory, un peu comme présenté dans ma solution, qui avec un string trouvait la bonne instance de classe. Mais je dois me tromper étant donné que tu parles de setter quelque chose.