Problème de conception : chargement de config

Bonjour,

Je cherche à charger des paramètres de configuration dans mon application.

1) Je vais donc avoir une classe de départ Config, pour laquelle je n'ai pas encore choisi la conception exacte (singleton/static load). Y a-t-il une préférence parmi ces deux options ?

2) Mon vrai problème arrive ensuite, lorsque je veux "propager" mes paramètres aux différentes classes.

a) Ma première idée était de venir simplement chercher depuis ma classe X le paramètre dont j'ai besoin via Config::M_param, avec M_param une variable statique de ma classe Config.
Inconvénient : mes classes dépendent directement de la Config.

b) Une autre idée était donc de commencer à initialiser dans chaque classe des variables statiques représentant mes paramètres et de venir ensuite appeler une méthode de chargement load pour éventuellement charger les valeurs d'un fichier de config.
Problème : il me faut une méthode de base héritée par mes classes pour le chargement. Or, je souhaite garder mes variables en statique car je trouve ça plus logique d'associer les paramètres à une classe plutôt qu'à une instance. Seulement, si je veux garder tout le chargement de la Config en statique, il m'est impossible d'avoir une méthode de chargement héritée par mes classes. Avez-vous une idée ?

Pour information, j'envisage ensuite d'utiliser le modèle Observer entre la Config et toutes mes classes pour le chargement.

Merci à vous :D

Salut,

La première chose à faire, c'est de veiller à parfaitement séparer les différents modules et responsabilités.

Non seulement au niveau de la gestion des options de configuration, mais aussi -- et surtout -- au niveau des fonctionnalités proposées par ton projet.

En effet, si ton application travaille en réseau, l'affichage n'aura besoin que des options "cosmétiques" permettant de définir les couleurs, les polices de caractères à utiliser ou la taille de l'affichage. Elle n'aura absolument que faire des options spécifiques au réseau (sauf, évidemment, pour l'éventuel onglet qui doit te permettre de les modifier ;))

Chaque "module" de ton application -- base métier, sauvegarde/chargement, réseau, affichage, son, ... -- devrait pouvoir travailler de manière strictement indépendante des autres (à l'exception de quelques "point d'accès" car il faudra bien que ces modules communiquent avec les autres ;)) et ne devrait donc avoir accès qu'aux options de configuration qui lui sont propres.

Et les différentes parties d'un module n'ont pas forcément besoin de disposer de toutes les options qui concernent ce module.

Le module réseau, par exemple, sera composé d'une classe qui aura pour but de créer et de maintenir la connexion active (ConnexionHolder :question:).

Cette classe aura besoin des options relatives à cette tâche, à savoir : le nom du serveur à contacter, le port, le protocole à utiliser, le nom d'utilisateur, son mot de passe, et autres auxquelles ne je pense pas forcément.

Mais on pourrait envisager d'indiquer la méthode de signature, de compression ou simplement d'encodage du contenu émis.

Ces informations ne sont sans doute absolument pas nécessaire à la classe ConnexionHolder mais seront par contre indispensable à la classe qui s'occupe de la transmission en elle-même. Et cette dernière n'aura absolument pas à s'inquiéter des options relatives à la mise en place et au maintient de la connexion.

Par contre, il est très vraisemblable (en tout cas, je t'incite à le faire) que tu mettras en place un système fort proche du patron de conception Façade pour permettre aux autres modules de communiquer avec ton module "réseau".

Cette façade, qui pourrait tout aussi bien être une classe, serait le candidat idéal à qui fournir l'ensemble des options propres au réseau, vu que c'est au travers de cette façade que toutes les fonctionnalités du réseau seront utilisées. Elle serait donc particulièrement bien placée pour transmettre l'option utile à "qui de droit" ;)

Et bien sûr, tu travaillerais de manière strictement similaire pour tous les modules :D

Au final, tu aurais une dernière classe, mettons Application, qui mettrait en présence les différents modules qu'elle utilise, éventuellement en tenant compte d'options qui la concernent directement (si tu as une option --nosound, c'est sans doute pour indiquer à l'application qu'elle ne doit pas activer le système de gestion du son :D) et qui "dispatcherait" les options adéquates vers les modules qui en ont besoin.

Je suis globalement contre le patron de conception singleton parce que j'estime (et je ne suis pas le seul :D) qu'il s'agit d'un "anti pattern" dans le sens où le meilleur moyen pour s'assurer qu'une donnée ne sera pas dupliquée, c'est encore de veiller à n'en créer qu'une seule.

En plus, le patron de conception Singleton utilise forcément une variable statique pour fonctionner.

Or, une variable statique n'est jamais qu'une variable globale "Facon du chef, enrobée d'accessibilité sur lit de mystère, avec sa sauce OO" :D

Au final, je dirais : pas de variables statiques, mais des variables "tout à fait classiques" qui seront, selon le cas, transmises comme argument à une fonction ou au constructeur (sous la forme d'une référence non constante, si besoin) des objets qui en ont réellement besoin ;)

Perso, je suis pas trop d'accord, dans tout mes projets (et projets professionnel) les classe de configuration sont des singleton renvoyant les différentes variables.

Exemple:
Mon fichier de configuration est un xml classique:

Code:

---

1 2 3 4

<configuration> <port>4242</port> <ip>127.0.0.1</ip> </configuration>

---

Ensuite ma classe de configuration va aller parser ce fichier et stocker les information sous forme de map:

Code:

---

std::map<std::string, std::string> info;

---

Pour y accéder j'ai juste besoin d'appelé une des fonction pour récupérer une variable:

Code:

---

1 2 3 4 5 6 7 8

int getInt(std::string cle) { return (toInt(info[cle])); } std::string getString(std::string cle) { return (info[cle]); }

---

(Ce n'est qu'une ébauche de ce que j'ai réellement, mais c'est pour donner une idée).

Ce système permet de rajouté des variable dans le fichiers de configuration sans avoir à recodé une partie du programme.

C'est beaucoup plus dynamique que d'avoir un membre d'une classe qui stock un paramètre. Imagine que tu doives rajouter x paramètre pour plusieurs classes, il faudra alors que tu re-développe les constructeurs de tes classes.

Imagine une classe ayant besoin de 10 paramètre, tu vas pas appelé un constructeur avec 10 variable quand même?
Imagine que ce constructeur soit appelé 50 fois dans ton code, tu vas aller modifié 50 fois ces lignes?

C'est pourquoi je pense qu'il est nettement mieux de passer par un singleton pour la configuration, ce n'est pas une partie très sensible d'une application donc on peut se le permettre.

Bonjour et merci à tous les deux pour vos suggestions :D.
C'est intéressant d'avoir ici deux points de vue!

koala01 :

Citation:

---

Je suis globalement contre le patron de conception singleton parce que j'estime (et je ne suis pas le seul ) qu'il s'agit d'un "anti pattern" dans le sens où le meilleur moyen pour s'assurer qu'une donnée ne sera pas dupliquée, c'est encore de veiller à n'en créer qu'une seule.

---

Ok mais charge au(x) développeur(s) de faire attention à ne pas instancier un nouvel objet qui ferait doublon alors, c'est ça? Pourquoi rester trop permissif au niveau de la conception si au final on veut qu'une seule et unique instance ?

Citation:

---

Or, une variable statique n'est jamais qu'une variable globale "Facon du chef, enrobée d'accessibilité sur lit de mystère, avec sa sauce OO"

---

En fait, j'avais envisagé de mettre mes paramètres de configuration par défaut en variable statique privée, ce qui réduit quand même la visibilité à la classe considérée, je trouve donc ça pas trop mal a priori.

Sinon, la Config serait aussi pour toi un objet instanciable classique ?

Citation:

---

Au final, je dirais : pas de variables statiques, mais des variables "tout à fait classiques" qui seront, selon le cas, transmises comme argument à une fonction ou au constructeur (sous la forme d'une référence non constante, si besoin) des objets qui en ont réellement besoin

---

Skeud :

Citation:

---

Imagine que tu doives rajouter x paramètre pour plusieurs classes, il faudra alors que tu re-développe les constructeurs de tes classes

---

A moins peut être de réaliser quelque chose d'assez générique en passant par exemple en constructeur une structure qui stocke les paramètres de configuration du module donné ? Enfin après, même si la signature des constructeurs restent inchangées, il faudra quand même définir les nouveaux membres pour stocker les nouveaux paramètres donc non c'est pas mieux ^^.

Citation:

---

Envoyé par skeud

Perso, je suis pas trop d'accord, dans tout mes projets (et projets professionnel) les classe de configuration sont des singleton renvoyant les différentes variables.

Pour y accéder j'ai juste besoin d'appelé une des fonction pour récupérer une variable:

Code:

---

1 2 3 4 5 6 7 8

int getInt(std::string cle) { return (toInt(info[cle])); } std::string getString(std::string cle) { return (info[cle]); }

---

---

J’ai pas mal utilisé ça, mais je trouve qu’il y a deux défauts principaux à cette approche :
- la description du fichier de configuration est éparpillée à plein d’endroits (en fait, partout où on utilise des paramètres de l’application), ce qui fait qu’il est difficile de lister tous les paramètres possibles de l’application.
- l’interface incite à utiliser directement le paramètre de configuration partout où on en a besoin en utilisant Config::get(XXX), où XXX est une chaîne de caractères, ce qui peut amener des bugs idiots dus à des fautes de frappe (et si c’est à un endroit du code où on ne passe pas souvent, ça peut être plus compliqué qu’on ne croit à détecter), ou compliquer le refactoring en cas de changement du nom du paramètre.

Cela dit, ça fonctionne et c’est simple à utiliser. Je recommande quand même du coup de s’imposer les limites suivantes :
- un paramètre de configuration en doit être lu qu’une seule fois, dans une fonction d’initialisation de l’objet dédiée
- la map des paramètres doit être hiérarchisée, de sorte qu’un module ne connaisse que ses propres paramètres et pas ceux des autres modules. Ça protège aussi des conflits de nom (par exemple, un programme qui accèderait à la fois à une bdd et à un service web pourrait avoir deux fois le paramètre username, mais pour deux contextes différents).

Citation:

---

Citation:
Imagine que tu doives rajouter x paramètre pour plusieurs classes, il faudra alors que tu re-développe les constructeurs de tes classes

---

Effectivement, un gros intérêt pour une bibliothèque est de pouvoir rajouter un paramètre tout en gardant la compatibilité binaire.

Citation:

---

Envoyé par white_tentacle

- l’interface incite à utiliser directement le paramètre de configuration partout où on en a besoin en utilisant Config::get(XXX), où XXX est une chaîne de caractères, ce qui peut amener des bugs idiots dus à des fautes de frappe (et si c’est à un endroit du code où on ne passe pas souvent, ça peut être plus compliqué qu’on ne croit à détecter), ou compliquer le refactoring en cas de changement du nom du paramètre.

---

C'est pourquoi j'utilise en général dans chacun de mes header de classe ou directement dans la configuration un enum ou des constantes définissant le nom des variables du fichier de configuration.

Une autre implémentation possible est d'avoir un objet configuration par module qui va chercher et charger exclusivement les paramètres qui concerne le module:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

<configuration> <reseau> <port>4242</port> <ip>127.0.0.1</ip> </reseau> <log> <fichier>toto.log</fichier> <level>DEBUG</level> </log> ... </configuration>

---

Voir aussi un fichier de configuration par module.

Et le constructeur de la classe configuration prend en paramètre le nom du module.
Cela permet d'avoir dans chaque module une classe de configuration qui contient que les paramètre du module, mais en contrepartis il faut se trimballé l'instance de la classe de configuration un peu partout car on y accède pas en singleton.

On peut aussi bien configurer la classe singleton qui stock la configuration pour hiérarchisé les information:

Code:

---

1 2 3 4 5 6

std::map<std::string, std::map<std::string, std::string>> info;   getString(std::string module, std::string cle) { return(info[module][cle]); }

---

L'énorme avantage que je vois c'est la modularité de ce fonctionnement, le but étant d'avoir un maximum d'information en dehors du code pour pouvoir changer le comportement de l'application sans recompiler.

Bien sur, comme toute chose, il faut l'utilisé avec paricimonie pour ne pas être dans la sur-configuration.

Vos méthodes me semblent plutôt bonnes mais ce qui me gène encore, c'est le fait d'associer les paramètres à un objet lors de son initialisation. C'est pourquoi je préfèrerais garder mes paramètres en variables statiques privées pour chacun de mes modules.

Voici en brouillon une solution en Qt pour laquelle j'aimerais avoir vos avis sur le fond plus que la forme :

La configuration QConfig :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

typedef void(*Load)(); // Pointeur sur une méthode de chargement   class QConfig { public : static void load(QString file); // Chargement du Dom depuis un fichier static void load(QString module, QMap<QString, QVariant>& params); static void attach(Load);   private : static void notify();   private : static QDomElement* M_pDom; // Stockage du dom static QList<Load> M_loads; // Liste des pointeurs sur les méthodes de chargement }

---

Code:

---

1 2 3 4 5 6

bool QConfig::load(QString file) { /* bool ret = StockageDuDomEnVariableStaticPriv();   if (success) */ notify(); // Le dom étant chargé, on est prêt à récupérer les paramètres depuis les modules. }

---

Code:

---

1 2 3 4 5

void Config::notify() { for (int i=0; i<M_loads.size(); ++i) (*M_loads[i])(); // Appel aux méthodes statiques de chargement }

---

Code:

---

1 2 3 4

bool QConfig::load(QString module, QMap<QString, QVariant>& params) { // Récupération des paramètres du module donné dans le dom }

---

Un module QNetwork :

Code:

---

1 2 3 4 5 6 7 8

class QNetwork //: public QModule { public : static void loadParameters();   private : static quint16 M_port; }

---

Prise en compte du nouveau module pour le chargement des paramètres :

Code:

---

QConfig::attach(QNetwork::loadParameters);

---

La méthode de chargement des paramètres d'un module :

Code:

---

1 2 3 4 5 6

void QNetwork::loadParameters() { QMap<QString, QVariant> tabParams; tabParams.insert(CFG_PARAM_PORT, M_port); Config::load(CFG_MODULE_NETWORK, tabParams); }

---

Qu'est ce que vous en pensez ?

Merci ;)

Si tu utilises Qt, utilises QSettings plutôt que de refaire quelque chose qui est similaire (sauf bien sûr à titre éducatif).

Citation:

---

Envoyé par skeud

Perso, je suis pas trop d'accord, dans tout mes projets (et projets professionnel) les classe de configuration sont des singleton renvoyant les différentes variables.

---

Allez, un peu de lecture :D (ca faisait longtemps que je ne l'avais plus ressorti ce lien :D)

Citation:

---

Ce système permet de rajouté des variable dans le fichiers de configuration sans avoir à recodé une partie du programme.

C'est beaucoup plus dynamique que d'avoir un membre d'une classe qui stock un paramètre. Imagine que tu doives rajouter x paramètre pour plusieurs classes, il faudra alors que tu re-développe les constructeurs de tes classes.

Imagine une classe ayant besoin de 10 paramètre, tu vas pas appelé un constructeur avec 10 variable quand même?
Imagine que ce constructeur soit appelé 50 fois dans ton code, tu vas aller modifié 50 fois ces lignes?

---

Ah, ben, ca me fait penser à cette discussion sur laquelle j'ai été à peu pres le seul à répondre à impéro!

Et je me suis même fendu d'un petit projet de "correction", qui utilise trois fichiers d'en-tête et que tu trouveras ==>ici<==

Ne trouves tu pas cela plus propre :question:

Citation:

---

C'est pourquoi je pense qu'il est nettement mieux de passer par un singleton pour la configuration, ce n'est pas une partie très sensible d'une application donc on peut se le permettre.

---

C'est beaucoup plus sensible que tu ne pourrais le croire!

Le problème du singleton, c'est que c'est forcément une variable globale, qui va donc maintenir globalement un ensemble d'informations dont certaines peuvent être sensibles (login et mot de passe, par exemple) et dont tu n'as globalement que faire dans la majorité des cas.

Tu pourrais en arriver à créer un singleton par module, ce qui aurait au moins déjà l'avantage de faire en sorte que chaque module ne dispose que des informations dont il a réellement besoin.

Mais c'est oublier un peu vite que chaque module est composé de plusieurs classes qui n'ont sans doute que faire de la plupart des informations auxquelles le singleton donne accès ;)

Citation:

---

Envoyé par sfarc

Bonjour et merci à tous les deux pour vos suggestions :D.
C'est intéressant d'avoir ici deux points de vue!

koala01 :

Ok mais charge au(x) développeur(s) de faire attention à ne pas instancier un nouvel objet qui ferait doublon alors, c'est ça? Pourquoi rester trop permissif au niveau de la conception si au final on veut qu'une seule et unique instance ?

---

Ca, ce n'est pas le plus compliqué...

Tu peux, par exemple, envisager le recours au pimpl idiom:

Code:

---

1 2 3 4 5 6 7 8 9

class SoundConfig; class SoundModule{ public: SoundModule(std::string const & configFilename); ~SoundModule(); UnType const & getConfigValue( Identifiant id) const; private: SoundConfig * config_; };

---

(UnType et Identifiant sont des types qui te seront utiles pour travailler qu'il s'agit de définir par toi même;))

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#include <SoundModule.h> class SoundConfig{ public: SoundConfig(std::string const & configFilename){ /* ... */ } UnType getConfigValue(Identifiant id) const{ /* ... */ } private: std::map<Identifiant, UnType> infos_; } SoundModule::SoundModule(std::string const & configFilename): config_(new SoundConfig(configFilename){   } SoundModule::~SoundModule(){ delete config_; } UnType SoundModule::getConfigValue(Identifiant id) const{ return config_->getConfigValue(id); }

---

Comme tu n'auras, de toutes manières, qu'un seul module son dans ton application, tu auras la certitude qu'il n'y aura qu'une seule instance de SoundConfig et le développeur n'aura jamais la possibilité d'aller créer une nouvelle instance de SoundConfig ;)

Citation:

---

En fait, j'avais envisagé de mettre mes paramètres de configuration par défaut en variable statique privée, ce qui réduit quand même la visibilité à la classe considérée, je trouve donc ça pas trop mal a priori.

---

Comme je te l'ai dit, même si c'est une variable privée, cela en fait une variable globale (c'est le gros principe du mot clé static).

Tu as beau la cacher, tu a beau en restreindre l'accès, ca reste une variable globale, et les variable globales, c'est mal ;)

Citation:

---

Sinon, la Config serait aussi pour toi un objet instanciable classique ?

---

A peu de chose près, oui.

Mais elle serait beaucoup plus proche de la structure FILE que l'on a en C : Tout le monde sait qu'elle existe, mais personne ne sait ce qu'elle contient réellement et tout ce que l'on en sait, c'est la manière dont on peut l'utiliser.

Dans l'exemple que je viens de donner, la seule chose que l'on en sait (et encore !!) c'est qu'on peut y accéder de manière indirecte au travers de SoundModule et de sa fonction membre getConfigValue ;)

Je me permet de revenir sur

Citation:

---

Envoyé par skeud

Imagine une classe ayant besoin de 10 paramètre, tu vas pas appelé un constructeur avec 10 variable quand même?

---

Je vais surtout voir à appeler le constructeur avec les paramètres dont il a réellement besoin pour fournir un objet cohérent, et veiller à ce que les autres paramètres soient transmis aux fonctions qui en ont besoin ;)

Parce que ce que j'ai dit au niveau de l'application et du module s'applique également au niveau de la classe : de nombreuses options utilisées au niveau de la classe ne sont utiles que pour certaines fonctions spécifiques (que ce soit le constructeur ou toute autre, fonction membre ou non, faisant partie de l'interface publique de l'objet en question).

Si une classe n'a pas besoin d'une information dont une des fonctions spécifique a besoin, il faut juste veiller à transmettre cette information particulière à la fonction qui en a besoin ;)

Citation:

---

Imagine que ce constructeur soit appelé 50 fois dans ton code, tu vas aller modifié 50 fois ces lignes?

---

Je ferais surtout passer le développeur responsable de cet état de fait par la fenêtre avant, s'il a la chance d'en réchapper, de le faire écarteler tout en le faisant rotir à petit feu, histoire qu'il comprenne sa douleur :D

La création d'objet doit être centralisée et la décision finale de créer ou non l'objet, en lui passant telle ou telle valeur issue de la configuration, doit dépendre d'un système qui permet justement de s'assurer -- de manière transparente pour celui qui demande la création de l'objet -- que l'objet sera créé "comme il se doit" pour respecter la configuration sans que l'utilisateur n'ai le moindre droit de regard sur cette configuration.

Je m'explique :

Mettons que l'utilisateur veuille créer un objet spécifique qui sera positionné à un endroit bien donné et que cet objet puisse être d'une couleur spécifiée par la configuration.

Les seules informations que l'utilisateur doit transmettre au système qui se chargera de créer l'objet, c'est la position de celui-ci ainsi que les éventuelles informations qui permettront, d'une manière ou d'une autre, de déterminer si c'est un objet de type A ou un objet de type B qui sera réellement créé.

Il n'a strictement que faire de savoir si l'objet en question sera, en fonction de la configuration, bleu ciel, rouge sang ou brun caca doigt ;)

Tout ce que l'utilisateur doit pouvoir faire, c'est demander au système concerné "crée moi tel objet à tel position" !

Et c'est au système de déterminer si l’utilisateur a le droit ou non de créer l'objet demandé, quelle couleur lui donner et le meilleur moyen à utiliser pour parvenir au résultat escompté par l’utilisateur ;)

Citation:

---

Allez, un peu de lecture (ca faisait longtemps que je ne l'avais plus ressorti ce lien )

---

Sympa comme article :D. J'étais déjà tombé dessus mais ça fait pas de mal de le relire :P.

Citation:

---

Tu peux, par exemple, envisager le recours au pimpl idiom:

Code:

---

1 2 3 4 5 6 7 8 9

class SoundConfig; class SoundModule{ public: SoundModule(std::string const & configFilename); ~SoundModule(); UnType const & getConfigValue( Identifiant id) const; private: SoundConfig * config_; };

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#include <SoundModule.h> class SoundConfig{ public: SoundConfig(std::string const & configFilename){ /* ... */ } UnType getConfigValue(Identifiant id) const{ /* ... */ } private: std::map<Identifiant, UnType> infos_; } SoundModule::SoundModule(std::string const & configFilename): config_(new SoundConfig(configFilename){   } SoundModule::~SoundModule(){ delete config_; } UnType SoundModule::getConfigValue(Identifiant id) const{ return config_->getConfigValue(id); }

---

Comme tu n'auras, de toutes manières, qu'un seul module son dans ton application, tu auras la certitude qu'il n'y aura qu'une seule instance de SoundConfig et le développeur n'aura jamais la possibilité d'aller créer une nouvelle instance de SoundConfig

---

Oui effectivement j'aurais qu'un seul module mais ce qui m'embête, c'est que rien ne l'impose. Rien n'empêche un développeur un jour d'instancier un nouveau module son par exemple même si c'est pas très fute fute.

Aussi, autre point, l'idée de passer en paramètre du constructeur le chemin du fichier de configuration à chaque module me gène un peu. Cela voudrait dire, que chaque module, ou plutôt chaque objet conf associé a la possibilité de connaître l'ensemble du fichier. Je réfléchie à une alternative pour ce point là ;).

Citation:

---

Envoyé par sfarc

Aussi, autre point, l'idée de passer en paramètre du constructeur le chemin du fichier de configuration à chaque module me gène un peu. Cela voudrait dire, que chaque module, ou plutôt chaque objet conf associé a la possibilité de connaître l'ensemble du fichier. Je réfléchie à une alternative pour ce point là ;).

---

De mon point de vue, un module doit se configurer… avec une structure qui lui est dédiée.

Dans l’idéal, tu vas donc avoir :
- un gestionnaire de settings, générique, qui s’occupe de la persistance (et donc, lecture / écriture du fichier de paramètres).
- des classes / modules qui prennent quelque part, soit dans le constructeur, soit dans une méthode init, une structure/classe dédiée à leur configuration.
- pour chaque module, un petit adaptateur qui va se charger de convertir les informations du fichier de configuration vers les classes de configuration, et vice-versa.

Ainsi, tu as réellement un couplage faible entre la configuration de tes modules et la gestion de ton fichier de configuration. Après tout, le module n’a que faire que le paramètre vienne d’un fichier, de la ligne de commande, soit codé en dur ou encore calculé à partir de l’âge du capitaine : tout ce qu’il a besoin de savoir, c’est sa valeur.

Citation:

---

Envoyé par sfarc

Oui effectivement j'aurais qu'un seul module mais ce qui m'embête, c'est que rien ne l'impose. Rien n'empêche un développeur un jour d'instancier un nouveau module son par exemple même si c'est pas très fute fute.

---

Ca, si le développeur fait une connerie, tu n'y peux rien ;)

Rend déjà ton module non copiable, non affectable.

Place bien un cartouche sur ton module qui indique explicitement qu'il ne doit y avoir qu'un module de créé par l'application.

Et si, malgré cela, le développeur ne sais pas lire, hé bien, tant pis pour lui :D

Citation:

---

Aussi, autre point, l'idée de passer en paramètre du constructeur le chemin du fichier de configuration à chaque module me gène un peu. Cela voudrait dire, que chaque module, ou plutôt chaque objet conf associé a la possibilité de connaître l'ensemble du fichier. Je réfléchie à une alternative pour ce point là ;).

---

Ne te bloque pas vraiment sur les paramètres que j'ai passé au constructeur de SoundModule.

L'exemple portait surtout sur le pimple idiome, car, rien n'empêche que le nom du fichier de configuration soit inscrit en dur dans le constructeur de SoundModule (ou meme de SoundConfig) ;)

Citation:

---

Envoyé par white_tentacle

De mon point de vue, un module doit se configurer… avec une structure qui lui est dédiée.

Dans l’idéal, tu vas donc avoir :
- un gestionnaire de settings, générique, qui s’occupe de la persistance (et donc, lecture / écriture du fichier de paramètres).
- des classes / modules qui prennent quelque part, soit dans le constructeur, soit dans une méthode init, une structure/classe dédiée à leur configuration.
- pour chaque module, un petit adaptateur qui va se charger de convertir les informations du fichier de configuration vers les classes de configuration, et vice-versa.

Ainsi, tu as réellement un couplage faible entre la configuration de tes modules et la gestion de ton fichier de configuration. Après tout, le module n’a que faire que le paramètre vienne d’un fichier, de la ligne de commande, soit codé en dur ou encore calculé à partir de l’âge du capitaine : tout ce qu’il a besoin de savoir, c’est sa valeur.

---

Exactement ;)

L'article met l'accent sur le fait que le singleton permet de faire deux choses
-Garantir l'unicité
-Permettre l’accès à l'instance de n'importe où
Mais on pourrais créer un speudo-singleton qui se contente de garantir l'unicité, en implémentant un singleton à la différence prêt que le "getInstance" renverrait NULL ou une exception si l'instance existe déjà. Après il reste toujours la variable globale déguisée, doit on réellement bannir l'utilisation des variables static ?

Citation:

---

Envoyé par bebaijhi

Après il reste toujours la variable globale déguisée, doit on réellement bannir l'utilisation des variables static ?

---

Je n'irai pas jusqu'à dire qu'il faut les bannir, mais il faut réellement se poser la question de savoir si l'on en a réellement besoin (AKA s'il n'y a vraiment pas d'alternative), surtout si c'est une variable non constante.

Que tu définisses une variable static const int xxMax pour indiquer une limite qui ne sera jamais atteinte est une chose qui peut sembler cohérente (toutes les instances de ta classe partagent la même valeur, et c'est une bonne chose).

Mais que tu crées une variable statique non constante qui peut, par définition, être modifiée depuis "n'importe où" dans le code n'ira jamais sans poser de problème. Ne serait-ce que parce que, justement, tu laisses la possibilité de la modifier depuis "n'importe où".

Or, à moins de définir une amitié pour permette à une seule classe de modifier l'état de ta variable statique, tu vas exposer les accesseurs sur le contenu de l'ensemble de ta configuration (il faut bien, si tu veux pouvoir en récupérer les valeurs ;)), quitte à ce qu'il n'y ait qu'une seule fonction qui remplisse office.

Mais tu exposeras également les mutateurs (ou la fonction unique qui en fait office), et donc, tu donneras de facto la possibilité de changer ces valeurs.

Et c'est à ce moment là que les problèmes apparaîtront, parce que tu en arriveras fatalement tôt ou tard à modifier l'une des valeurs à un endroit où tu n'aurais pas du le faire :P.

C'est pour cela que je n'ai rien contre le fait de regrouper, d'une manière ou d'une autre, toutes les informations de configuration d'un module en un point précis, mais que je dis qu'il faut veiller à ce que ces informations ne soient transmises qu'aux classes et fonction qui en ont besoin ;)

Citation:

---

Rend déjà ton module non copiable, non affectable.

---

Oui je vais déjà faire ça ;)
Mais le fait de faire confiance aux développeurs ne témoigne pas d'une faille dans la conception ?
C'est vraiment ce qui me gène. Pour moi, défini de la sorte, on peut avoir dans l'absolu plusieurs instances de la classe.

Voici l'implémentation que je propose suite à vos suggestions :

Code:

---

1 2 3 4 5 6 7 8 9 10

class QNetwork : public QModule { public : QNetwork() : QModule(), m_config(new QNetworkConfig()) {} ~QNetwork(); // se charge de détruire m_config   private : QNetworkConfig* m_config; }

---

Code:

---

1 2 3 4 5 6 7 8

class QNetworkConfig { public : QNetworkConfig();   private : quint16 m_port; }

---

Code:

---

1 2 3 4 5 6 7 8

QNetworkConfig::QNetworkConfig() , m_port(CFG_PARAM_PORT_DEFAULT_VALUE) { if (QConfig::load(CFG_FILE_NETWORK)) // Finalement, chaque module aura son propre fichier de config { QConfig::getParam<int>(CFG_PARAM_PORT, m_port); // Se serait mieux de spécialiser getParam en quint16 non ? } }

---

Et pour le chargement d'un fichier de configuration et la lecture de paramètres, j'ai tout de même conserver des méthodes statiques avec une variable statique privée pour le dom :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class QConfig { public : static bool load(const QString&);   template <typename T> static bool getParam(const QString&, T&);   private : static QDomDocument M_dom; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

bool getParam(const QString& key, T& value) { QDomElement root = M_dom.documentElement(); QDomNode node = root.firstChild(); QDomElement element; while (!node.isNull()) { element = node.toElement(); if (element.tagName() == key) { value = element.text(); return true; } }   return false; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

// Spécialisation pour les int template<> bool QConfig::getParam<int>(const QString& key, int& value) { bool ret; QString text; if (ret = getParam<QString>(key, text)) value = text.toInt(&ret);   return ret; }

---

Qu'en pensez-vous ? :)

Citation:

---

Envoyé par sfarc

Oui je vais déjà faire ça ;)
Mais le fait de faire confiance aux développeurs ne témoigne pas d'une faille dans la conception ?

---

A vrai dire, je ne vois pas pourquoi...

Il y a "toutes les chances" pour qu'il ne doive exister qu'une instance de tes différents modules, mais qu'est ce qui justifierait que ce ne soit pas le cas :question:

Qu'est ce qui pourrait empêcher le développeur de vouloir explicitement lancer deux instances particulière du même module :question:

En obligeant le développeur à n'en créer qu'une instance, tu prends une décision arbitraire qui, bien que cohérente de ton point de vue n'est peut être pas forcément en accord avec les besoins du développeur ;)

Signale lui bien que, normalement, une seule instance devrait suffire, mais, s'il a besoin d'en avoir plusieurs (pour quelque raison que ce soit ;)), pourquoi le lui refuser :question:

Citation:

---

C'est vraiment ce qui me gène. Pour moi, défini de la sorte, on peut avoir dans l'absolu plusieurs instances de la classe.

---

Effectivement, dans l'absolu, on peut envisager d'avoir plusieurs instances... Et pourquoi ne devrait-ce pas être le cas dans certaines situations bien particulières :question:

Citation:

---

Voici l'implémentation que je propose suite à vos suggestions :

Code:

---

1 2 3 4 5 6 7 8 9 10

class QNetwork : public QModule { public : QNetwork() : QModule(), m_config(new QNetworkConfig()) {} ~QNetwork(); // se charge de détruire m_config   private : QNetworkConfig* m_config; }

---

Code:

---

1 2 3 4 5 6 7 8

class QNetworkConfig { public : QNetworkConfig();   private : quint16 m_port; }

---

Code:

---

1 2 3 4 5 6 7 8

QNetworkConfig::QNetworkConfig() , m_port(CFG_PARAM_PORT_DEFAULT_VALUE) { if (QConfig::load(CFG_FILE_NETWORK)) // Finalement, chaque module aura son propre fichier de config { QConfig::getParam<int>(CFG_PARAM_PORT, m_port); // Se serait mieux de spécialiser getParam en quint16 non ? } }

---

---

je ne suis pas fan de l'utilisation des directive #define du préprocesseur :aie:

Tu as raison d'éviter les nombres magiques, mais tu devrais plutôt soit utiliser une valeur numérique réelle (un int, par exemple) constant, soit une valeur énumérée.

Cela t'évitera sans doute bien des problèmes si tu utilise cette valeur à mauvais escient ;)

Citation:

---

Et pour le chargement d'un fichier de configuration et la lecture de paramètres, j'ai tout de même conserver des méthodes statiques avec une variable statique privée pour le dom :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class QConfig { public : static bool load(const QString&);   template <typename T> static bool getParam(const QString&, T&);   private : static QDomDocument M_dom; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

bool getParam(const QString& key, T& value) { QDomElement root = M_dom.documentElement(); QDomNode node = root.firstChild(); QDomElement element; while (!node.isNull()) { element = node.toElement(); if (element.tagName() == key) { value = element.text(); return true; } }   return false; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

// Spécialisation pour les int template<> bool QConfig::getParam<int>(const QString& key, int& value) { bool ret; QString text; if (ret = getParam<QString>(key, text)) value = text.toInt(&ret);   return ret; }

---

Qu'en pensez-vous ? :)

---

Pourquoi rendre la fonction load et le document statiques :question:

A prior, tu as de toutes façons une configuration qui est créée. Autant appeler la fonction load depuis l'instance qui est créée, autrement, tu devras de toutes manières transmettre cette configuration en paramètre pour pouvoir la mettre à jour ;)

Citation:

---

En obligeant le développeur à n'en créer qu'une instance, tu prends une décision arbitraire qui, bien que cohérente de ton point de vue n'est peut être pas forcément en accord avec les besoins du développeur

---

Citation:

---

dans l'absolu, on peut envisager d'avoir plusieurs instances... Et pourquoi ne devrait-ce pas être le cas dans certaines situations bien particulières

---

Je comprends ce que tu veux dire. En fait, l'idée n'est pas de fournir une API à des développeurs mais plutôt de concevoir ma propre application, d'où ma gêne à laisser autant de liberté à d'éventuels développeurs de la revoir, quitte à ce que l'application perde de son sens.

Citation:

---

je ne suis pas fan de l'utilisation des directive #define du préprocesseur
tu devrais plutôt soit utiliser une valeur numérique réelle (un int, par exemple) constant, soit une valeur énumérée.
Cela t'évitera sans doute bien des problèmes si tu utilise cette valeur à mauvais escient

---

Qu'est ce que les valeurs numériques réelles apportent en plus ici ? un type précis pour le compilateur par exemple ?

Citation:

---

Pourquoi rendre la fonction load et le document statiques

---

Ici, pour chaque configuration de module, j'avais besoin d'une factorisation de code pour charger un fichier et récupérer les paramètres. Je ne me voyais pas définir un même objet config à instancier dans chaque configuration de module car je trouve ça redondant et je ne me voyais pas passer en paramètre une référence sur la config à chaque module. Tu avais envisagé l'une de ces solutions ?

Citation:

---

A prior, tu as de toutes façons une configuration qui est créée. Autant appeler la fonction load depuis l'instance qui est créée, autrement, tu devras de toutes manières transmettre cette configuration en paramètre pour pouvoir la mettre à jour

---

Tu veux dire appeler load depuis chaque configuration de module ?
Je ne vois pas bien ce que tu suggères ici :P.

Aussi, un point qui m'embête assez souvent dans ma conception, c'est le fait de ne pas pouvoir appeler depuis le constructeur des méthode virtuelles à cause de la vtable qui n'est pas encore créée. Je sais qu'il suffit de définir une méthode a appeler après le constructeur comme Init() mais ça m'embête de ne pas avoir, dés la construction de l'objet (seul appel du constructeur), l'objet entièrement initialisé et prêt. Comment vous faites pour contourner ce problème classique ?

Citation:

---

Envoyé par sfarc

Je comprends ce que tu veux dire. En fait, l'idée n'est pas de fournir une API à des développeurs mais plutôt de concevoir ma propre application, d'où ma gêne à laisser autant de liberté à d'éventuels développeurs de la revoir, quitte à ce que l'application perde de son sens.

---

Tu n'as pas vraiment à t'inquiéter de cela...

pour chaque module, tu auras une sorte de "façade" qui permettra à ce module d'interagir avec les autres.

Tu charges ta configuration au niveau de cette façade et tu veilles à ce que chaque fonctionnalité accessible depuis la façade fournisse aux différents éléments du module les données de configuration dont ils ont besoin pour fonctionner.

Ton module devient une sorte de "boite noire" au départ de laquelle seules les fonctionnalités exposées par la façade sont accessibles pour "le monde extérieur", et, si tu as besoin, à l'intérieur du module concerné, des fonctionnalités offertes par la façade, tu travailles avec des références et/ou des pointeurs.

Le seul endroit où le module est instancié, c'est d'office l'application (qui va utiliser différents modules). Tu n'as donc pas à t'inquiéter de rendre ton module unique, vu qu'il l'est déjà de facto ;)

Et si un développeur décide de créer une deuxième instance de ton module, a priori, soit il fait une erreur dont il se rendra rapidement compte, soit il sait pertinemment ce qu'il fait. Quoi qu'il en soit, cela ne te concerne pas ;)

Citation:

---

Qu'est ce que les valeurs numériques réelles apportent en plus ici ? un type précis pour le compilateur par exemple ?

---

Essentiellement, oui.

Citation:

---

Ici, pour chaque configuration de module, j'avais besoin d'une factorisation de code pour charger un fichier et récupérer les paramètres. Je ne me voyais pas définir un même objet config à instancier dans chaque configuration de module car je trouve ça redondant et je ne me voyais pas passer en paramètre une référence sur la config à chaque module. Tu avais envisagé l'une de ces solutions ?

---

Bien sur que tu ne vas pas instancier une configuration par information que contient ton fichier de config :D (enfin, tu vas instancier une ConfigurationInfo quand même, quelle qu'en soit la forme).

Mais, comme je te l'ai dit plus haut, le module son n'a absolument que faire des informations de configuration du module réseau qui n'a absolument que faire des informations de configuration du module graphique qui n'a absolument que faire des informations de configuration du module métier.

Que les informations de configuration soient représentée sous une forme relativement commune (comprends : qu'une information de couleur par exemple soit représentée sous la même forme quel que soit le module qui l'utilise) est normal et tout à fait cohérent.

Que les informations de configuration soient centralisées dans un fichier unique est envisageable, mais tu dois veiller à ce que chaque module ne dispose que des informations qui le concernent directement ;)

Citation:

---

Tu veux dire appeler load depuis chaque configuration de module ?
Je ne vois pas bien ce que tu suggères ici :P.

---

Effectivement, c'est ce que je suggère.

Si tu décides de travailler avec un fichier xml, grand bien te fasse. Tu peux tout à fait factoriser le code de récupération / création des différentes informations de configuration. Mais pas au niveau de la configuration elle-même : au niveau "du système responsable de la subsistance / sérialisation / désérialisation" de tes informations de connexions.

Et cela peut, parfaitement, aussi prendre la forme d'une fonction libre. Il n'est pas indispensable de vouloir respecter à tout prix le paradigme OO plus que de raison ;)

D'une certaine manière, c'est ce que Stroutroup reproche au terme paradigme : si on en croit wikipedia, ce sont des rails dont il ne faut pas s'écarter. Or, C++ est multi - paradigme. Ce qui fait que tu peux choisir le meilleur de tous les paradigmes possibles pour résoudre un problème particulier ;)

Citation:

---

Aussi, un point qui m'embête assez souvent dans ma conception, c'est le fait de ne pas pouvoir appeler depuis le constructeur des méthode virtuelles à cause de la vtable qui n'est pas encore créée. Je sais qu'il suffit de définir une méthode a appeler après le constructeur comme Init() mais ça m'embête de ne pas avoir, dés la construction de l'objet (seul appel du constructeur), l'objet entièrement initialisé et prêt. Comment vous faites pour contourner ce problème classique ?

---

1- Je respecte scrupuleusement le SRP (Single Responsability Principle ou, si tu préfères, le principe de la responsabilité unique) : je définis clairement la responsabilité de chaque classe afin de savoir quel(s) service(s) je suis en droit d'attendre

2- Je me méfie comme de la peste des termes "gérer", "manager", "système" et autres : Bien souvent, ce sont des termes qui méritent des précisions et qui englobent plusieurs responsabilités qui peuvent être déléguées à plusieurs classes distinctes.

3- je ne fais jamais dépendre une classe de base d'une donnée d'une classe dérivée. Au pire, je fais l'inverse.

4 - j'utilise tous les outils à ma disposition : le paradigme impératif, le paradigme OO, le paradigme générique en fonction des circonstances afin d'en tirer le meilleur parti et les différents patrons de conception mis à ma disposition (à l'exception notable du singleton :D)

5- je respecte l'OCP (Open/Close Principle)

6- De manière générale, j'ai six dieux et une profession de foi : la loi de Déméter, les principe SOLID et la citation de David Wheeler : Tout problème en informatique peut être résolu par une indirection supplémentaire (mais en occasionne souvent un autre)

Y en a sans doute d'autres, mais si tu suis déjà ces six points, tu auras fait un très grand pas dans la bonne direction ;)

Merci encore koala01 pour tes précieux conseils ;)

Voici ma nouvelle proposition :

Code:

---

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

class QNetworkFacade { public : QNetworkFacade(); ~QNetworkFacade();   bool Listen() const;   private : QNetworkConfig* m_config; QUdpServer* m_udpServer; };

---

Code:

---

1 2 3 4 5 6

QNetworkFacade::QNetworkFacade() : m_config(new QNetworkConfig()) , m_udpServer(new QUdpServer()) { m_config->load(CFG_NETWORK); }

---

Code:

---

1 2 3 4 5 6 7

bool QNetworkFacade::Listen() const { if (!m_udpServer) return false;   return m_udpServer->bind(QHostAddress::LocalHost, m_config->m_port); }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class QUdpServer : public QObject { Q_OBJECT   public : QUdpServer(QObject* parent = 0); ~QUdpServer();   bool bind(const QHostAddress&, const quint16) const;   private slots : void readData();   private : void initConnections() const;   private : QUdpSocket* m_socket; };

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

class QModuleConfig { public : virtual ~QModuleConfig(); virtual bool load(const QString&) = 0;   protected : bool loadDom(const QString&);   template <typename T> bool getParam(const QString& key, T& value) { // Get param from dom and return error code }   protected : QDomDocument* m_dom; };   template<> bool QModuleConfig::getParam<ushort>(const QString&, ushort&);

---

Code:

---

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

class QNetworkConfig : public QModuleConfig { friend class QNetworkFacade;   public : QNetworkConfig();   protected : bool load(const QString&);   private : quint16 m_port; };

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

const QString CFG_PARAM_PORT = "Port"; const quint16 CFG_PARAM_PORT_DEFAULT = 5000;   QNetworkConfig::QNetworkConfig() : QModuleConfig() , m_port(CFG_PARAM_PORT_DEFAULT) {}   bool QNetworkConfig::load(const QString& file) { if (!loadDom(file)) return false;   getParam<ushort>(CFG_PARAM_PORT, m_port);   return true; }

---

J'ai toutefois un problème au niveau de mon objet QAppli. Quand je vais appeler Listen, je voudrais par exemple récupérer le buffer pour le décoder et construire un modèle qui sera utilisé par l'IHM..

Je vais donc avoir un autre module Graphic, et un module pour décoder et construire mon modèle. Il faudrait donc que je créé un point d'entrée dans le module Network comme un pointeur de fonction en argument de la méthode Listen pour appeler la callback au moment voulu ?

J'imagine qu'il faudra procéder de la sorte aussi entre le modèle et la vue, à savoir, passer éventuellement des callbacks ou des pointeurs pour les connecter ?

Autre problème, dans ma spécialisation de template pour la méthode getParam dans QModuleConfig, je vois via l'intellisense que ma méthode getParam est publique (car spécialisation publique même si la méthode générique est censée être protégée). Est-ce normal ?

Merci :)

C'est déjà beaucoup mieux ;)

Citation:

---

J'ai toutefois un problème au niveau de mon objet QAppli. Quand je vais appeler Listen, je voudrais par exemple récupérer le buffer pour le décoder et construire un modèle qui sera utilisé par l'IHM..

---

Ben, ce serait bien le rôle du module réseau que de créer / mettre à jour le modèle avec les données qu'il obtient au travers du client UDP, tu ne crois pas :question:

Ou, du moins de faire la "transition" entre les données telles qu'elles sont reçues sur le réseau et le module "métier" (le module qui contient les données spécifiques à ton application).

Note qu'il peut parfaitement y avoir quelque chose "entre les deux" (un ou plusieurs module(s) "modèle" auxquels les autres modules viendraient se rattacher) ;)

Citation:

---

Je vais donc avoir un autre module Graphic, et un module pour décoder et construire mon modèle.

---

Tu dois, surtout, avoir un module "Model" qui s'occupe de fournir les modèles "à qui en a besoin", qui est sans doute le seul à manipuler les données métier (plusieurs façades distinctes sont envisageables) et qui fait le lien avec les données d'une part et les autres modules d'autre part.

Au final, tu pourrais avoir quelque chose comme (désolé, ASCII art ;))

Code:

---

1 2 3 4 5 6 7 8 9 10

Reseau / \ // ??? | \ / Model -- > Metier / \ | \ / IHM

---

(Les flèches indiquent le sens des communications entre les modules)

En effet, le module "réseau" peut parfaitement être considéré comme "une vue particulière" dans le sens où elle n'est pas affichée mais... transmise sur le web ;)

Et, comme tu est (il me semble) sous Qt, tu dispose des QAbstractModel et autres joyeusetés du genre qui, justement, sont prévus pour fonctionner de concert.

Tout ce que tu dois pouvoir passer au module réseau (et au module IHM), c'est un pointeur vers le modèle créé par le module Model, (le même modèle pour les deux, simplement "manipulé" et utilisé différemment) ;)

Citation:

---

Il faudrait donc que je créé un point d'entrée dans le module Network comme un pointeur de fonction en argument de la méthode Listen pour appeler la callback au moment voulu ?

---

Quelle horreur !!!

Pourquoi faire des callbacks :question:

Tu fournis un pointeur (ou une référence) vers le modèle (dérivé de QAbstractModel) créé par le module Model (ou carrement une référence vers une partie de la façade de celui-ci, si tu veux que ce soit le module Model qui s'occupe réellement du modèle) et basta: ton module réseau et ton module IHM n'ont qu'à s'occuper d'appeler les fonctions qui vont bien, sur le modèle ou sur la façade vers le module Model (je préférerais utiliser la façade vers le module, ca évitera les problèmes liés à l'évolution des éléments ;))

Citation:

---

Autre problème, dans ma spécialisation de template pour la méthode getParam dans QModuleConfig, je vois via l'intellisense que ma méthode getParam est publique (car spécialisation publique même si la méthode générique est censée être protégée). Est-ce normal ?

---

Ce n'est pas forcément "normal" (généralement l'intellisense sait la visibilité des différents membres d'une classe), mais c'est "possible"...

Quoi qu'il en soit, ce n'est pas "catastrophique" :D

Ceci dit, étant donné que seul le module aura connaissance de la configuration, pourquoi te faire ch...er à créer une amitié (de très mauvais aloi ici) et à placer ta fonction getParam dans l'accessibilité protégée :question:

Pourquoi ne pas virer cette amitié et la placer en accessibilité publique :question:

Citation:

---

Ceci dit, étant donné que seul le module aura connaissance de la configuration, pourquoi te faire ch...er à créer une amitié (de très mauvais aloi ici) et à placer ta fonction getParam dans l'accessibilité protégée

---

Effectivement, j'ai mis en public le paramètre port. Par contre, j'ai laissé en protégée la méthode getParam puisque je n'ai pas envie qu'on s'en sert de manière indirecte dans la façade à la place d'appeler les membres publics.

Il me reste un petit problème sur la dépendance entre façades.
Ici, je dois spécifier mon modèle (façade model) à ma vue (façade graphic). J'ai donc :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class QGraphicFacade : public Common::QFacade { public : QGraphicFacade(); ~QGraphicFacade();   void setModel(Model::QModelFacade*);   private : QTraceTableView* m_traceTableView; };

---

Code:

---

1 2 3 4 5 6 7

void QGraphicFacade::setModel(Model::QModelFacade* modelFacade) { if (!m_traceTableView) return;   // m_traceTableView->setModel( ??? ); }

---

En passant par les façades, je risque de me retrouver souvent dans le cas ou j'ai besoin de récupérer un objet de celle-ci pour faire des liaisons depuis une autre façade. Que faire ? Définir des accesseurs ? Une amitié ?

Autre point, je me suis rendu compte que je n'utilisais pas les modules (Network, Graphic, Model) mais que c'est mes façades qui contiennent directement tous les objets nécessaires aux traitements des informations. Je m'y suis peut être mal pris mais dans mon cas, ajouter un niveau d'abstraction avec le module (déplacer tous les objets dans le module plutôt que de les laisser dans la façade) ajouterait une indirection supplémentaire et serait donc redondant. Un exemple de ce que j'ai :

Code:

---

1 2 3 4 5 6 7

bool QNetworkFacade::listen() const { if (!m_udpServer) // objet défini dans la façade et non dans le module QNetwork return false;   return m_udpServer->bind(QHostAddress::LocalHost, m_config->m_port); }

---

Merci ;)

Citation:

---

Envoyé par koala01

Or, une variable statique n'est jamais qu'une variable globale "Facon du chef, enrobée d'accessibilité sur lit de mystère, avec sa sauce OO" :D

---

c'est tout à fait exact :D

En fait, l'idée est, vraiment, de veiller à respecter scrupuleusement le D de SOLID qui est mis pour Dependency Inversion Principle, ou, si tu préfères en français, le principe d'inversion des dépendances.

Autrement dit, chaque module ne doit exposer, au travers d'une façade, que le stricte nécessaire pour pouvoir être utilisé.

Et, comme je te l'ai dit, le module "réseau" peut très facilement être considéré comme une "vue particulière", dans le sens où, tout ce qu'elle fait, c'est faire la transition entre des données externes (issues du réseau) à transmettre au modèle et des données internes (issues du modèle) à transmettre au réseau.

Or, tu dispose d'un système génial pour faire communiquer les modèles avec les différentes vues : le système de signaux et de slots.

La dépendance entre le module "modèles" et le module "réseau" peut donc être quasiment nulle.

Je m'explique :

Tu devrais avoir différents modules dont on pourrait dresser une liste proche de

• Business : ce module ne contient que des données métier pures et dures
• Modifications : ce module contient des données qui n'entrent pas tout à fait dans la définition de "données métier", mais qui permettent de manipuler et de modifier celles-ci (par exemple : l'identifiant d'un objet vendu et le prix obtenu lors de la transaction, l'identifiant du monstre attaqué et du sort (ou de l'arme) utilisé(e), ...)
• Models : ce module contient les différents modèles que tu vas manipuler dans ton application
• Views : ce module reprend l'ensemble des vue "graphiques" que tu feras afficher par ton application
• Network : ce module s'occupe de gérer la connectivité avec le réseau.
• Sound : ce module s'occupe de gérer tout l'aspect sonore de ton application.
• Y en a peut être d'autres ;)

Comment va-t-il s'y prendre :question: il va réagir à certains signaux qui sont émis par certains modules (essentiellement le module Network et le module Views).

Comment pourra-t-il réagir à ces signaux :question: en exposant au travers de sa façade un certain nombre de slots qui pourront être connectés aux différents signaux émis par les différents modules.

Pour cet aspect spécifique, la façade du module Models se contente donc d'exposer les différents slots susceptibles d'intéresser les différents modèles et de faire la jonction entre ces slots exposés et les slots des modèles en question.

D'un autre coté, les modifications apportées par le module Models au business sont, elles aussi, susceptibles d'occasionner l'émission de signaux, susceptibles d'intéresser des modules comme Network, Views ou sound.

La façade de Models va donc exposer ces signaux "intéressants" (comprends : qui sont susceptibles d'intéresser d'autres modules que le module Models) et faire la jonction entre les signaux émis par les différents modèles et ces signaux exposés.

La façade du module Sound exposera essentiellement des slots, correspondant aux différentes réactions sonores envisagées.

La façade du module Network et celle du module Views exposera un certain nombre de slots qui seront connectés aux "signaux intéressants" (du point de vue du réseau) émis par le module Models afin de permettre l'émission des modifications apportées "en local" ainsi qu'un certain nombre de signaux -- auxquels viendront se connecter certains slots du module "Models" -- afin de permettre la prise en compte des informations reçues au travers du réseau.

Enfin, il faut "juste" prendre en compte le fait que les vues "graphiques" sont généralement directement reliées à un modèle particulier.

L'idée est donc peut être de faire en sorte que la façade de Views puisse permettre d'accéder à une vue particulière et que celle de Models puisse permettre de faire la relation entre une vue et le modèle à utiliser.

Au final, tous les modules dépendent du module "Modifications" car ce ne sont que des "structures simples" qui représentent les modifications à apporter.

La façade du module Models peut ressembler à quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

class ModelsFacade{ public: ModelsFacade(){ createModels(); connectSignals(); connectSlots(); } setModelToView(View * view, ModelId id) const{ Model * model =/* trouver le modèle correspondant */; view->setModel(model); } /* peut être quelques autres fonctions utilitaires */ signals : /* les différents signaux à exposer */ public slots: /* les différents slots à exposer */ private: void createModels(){ /* on crée les modèles et on les ajoute à la map */ } void connectSignals(){ /* on connecte les signaux des différents modèles   * aux signaux exposés par la facade   */ } void connectSlots(){ /* on connecte les slots exposés par la façade aux   * slots des différents modèles   */ } /* ce n'est qu'un exemple :D */ std::map<ModelId, QAbstractModel *> allModels_; /* le fameux pimple idiome dont j'ai parlé plus haut */ ModelsConfig * config_; };

---

Pour le module Network, on exposerait essentiellement des signaux et des slots avec, peut être, une ou deux fonctions "utilitaires", sous une forme proche de

Code:

---

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

class NetworkFacade{ public: NetworkFacade(){ createConnection(); } /* peut être une ou deux fonctions utilitaires ici */ signals : /* les différents signaux susceptibles d'être émis */ public slots : /* les différents slots de réaction intéressants */ private: NetworkConnection connection_; /* le fameux pimple idiome dont j'ai parlé plus haut */ NetwokConfig * config_; };

---

et la façade du module Views pourrait ressembler à quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

class ViewsFacade{ public: ViewFacade(){ createViews(); connectSignals(); connectSlots(); } View * getViewById(ViewId id){ View * found = /* recherche de la vue identifiée par id */ return found; } signals : /* les différents signaux exposés */   signals : /* les différents signaux à exposer */ public slots: /* les différents slots à exposer */ private: void createView(){ /* on crée les vues et on les ajoute à la map */ } void connectSignals(){ /* on connecte les signaux des différentes vues   * aux signaux exposés par la facade   */ } void connectSlots(){ /* on connecte les slots exposés par la façade aux   * slots des différents modèles   */ } /* ce n'est qu'un exemple :D */ std::map<ViewId, QAbstractView *> allView_; /* le fameux pimple idiome dont j'ai parlé plus haut */ ViewsConfig * config_; };

---

Et ton application pourrait parfaitement ressembler à quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

class Application{ public: Application(){ setupViewModels(); connectSignals(); } private: void setupViewModels(){ /* on récupère les différentes vues de View et on définit leur modèle   * au travers de models_.setModelToView */ } void connectSignals(){ /* on connecte les signaux émis par les différentes façades aux slots   * des façades intéressées   */ } ModelFacade models_; ViewFacade views_; NetworkFacade network_; SoundNetwork sound_; };

---

Sous une telle forme, tes trois modules peuvent fonctionner de manière strictement autonome.

Mieux encore, tu peux développer tes différents modules dans l'ordre que tu souhaites, y compris par "petit morceau", sans que cela n'influe en rien sur le fonctionnement du reste ;)

Bon, bien sur, il faudra toujours tenir compte du module Modifications qui est un module "central" (comprends : dont dépendent tous les autres) et du module Business lorsque tu développera ton module Models, mais ce sont les deux seuls points de liaison entre les différents modules auxquels tu devras être attentif.

Elle est pas belle la vie :question: :D

Tout paraît plus facile avec tes explications :P.

Juste deux points qui sont encore un peu flous :
1) Le module Business contiendra uniquement la déclaration des données métiers c'est bien ça ?
2) Le module Modifications n'est pas très clair pour moi. En fait, je ne vois pas bien son intérêt.

Si je prends l'exemple de récupération de trames réseaux pour le remplissage d'un modèle de données, dois-je faire :

a) Le module Network récupère les trames, les décode, envoie un signal avec les données décodés, signal qui est connecté à un slot d'un modèle du module Model (ou encore à un slot de la façade du module Model qui se charge de passer les informations aux modèles voulus).

b) Le module Network récupère les trames, les décode, envoie un signal avec les données décodés, signal connecté à un slot qui met à jour une collection des données récupérées, qui, à sa mise à jour, prévient à son tour le modèle lié à cette collection (le modèle possède un pointeur sur la collection par exemple).

Dans ces deux cas, je ne vois pas vraiment ou va intervenir le module Modification.

Merci encore :)

Citation:

---

Envoyé par sfarc

Tout paraît plus facile avec tes explications :P.

Juste deux points qui sont encore un peu flous :
1) Le module Business contiendra uniquement la déclaration des données métiers c'est bien ça ?

---

Et de "tout ce qui va bien pour les manipuler, oui.

Citation:

---

2) Le module Modifications n'est pas très clair pour moi. En fait, je ne vois pas bien son intérêt.

---

Hé bien, pose toi la question de savoir ce que tu vas envoyer sur le réseau.

Vas-tu systématiquement envoyer toutes tes données métiers :question:

Ou vas-tu plutôt envoyer uniquement les informations qui permettront de reproduire la modification qui a été apportée entre un instant T et l'instant T+1 :question:

Il semble beaucoup plus logique de ne renvoyer que "ce qui a changé" entre T et T+1, et encore, pas forcément la donnée en entier mais juste la "différence" entre l'état de la donnée telle qu'elle était à l'instant T et l'état dans lequel elle se trouve à T+1.

Cela te permettra de n'envoyer que le "stricte minimum" sur le réseau et d'éviter de le surcharger avec un tas d'informations dont le récepteur n'a que faire.

C'est d'autant plus justifié que c'est, en gros, la manière de fonctionner des signaux et des slots très spécifiques : quand un signal indique que l'index sélectionné d'un combobox a été modifié, il envoie juste un signal selectedIndexChanged( nouvel index), et le slot qui gère ce signal sait comment réagir en conséquence ;)

Citation:

---

Si je prends l'exemple de récupération de trames réseaux pour le remplissage d'un modèle de données, dois-je faire :

a) Le module Network récupère les trames, les décode, envoie un signal avec les données décodés, signal qui est connecté à un slot d'un modèle du module Model (ou encore à un slot de la façade du module Model qui se charge de passer les informations aux modèles voulus).

b) Le module Network récupère les trames, les décode, envoie un signal avec les données décodés, signal connecté à un slot qui met à jour une collection des données récupérées, qui, à sa mise à jour, prévient à son tour le modèle lié à cette collection (le modèle possède un pointeur sur la collection par exemple).

Dans ces deux cas, je ne vois pas vraiment ou va intervenir le module Modification.

---

Encore une fois, pose toi la question de ce que le module Network récupère comme trame.

Il va récupérer des données, certes, mais il n'y a aucun sens à ce qu'il récupère à chaque fois l'ensemble des données métier, même si cela se limite au données métier modifiées.

Il va juste obtenir la différence entre l'état des données métier à l'instant T et celui à l'instant T+1. Et il doit juste décoder cette différence.

Et son rôle s'arrête là : à émettre un signal qui sera "porteur" de la différence à appliquer.

Parce que c'est le rôle du module "Model" de s'assurer que cette différence est cohérente et d'appliquer cette différence au données métier.

Et parce que c'est aussi ce qui va se passer au niveau graphique, en réactions aux différents événement comme le clique de la souris ou l'utilisation du clavier ;)

Maintenant, je parle de "module" de modifications à apporter, c'est eput etre un peu excessif.

Ce peut très bien n'être que l'ensemble des types primitifs utilisés ;)... Tout comme ce peut être des structures qui donnent un sens particulier à ces types primitifs en fonction de la différence à appliquer :D

Citation:

---

Vas-tu systématiquement envoyer toutes tes données métiers

Ou vas-tu plutôt envoyer uniquement les informations qui permettront de reproduire la modification qui a été apportée entre un instant T et l'instant T+1

---

L'idée est vraiment de récupérer par le réseau des traces donc effectivement, une fois qu'une trace est reçue avec ses infos (message, ligne, fichier, type de trace, ...), elle est insérée dans une liste au niveau des données.
D'ailleurs au passage, la communication est unilatérale (réseau -> appli) puisque c'est surtout une application d'affichage de données (traces ici).

Pour la question sur le meilleur moyen de procédé, j'ai dû mal m'exprimer :P. Ce que je voulais en fait savoir, c'est, est-il mieux de découpler le modèle (QTableModel) des données (liste des traces) ou de tout regrouper dans le modèle au niveau du module Model ? Quand je parlais de signal envoyé par le module Network à la liste des traces, je comptais uniquement insérer la nouvelle trace et prévenir le modèle qui à un pointeur sur cette liste plutôt que de remettre à jour l'ensemble de la liste.

Voici un exemple de ce que j'appelle couplage entre les donneés et le modèle :

Code:

---

1 2 3 4 5 6

template <typename T> class QDataTableModel : public QAbstractTableModel { protected : QList<const T*> m_data; // Directement au niveau du modèle };

---

Citation:

---

Parce que c'est le rôle du module "Model" de s'assurer que cette différence est cohérente et d'appliquer cette différence au données métier.

---

Ici, tu as l'air de coupler la liste des traces directement au modèle concernant dans le module Model donc.

Citation:

---

Maintenant, je parle de "module" de modifications à apporter, c'est eput etre un peu excessif.

Ce peut très bien n'être que l'ensemble des types primitifs utilisés ... Tout comme ce peut être des structures qui donnent un sens particulier à ces types primitifs en fonction de la différence à appliquer

---

Mais pour moi les types primitifs sont déjà définis dans le module Business en fait.

Citation:

---

Envoyé par sfarc

L'idée est vraiment de récupérer par le réseau des traces donc effectivement, une fois qu'une trace est reçue avec ses infos (message, ligne, fichier, type de trace, ...), elle est insérée dans une liste au niveau des données.
D'ailleurs au passage, la communication est unilatérale (réseau -> appli) puisque c'est surtout une application d'affichage de données (traces ici).

---

Ah, oui, mais quand tu auras tout dit... je saurai tout :D

Moi, je partais sur une application plus "mmo" qui implique une communication bidirectionnelle :P.

Ceci dit, le principe reste toujours le même ;)

Citation:

---

Pour la question sur le meilleur moyen de procédé, j'ai dû mal m'exprimer :P. Ce que je voulais en fait savoir, c'est, est-il mieux de découpler le modèle (QTableModel) des données (liste des traces) ou de tout regrouper dans le modèle au niveau du module Model ? Quand je parlais de signal envoyé par le module Network à la liste des traces, je comptais uniquement insérer la nouvelle trace et prévenir le modèle qui à un pointeur sur cette liste plutôt que de remettre à jour l'ensemble de la liste.

---

La règle d'or, c'est que chaque élément doit avoir sa responsabilité propre.

Si tu as "quelque chose" dont la responsabilité est de récupérer des données depuis le réseau, elle ne doit faire que ca, et envoyer les données "à qui de droit".

"Qui de droit", en l'occurrence, c'est "quelque chose" qui est utilisé par le modèle, dont la responsabilité est de maintenir ces données "en place", vu que la responsabilité du modèle est la "communication interne" entre les données métiers d'une part et les différentes vues.

Au final, le module Network "écoute" le réseau et décode les informations qu'il reçoit.

Quand il a reçu une information, il émet un signal qui indique "j'ai reçu telle information (même si c'est toujours le même type d'info :D), à vous de vous en occuper".

Ce signal est intercepté par le module Model qui va prendre les mesures adéquates, à savoir:

1. Demander à un objet dont la responsabilité est le maintient des informations de rajouter l'information reçue à la liste (*)
2. émettre un signal indiquant aux vues qu'il est temps de se mettre à jour.

(*) La "gestion" de la liste des traces devrait, idéalement, échoir à une classe du module Business, totalement indépendant de tout ce qui a trait aux vues et aux modèle.

En allant un peu plus loin, on pourrait presque dire que tu devrais n'utiliser que ce qui est disponible dans l'espace de noms std, histoire, pourquoi pas, de pouvoir décider "à n'importe quel moment" de lancer un projet parallèle utilisant une autre bibliothèque graphique, par exemple, en n'ayant que ce qui utilise les possibilités de cette bibliothèque à mettre en place (ou plutôt, en pouvant récupérer tout le module Business) sans avoir à te poser de question ;).

C'est le but de l'idiome modèle vue contrôleur, c'est sa raison d'être : permettre de dégager tout ce qui a trait au métier de tout le reste ;)

Citation:

---

Voici un exemple de ce que j'appelle couplage entre les donneés et le modèle :

Code:

---

1 2 3 4 5 6

template <typename T> class QDataTableModel : public QAbstractTableModel { protected : QList<const T*> m_data; // Directement au niveau du modèle };

---

Ici, tu as l'air de coupler la liste des traces directement au modèle concernant dans le module Model donc.


Mais pour moi les types primitifs sont déjà définis dans le module Business en fait.

---

En fait, ici, tes données métier sont au final très limitées, et tu n'as, effectivement, pas besoin du module "modifications" dont je parlais plus haut.

En gros, ton module Business va se limiter à quelque chose comme

1. une structure reprenant la date, l'heure, le niveau de gravité de la trace, un message et quelques informations connexes en cas de besoin
2. une classe qui gère les différentes instances de la structure décrite en (1)
3. peut être quelques énumérations et quelques tableaux d'équivalence (pour avoir un aperçu "textuel" des différentes valeurs énumérées)

Mais, et j'insiste sur ce point, la seule "entrée" par laquelle le module Model accède au données métier devrait être l'interface publique de cette classe qui gères les différentes instances de trace ;)

Finalement, à peu de chose près, la façade de ton module correspond à cette fameuse classe qui s'occupe de la gestion des trace ;)

Bonjour,

J'espère que vous avez passé de bonnes fêtes ;-)

Citation:

---

Ah, oui, mais quand tu auras tout dit... je saurai tout :D

---

Je m'en suis rendu compte au vu de tes réponses oui :P. En fait dans mon cas, c'est plutôt minimaliste effectivement. C'est comme pour le modèle, étant donné que pour cette application, il va se limiter à un "QTableModel", je n'ai pas vraiment besoin de définir une map dans ma façade. Mais bon, l'idée reste la même ça c'est sûr :)

Citation:

---

Ce signal est intercepté par le module Model qui va prendre les mesures adéquates, à savoir:
- Demander à un objet dont la responsabilité est le maintient des informations de rajouter l'information reçue à la liste (*)
- émettre un signal indiquant aux vues qu'il est temps de se mettre à jour.
(*) La "gestion" de la liste des traces devrait, idéalement, échoir à une classe du module Business, totalement indépendant de tout ce qui a trait aux vues et aux modèle.

---

Ok donc ma façade du module Business pourrait ressembler à :

Code:

---

1 2 3 4 5 6 7 8

class QBusinessFacade { public : void setDataToModel(QModelFacade*);   private : QTraceCollection* m_data; }

---

En considérant pour simplifier qu'on ait que des données de trace.
Une fois que le modèle connait les données, il peut alors les manipuler et mettre à jour la vue si nécessaire.

Merci ;)

Citation:

---

Envoyé par sfarc

Ok donc ma façade du module Business pourrait ressembler à :

Code:

---

1 2 3 4 5 6 7 8

class QBusinessFacade { public : void setDataToModel(QModelFacade*);   private : QTraceCollection* m_data; }

---

En considérant pour simplifier qu'on ait que des données de trace.
Une fois que le modèle connait les données, il peut alors les manipuler et mettre à jour la vue si nécessaire.

---

Noonn!!!

Ton modèle dois connaître le business mais le business doit être totalement indépendant (y compris au travers de la façade) du modèle.

Dans l'ordre des dépendances, le modèle dépend du business, le module réseau dépend d'une partie du business (pour les traces en elles-même) et le module vue dépend du modèle. Mais business ne dépend d'aucun module et, pour aller plus loin, il ne devrait même pas dépendre de Qt.

Dans l'idéal, ton business n'utiliserait que des classes comme std::(w)string, std::vector, std:map ou des type "personnels" ;) (mais là, c'est mon côté puriste qui parle et il est un peu radical :D )

Citation:

---

le business doit être totalement indépendant (y compris au travers de la façade) du modèle.

---

Ok ça parait logique dans le fond mais du coup, à quoi va servir la façade du module business ?
Il faudrait au moins que je puisse exposer dans ce cas là les données, à savoir ici la collection des traces par exemple, pour que la façade du module modèle puisse les associer au modèle voulu.

Citation:

---

pour aller plus loin, il ne devrait même pas dépendre de Qt.

---

C'est vrai que ce serait l'idéal ;)

Citation:

---

Envoyé par sfarc

Ok ça parait logique dans le fond mais du coup, à quoi va servir la façade du module business ?

---

En fait, la loi de Déméter s'applique aussi bien aux différents types qu'aux différents modules.

La partie métier s'occupe de gérer les données "brutes".

Dans ton cas, tu as deux types de données : Une classe (ou une structure) qui correspond à une ligne dans le fichier log et une classe qui permet de maintenir (et d'accéder à ) l'ensemble des lignes qui ont été lues dans le fichier log.

On se fout pas mal, au niveau du module Business, de savoir d'où viennent ces données!!! Elle pourraient tout aussi bien avoir été lue sur le disque dur local que récupérées au travers du réseau.

Tout ce que tu sais, c'est que tu vas manipuler des "traces" issues "de quelque part", et que tu dois donc être en mesure de les garder en mémoire ;).

Le module Model a deux choses à faire :
D'un coté, il doit être en mesure de rajouter les lignes de trace qui lui viennent "de n'importe où" (ici aussi, on se fout pas mal de l'origine de ces traces ;)).Et de l'autre, il doit pouvoir récupérer ces données afin de les transmettre à la vue qui s'occupera de les afficher.

Bien sûr, lorsqu'il va au passage sans doute décider de la ligne, de la colonne ou de la couleur qui sera utilisée pour afficher un des éléments de la trace, mais le business n'a aucun besoin de connaître ces informations.

Le modèle a donc besoin de quatre choses qui viennent du module buisness, ni plus, ni moins (alors que le module business en utilise sans doute d'avantage ;))
La structure de ta trace, dont il utilisera certaines parties afin de transmettre ses ordres à la vue.
Une fonction qui lui permette d'ajouter une trace parce que c'est le module Model qui décidera de rajouter une nouvelle information.
Une fonction qui permette de savoir combien de traces le business contient
Une fonction qui permette au modèle d'accéder à une trace bien particulière, par exemple, sur base d'un numéro incrémenté.

En effet, si le log dure assez longtemps, le modèle n'a sans doute que faire de 153 497 premières lignes de log, et il pourrait très bien se contenter des 20 dernières.

Il n'a même pas besoin d'utiliser un itérateur! il a juste à s'occuper de calculer le "numéro" de la trace qui l'intéresse sur base du nombre de trace que le business contient.

Autrement dit, ton modèle fonctionnera sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void ilFautAjouterUneTrace( Trace const & t){ business.ajouteLaTrace(t); } void jeVeuxLesVingtDernieresTraces(){ size_t total =business.nombreDeTraces(); size_t premiereTrace = (total >20 ? total-20 : 0); for(size_t i = premiereTrace; i<total; ++i){ Trace const t = business.donneMoiLaTrace(i); /* ... */ } }

---

Chaque fois que tu vois business apparaitre, c'est quelque chose qui doit être exposé par la façade du module en question, mais il ne faut strictement rien de plus ;)

Citation:

---

Il faudrait au moins que je puisse exposer dans ce cas là les données, à savoir ici la collection des traces par exemple, pour que la façade du module modèle puisse les associer au modèle voulu.

---

Non, je viens de t'en donner la preuve ;)

Effectivement, il suffit d'exposer des méthodes de la façade business pour que la façade modèle puisse mettre à jour les données brutes sans pour autant les exposer ;)

Dernier point, pour revenir sur ton ancienne réponse :

Citation:

---

Dans l'ordre des dépendances, le modèle dépend du business, le module réseau dépend d'une partie du business (pour les traces en elles-même) et le module vue dépend du modèle. Mais business ne dépend d'aucun module et, pour aller plus loin, il ne devrait même pas dépendre de Qt.

---

Seulement, tu proposes dans la conception de mettre dans la façade du modèle une méthode SetModelToView pour associer à la vue un modèle. Dans ce cas, la façade du modèle dépendrait donc de la vue (paramètre de la méthode).
Pourquoi ne pas exposer le modèle via la façade et plutôt faire dépendre la façade Graphic du modèle à la place en proposant une méthode similaire SetModelToView mais dans la façade Graphic avec en argument la façade du modèle?
Bon après c'est vrai qu'exposer le modèle est potentiellement plus "dangereux" que d'exposer une vue.

Citation:

---

Envoyé par sfarc

Dernier point, pour revenir sur ton ancienne réponse :

Citation:

---

Dans l'ordre des dépendances, le modèle dépend du business, le module réseau dépend d'une partie du business (pour les traces en elles-même) et le module vue dépend du modèle. Mais business ne dépend d'aucun module et, pour aller plus loin, il ne devrait même pas dépendre de Qt.

---

Seulement, tu proposes dans la conception de mettre dans la façade du modèle une méthode SetModelToView pour associer à la vue un modèle. Dans ce cas, la façade du modèle dépendrait donc de la vue (paramètre de la méthode).

---

Cela mérite vraiment réflexion :aie:

Il faut dire que les relations entre le modèle et la vue sont particulièrement complexes :aie:

D'abord, parce que la communication entre les deux doit passer "dans les deux sens" :

D'une part, le modèle doit pouvoir prévenir la vue qu'il est temps de se mettre à jour, et d'autre part, la vue doit pouvoir:

• indiquer au modèle qu'elle a intercepté un événement pour lequel le module devra décider de le prendre en compte ou non
• interroger le modèle afin de savoir quoi afficher.

En plus, tu peux parfaitement avoir plusieurs vues qui travaillent de concert avec le même modèle (on a une relation de l'ordre de un modèle à plusieurs vues).

La communication dans le sens modèle vers la (les) vue(s) qui utilise(nt) le modèle peut se faire à coup de signaux.

Il en va de même quand la (les) vue(s) qui utilise(nt) le modèle doi(ven)t lui transmettre un événement qu'il doit prendre en compte.

Mais le système de signaux et de slot sera insuffisant pour permettre à la vue d'interroger le modèle afin de savoir ce qu'elle doit afficher :aie:

Ce n'est en effet pas un hasard si la classe QAbstractItemView (la classe de base pour tout ce qui doit afficher des données :D) disposer d'une fonction setModel(QAbstractItemModel*). C'est parce que la classe QAbstractItemModel (la classe de base pour tous les modèles que nous voudrions utiliser) expose un certain nombre de services qui seront directement utilisés par les vues ;).

On remarque donc qu'il y a, de facto, une dépendance de la vue (ou du module View) envers le modèle (ou envers le module Model). De ce point de vue particulier, il serait donc sans doute dommageable de rajouter une dépendance inverse (du module Model envers le module View), mais...

Nous travaillons ici avec deux abstractions. "L'empreinte" de la dépendance du module Model vis à vis du module View serait donc particulièrement limitée (on peut se contenter de transmettre un pointeur ou une référence vers un élément de type QAbstractItemView). Et il faudra, de toutes façons, questionner la façade de Model pour pouvoir définir le modèle de tes vues, que ce soit au travers de la façade de View ou directement depuis tes vues.

La question est donc: préfères tu écrire un code qui pourrait ressembler à

Code:

---

1 2 3

void MyView::askModelToModule(ModelFacade & facade){ facade.setModelToView(this); }

---

ou un code qui ressemblerait plutôt à

Code:

---

1 2 3

void MyView::askModelToModule(ModelFacade & facade){ setModel(facade.giveMeModel()); }

---

Perso, je préfères "intuitivement" la première solution. Mais je n'ai aucune justification conceptuelle à te donner à ce sujet :aie:

Citation:

---

Nous travaillons ici avec deux abstractions. "L'empreinte" de la dépendance du module Model vis à vis du module View serait donc particulièrement limitée (on peut se contenter de transmettre un pointeur ou une référence vers un élément de type QAbstractItemView).

---

Effectivement, je peux très bien garder un type abstrait pour la vue défini par Qt. Mais, si je souhaite garder une indépendance avec la bibliothèque utilisée, tout comme ce que tu proposais pour le module business, on ne peut plus "se reposer" sur une vue abstraite offert par Qt.
Enfin bon, l'idée reste la même j'imagine, définir une vue abstraite et garder cette petite dépendance avec le modèle de la façade du module Graphic.

Citation:

---

La question est donc: préfères tu écrire un code qui pourrait ressembler à

Code:

---

1 2 3

void MyView::askModelToModule(ModelFacade & facade){ facade.setModelToView(this); }

---

ou un code qui ressemblerait plutôt à

Code:

---

1 2 3

void MyView::askModelToModule(ModelFacade & facade){ setModel(facade.giveMeModel()); }

---

Perso, je préfères "intuitivement" la première solution. Mais je n'ai aucune justification conceptuelle à te donner à ce sujet :aie:

---

La deuxième solution a quand même un inconvénient que je trouve important. Il expose depuis la façade Model le modèle, qui possède d'ailleurs des méthodes publiques de gestion du modèle (ré-implémentation des méthodes du modèle Qt abstrait), méthodes donc potentiellement exploitables depuis l'extérieur.
Exposer une vue, reste donc a priori, moins néfaste non?

Je pencherais donc plutôt pour la première aussi :)