Folco (./130) :
1. La transmission d'informations.

Mon gestionnaire de tâches est à la racine de tous les objets : il crée des modules, qui créent des Plane, des icônes, des évènements, des listes, des avions, bref de tout. Mais (puisqu'il y a un mais, je l'ai donc mis là). Mais ce sont les icônes qui vont provoquer un changement de tâche. C'est en effet en cliquant sur un icône ou une autre qu'on va quitter un module et demander le chargement d'un autre. Alors comment faire communiquer l'icône avec le gestionnaire de tâches ? Ou la méthode manageIcon(MouseX, MouseY) renvoie un numéro de tâche à charger s'il y en a un, et le module doit le renvoyer à son tour au gestionnaire de tâche, ou... quoi d'autre ?Personnellement, je trouve ça très moche le fait de faire transiter une information par tous les objets qui auront été créés entre le gestionnaire et l'icône... J'aurais alors des objets qui n'ont rien à faire des tâches qui se retrouvent à jouer les facteurs ? C'est hyper moche. J'ai pensé alors à une sorte d'"objet global", comme une variable globale, qui servirait de boite au lettre pour les uns et les autres, et que le gestionnaire viendrait relever quand ça lui plairait. Mais l'idée ne m'attire pas plus, même si ça me semble déjà mieux.

À mon avis, il faudrait passer le pointeur vers le gestionnaire de tâches dans le constructeur de chaque classe, ou le lui faire récupérer automatiquement à partir de la classe parent qu'on lui passe.

Sinon il y a aussi le singleton comme solution, ou alors tu fais carrément du gestionnaire de tâches un module (un .cpp avec des fonctions procédurales) plutôt qu'un objet. Le singleton est la version "pur objet" du module.

a. Question de principe : si je veux simplifier un minimum quelques tâches, est-ce propre de mettre pas mal d'attributs en protected dans Module pour ne pas jouer de l'accesseur tous les 2 minutes pour ? C'est considéré comme propre ce concept ? Ca peut être dangereux ?

C'est un peu le but de protected.

Cela dit, si tu veux encapsuler très fortement ta classe (genre si tu veux permettre des classes dérivées par autrui que toi et que tu veux éviter que tes changements cassent leur code), tu mets tes membres en private, des accesseurs pour les classes dérivées (pour ce pour quoi il n'y a pas d'accesseur public) en protected et les accesseurs publics en public.

(Et attention, quand je dis "accesseur", ce n'est pas forcément un bête get/set, ça peut aussi être une interface spécialisée qui abstrait entièrement les membres.)

J'ai bien compris la POO, je n'ai juste pas l'habitude de l'utiliser.

b. Que dois-je implémenter comme méthodes ? Que dois-je définir comme virtual ? Je sens qu'ici il y a des choix à faire, mais je n'en maitrise absolument pas les tenants et aboutissants... Si vous vouliez bien m'éclairer, ce serait très aimable à vous.

Si tu veux permettre aux classes dérivées de surcharger ta méthode, tu as tout intérêt à la rendre virtual, sinon tu risques de mauvaises surprises! Mais si surcharger la méthode n'a aucun sens, il vaut mieux éviter le virtual, à la fois pour la performance et parce que la compatibilité antérieure binaire est plus simple à réaliser avec des méthodes non-virtuelles (cf. http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ si tu as envie de savoir tout sur la compatibilité binaire, c'est vraiment le bordel).