Discussion :

[ElPedro]

Bonjour,

Je cherche à savoir : quelle est la meilleure méthodes pour gérer des hierarchies d'aggregation parallèles (exemple ci dessous)?

Je pense que c'est un problème récurrent, et pourtant je ne trouve pas de design pattern sur le sujet. Y a-t-il une solution récurrente?
=====================================
Exemple de problème :
Dans un jeu video j'ai une classe VoitureTempsReel. VoitureTempsReel contient N SiegeTempsReel qui contiennent chacun M MateriauTempsReels.

Au niveau de la configuration, j'édite des classes : VoitureConfig, SiegeConfig, et MateriauConfig. Ces classe sont utilisées pour initialiser VoitureTempsReel. (Elles permettent l'édition + (de)sérialisation automatique).

Lorsque je sauvegardes des informations temps réelle, de la même manière je vais avoir : VoitureSave, SiegeSave, MateriauSave qui contiennent les informations qui ne sont pas dans VoitureConfig etc.

Cette archi me convient plutôt bien, sauf que :
- VoitureConfig contient des SiegeConfig qui contiennent des MateriauConfig. Idem pour les XXXSave. On a donc des hierarchies d'aggrégation parallèles, dont le + haut niveau est relié (par l'initialisation des infos), et le reste est transmis en cascade.
- On a sauvent la copie des infos de VoitureConfig dans les attributs de VoitureTempsReel (et idem pour les autres) à faire et maintenir à la main.

=====================================
Background : j'ai déjà codé des jeux vidéos professionnellement. Je suis (très) à l'aise en général, mais cette question me turlupine depuis des lustres.

Avez vous des remarques / suggestions? Y a-t-il un design pattern adapté?
Et si j'utilisais un préprocesseur custom (j'en ai déjà écris) cela aurait-il du sens ?

[ternel]

Personnellement, je fais un sapin-fourchu, ou un peigne, selon ce que tu visualise le mieux.

C'est une hiérarchie de classe métier, et pendant de chacune, des classes sœurs (save et config), souvent templatisées pour partager le code.

il n'y a pas souvent d'héritage entre les sœurs des classes métiers.

Par ailleurs, tu n'as pas de hiérarchie dans ton exemple.
un siège n'est pas une voiture, une voiture n'est pas un siège, même si celle-ci est composée de ceux-là.

[ElPedro]

Merci pour ta réponse.

Détail : je ne suis pas convaincu que le mot "hierarchie" ne s'utilise que pour de l'héritage. C'est pourquoi je l'ai utilisé, clairement sans parler d'héritage. Dans tous les cas, tu as bien compris effectivement ce que je voulais dire dans mon premier thread, où je parlais d'aggrégation (comme le titre).

Je comprends ce que tu décris comme structure en peigne. Cependant, dans ce cas tu ne peux pas instancier complètement une classe métier à partir d'une classe soeur (il manque les aggrégats/fils/elements contenus, non) ?

[Joel F]

ça se résout avec quelques template.

tes seules vraies classes sont voitures, siege etc..
les config et autres utilitaires s’écrivent façon:

Code :

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

1
2
3
4
5
6
template<class T> struct config
{
  // le code
};
 
typedef config<voiture> voitureconfig;

pas besoin de préprocesseur

[ternel]

En principe, tu vas aussi avoir une banque de configuration (les fichiers de données, en général), matérialisés par une ou plusieurs factory basées sur les identifiants.

Ce qui veut dire que tu aurais probablement des appels tels que:

Code :

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

1
2
3
4
5
6
7
//il faudra surement en faire des singletons.
Factory<voiture> garage("voitures.data");
Factory<siege> chaiserie("chaises.data");
Factory<materiau> usine("materials.data");
 
voiture v = garage.get("voiture1");
//ce qui provoque, en interne des appels à usine.get(…)