Discussion :

[gbdivers]

Bref, du dynamique

Je continue mon refactoring et je suis encore tombé sur une question existentielle (avec mort de bébé lapin probablement).

Le contexte : dans un application plugable, on peut avoir des créations d'objets dont le type n'est pas connu à l'avance, ni le nombre d'objet, ni les dépendances entre les objets. Par exemple, on peut avoir :
- un plugin "gui1" qui créé un objet "MainWinow" qui peut prendre en charge des objets de type "Widget"
- un plugin "gui2" qui ajoute un objet "Vues" qui est un "Widget" et qui prend en charge des objets de type "Vue"
- un plugin "gui3" qui ajoute un objet "TableVue" qui est une "Vue"
- un plugin "gui4" qui ajoute un objet "TreeVue" qui est une "Vue"
etc.

Habituellement, je gère ça avec une collection globale d'objet avec typage faible (type boost any). Chaque plugin ajoute ses objets dans la collection lors de l'initialisaton. Quand un objet a besoin d'avoir la liste des objets qu'il gère, il parcourt la collection en faisant des casts pour vérifier que c'est un type pris en charge (c'est la méthode utilisée par exemple dans QtCreator)

L'utilisation du any + des casts me semble pas top. Je me demandais s'il était possible de concevoir une architecture qui évite cela ?

J'ai pensé utiliser des collections spécifiques dans les objets "gestionnaires" (càd ceux qui prennent en charge d'autres objets), de type ObjetGestionnaire::Collection<ObjetGéré> ou Collection<ObjetGestionnaire, ObjetGéré>. Cela oblige d'avoir une liste d'objet gestionnaire ou une liste de collection et il faut passer par un dispatcher (par exemple un DP chaine de commande) lorsqu'un plugin veut ajouter une nouveau ObjetGéré (pour trouvé le bon gestionnaire ou la bonne collection)

Des critiques ou de meilleures idées ? (ou des questions parce que j'ai encore mal expliqué mon problème ?)

[Médinoc]

Je pense que quoi que tu fasses, cela se résumera à des dynamic_cast<> déguisés. Y compris si tu faisais un truc ressemblant au QueryInterface() de COM.