Discussion :

[tof114]

Bonjour,

J'ai une questions que j'aimerais vous soumettre.
Voilà, j'ai créé un objet qui a des caractéristiques que je regroupe dans des sous catégories:
* forme ( poids, volume, dimensions...)
* composition chimique (nombre de carbone, formule, nom...)
* propriétés mécaniques (traction, résistance, rugosité...)
* propriétés électriques (conductance, inductance...)

J'ai potentiellement une bonne 100aine de caractéristiques.

Ensuite, j'ai plein de fonctions qui vont prendre les caractéristiques de l'objet pour en déduire d'autre grandeur.

Je pense utiliser une map pour stocker tout au même endroit.
Par exemple:
<"Poids",4.5>
<"Nb_Carbone",12>
<"Formule", "C12H26">
<"Nom","Dodecane">
etc...


En effet, cela me permettra d'être souple en n'utilisant que les infos qui sont à ma disposition (par exemple, je ne connais pas la rugosité...donc, rien dans ma map).
Au niveau du dev, pas besoin de recompiler dès que je rajoute un attribut et surtout, je peux proposer des interfaces simples avec l'extérieur.

Puis-je avoir votre avis sur cette conception svp ?
Merci d'avance.

[NiamorH]

Oui, ça parait une bonne idée, maintenant comment comptes-tu gérer le fait que les données associées ne sont pas du même type ?

[Invité]

Boost.Any est fait pour cela.

C'est une bonne idée de conception. Tu peux peut-être formaliser l'idée qu'un tel objet appartient à plusieurs "classes" (pas au sens statique, mais au sens conceptuel) dans ta conception, histoire de structurer un peu les concepts que ton application utilise, mais sinon je pense que le choix est bon. Tu auras notamment de gros avantages pour le stockage persistant de tes objets (dans une base de données, par exemple, qui s'y prêterait bien).

Carl

[tof114]

Oui, ça parait une bonne idée, maintenant comment comptes-tu gérer le fait que les données associées ne sont pas du même type ?

Merci. Effectivement, les données gérées ne seront pas du même type.
Les fonctions qui prennent en argument la map utiliseront "le bon type".
Par ex:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
getName (CaracMap _carac)
{
      return _carac("Nom");
}
 
computeNbHydrogene (CaracMap _carac)
{
      long nbH = _carac("Nb_Carbone") * 2;
      if _carac("Type") == "Alcane"    
           return nbH + 2;
}

Le danger c'est qu'à la compilation, ça ne vérifiera pas qu'on ajoute des choux et des carottes !

Boost.Any est fait pour cela.

C'est une bonne idée de conception. Tu peux peut-être formaliser l'idée qu'un tel objet appartient à plusieurs "classes" (pas au sens statique, mais au sens conceptuel) dans ta conception, histoire de structurer un peu les concepts que ton application utilise, mais sinon je pense que le choix est bon. Tu auras notamment de gros avantages pour le stockage persistant de tes objets (dans une base de données, par exemple, qui s'y prêterait bien).

Carl

Merci pour ton analyse.
Je ne comprends pas trop ta recommendation, tu peux me donner un exemple stp ?

Autre point, est-ce vraiment une conception objet ? car je me demande si finalement, on a pas un fourre-tout !

[JolyLoic]

Si tu peux la plupart du temps manipuler tes données de manière uniforme, en te moquant du fait que l'une représente la résistance, l'autre la capacité, ce design ne me choque pas.

Si tel n'est pas le cas, si tu dois sans cesse tout au long du logiciel travailler avec telle puis telle donnée, ce design me semble plus douteux.

Par exemple, si je reprends les données électriques, si le but est de gérer un catalogue de composants, ok. Si le but est de gérer un simulateur de schéma électrique, je suis moins convaincu.

[Invité]

Hello tof114,

C'est ta conception, et sans avoir les détails du programme, c'est difficile de venir avec des éléments concrets, surtout lorsque ta solution est particulièrement abstraite.

Imagine qu'une partie de ton logiciel est, comme le mentionne JolyLoic, un simulateur de schéma électrique. Cette partie-là de l'application ne va gérer qu'un sous-ensemble des propriétés de chaque objet, et va ignorer les autres. Peut-être que cette subdivision peut apparaître dans le code c++, sous forme d'adaptateurs, par exemple, qui "enveloppent" ton type très général dans une interface C++ plus stricte et plus spécialisée, dans le but de faciliter la manipulation.

Par contre, quand je regarde l'interface que tu proposes, j'ai l'impression que tu adoptes la solution perdant-perdant: tu as une interface définie à la compilation, et donc tu perds par exemple en capacités d'introspection, mais tu as une implémentation "relax" qui inhibe toute vérification sur les types et toute optimisation de la part du compilateur. Si j'étais toi, j'aurais une classe "Objet" qui propose des méthodes de manipulation très générale sur les propriétés (y compris de lister les propriétés et de vérifier si une propriété a bien été définie) et un ensemble de classes "adaptatrices" pour utiliser de tels objets dans tel ou tel contexte.

Pour ton problème de type, je te conseille vivement Boost.Any: si tu as des fonctions différentes comme tu l'indiques, chaque fonction récupère la donnée grâce à son nom, et vérifie le type à la compilation avant de renvoyer la valeur:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
std::map<std::string, boost::any> carac_t;
 
std::string getName(carac_t& caracs)
{
  // Lance une exception si la carac "Nom" n'a pas le type
  // std::string (ou compatible).
  return boost::any_cast<std::string>(caracs["Nom"]);
}
 
int getNbHydrogene(carac_t& caracs)
{
  return boost::any_cast<int>(caracs["Nb_Carbone"]);
}

Carl