conception entrées/sorties élégantes et solides

Salut,

J'ai une petite question de conception, j'aimerais savoir ce qu'il est coutume de faire.

J'écris un programme (console) qui est constitué de l'interaction de plusieurs objets, les uns avec les autres (comme tout le monde quoi).

Les paramètres utilisateur visant à initialiser le programme sont contenus dans une fichier d'input "input.txt", c'est un fichier ascii, mais peu importe...

Les paramètres contenus dans ce fichier d'input concernent différents objets dans le programme...

Perso je serais tenté de coder une classe qui fasse l'interface d'entrée de mon programme et dont une instance va lire et stocker les paramètres entrés dans le fichier input. Cette instance serait ensuite passée en paramètre des constructeurs des différents objets du programme, qui iront piocher, via les accesseurs, les paramètres qui les concernent.

Ca me semble bien car en faisant ça, je sépare bien la vie de mes objets, de ce qui fait l'interface d'entrée de mon programme.

Néanmoins, il y a une inélégance dans ce truc, liée à la redondance de certaines variables... qui sont à la fois des membres de ma classe d'input, et des membres de mes divers objets.

Est-ce qu'il y a une façon de faire qui soit reconnue ?


Merci

Salut,
Ne serait-ce pas d'un DP Builder dont tu as besoin ?

Autre chose, pour t'éviter l'écriture laborieuse d'un parser de fichier de config, il y a Boost.Program Option.

Vais voir la page wikipedia et je reviens... ça m'a l'air d'être un peu l'artillerie lourde comme méthode, du point de vue de mon petit projet :-)

Salut

Meuh non ne t'en fais pas, ce n'est pas très lourd un design pattern.

Ne t'en fais pas trop pour cette redondance là : tu peux créer tes objets (avec le pattern monteur comme suggéré par 3DArchi, par exemple) et détruire ensuite celui qui t'as permis de lire le fichier. De cette manière, le(s) monteur(s) n'aura(ont) pour durée de vie que l'initialisation du programme, ce qui est cohérent avec le rôle que tu veux lui donner.

Je valide également Boost.ProgramOption qui est facile à utiliser et très pratique.

Bonjour,

sur ce sujet, moi j'ai opté pour une solution que j'ai appelé Registry (qui n'a -presque- rien à voir avec la base de registre de windows).
3DArchi, le "DP builder" dont tu parles ne serait-ce pas plutôt le factory?
Quant à boost, effectivement c'est l'artillerie lourde. C'est un peu abusé de se taper boost juste pour ça (je n'aime pas trop boost de toutes façons. Je l'utilise pourtant dans presque tous mes projets, mais quand je peux, je m'en passe avec soulagement).

Mon histoire de Registry fonctionne comme suit:
C'est une simple map<string,string> (id/key), qui est encapsulée dans une classe Registry (dans mon cas c'est un singleton. Je suis un peu atteint de singletonite, mais dans ce cas là je pense que c'est vraiment ce qu'il y a de mieux). Cette classe Registry fournit une fonction qui lit le fichier de config (bon en vérité, dans ma lib c'est une classe à part mais peu importe) et des accesseurs templates qui permettent de récupérer les variables directement dans le type souhaité.

Les sources sont dispos sur mon dépôt sourceforge, si ça t'intéresse:
registry.h
registry.cpp
Note: l'acces aux variables de cette classe Registry est particulièrement coûteuse, surtout si on ne les récupère pas sous forme de string. Il faut donc l'utiliser de bon aloi (spéciale dédicace).

Ensuite, pour la création des objets qui utilisent ces variables, cela va dépendre de chaque objet. Il n'est certainement pas nécessaire, par exemple, d'implémenter une factory à chaque fois.

Citation:

---

Envoyé par r0d

Quant à boost, effectivement c'est l'artillerie lourde. C'est un peu abusé de se taper boost juste pour ça

---

Je ne suis pas trop d'accord. Passé l'étape d'installation et de link de boost la première fois qu'on s'en sert, ça se fait tout seul par la suite... Boost.Program_Option m'a fait gagner des heures de boulot par le passé.

jblecanard, je te répond ici ;)

Salut,

Citation:

---

Envoyé par r0d

3DArchi, le "DP builder" dont tu parles ne serait-ce pas plutôt le factory?

---

Il s'agit bien du DP Builder (ou Monteur) dont l'objectif est bien de masquer la construction d'un objet complexe. Cela peut être le cas au démarrage où un builder spécifique peut s'appuyer sur les fichiers de configuration/initialisation/arguments en ligne de cmd pour construire les objets de l'application.