lu,

Je suis actuellement sur un petit projet. Il y a une dizaine de classes "spécialisées" qui s' occupent chaqune d' une partie spécifique de l' application et une classe qui les gére. Cette dernière concentre donc pas mal de données.

Si une classe spécialisée doit causer à une autre classe spécialisée, je passe par la classe qui gére ?

Si une classe spécialiser doit faire une action qui demande des ressources qui sont dans la classe qui gére, est ce que je lui donne les ressources ou je la fait passer par la classe qui gére ?

trop generique pour apporter une solution precise, mais mon impression en lisant cela et que ta classe "centrale" est une sorte de gros "manager" qui souffre d'etre "monolithique", et autour duquel qq classes proposant des services et qui tentent tant bien que mal de naviguer l'arborescence pour acceder aux donnees.

je recommande la lecture de 2 ouvrages tres bien fait:
Large Scale C++ Software Design
Design Patterns: elements of reusable object-oriented software

qui devraient t'aider dans la conception (surement trop tard pour ce projet... ca servira pour le prochain)

k merci pour les bouquins

Bon j' ai un autre probléme du même genre, donc je vais upper ici.

Voici le plan de réorganisation du code de mon petit "jeu" :

Il aura deux type de classes : les aides et le reste. Les aides c'est un groupe de classes utilitaires qui est parfaitement réutilisable pour un autre projet. Pour le reste je voulais les organiser par "niveau d' abstraction" en gros, plus on descend dans la hierarchie plus c 'est spécialisé. Donc sa permeterais d' avoir toute la logique du jeu isolée des difficultés technique et facilement modifiable.

Sa utilise beaucoup le patern façade ( ou interface je sais plus ).

Premierement est-ce une grosse bêtise ?

Et puis comment faire passer les informations d' une couche à l' autre ? Fonctions de rappel ? Ou alors des messages ?
++

"Les aides c'est un groupe de classes utilitaires qui est parfaitement réutilisable pour un autre projet."

ca, tu peux facilement le "demoter" dans des libs annexes par exemple, pour garder un coupling minimal.

"plus on descend dans la hierarchie plus c 'est spécialisé."

c'est le principe meme de la POO

"Donc sa permeterais d' avoir toute la logique du jeu isolée des difficultés technique et facilement modifiable."

attention a ne pas essayer de trop generaliser cette approche et essayer de hierarchiser le "flow control".

"Sa utilise beaucoup le patern façade ( ou interface je sais plus ). Premierement est-ce une grosse bêtise ?"

pas foncierement, mais c'est pas non plus optimal, en terme d'archi. Pense plutot ton application comme un ensemble de modules qui communiquent entre eux: au lieu d'abstraire l'information pour faire passer les donnees entre plusieurs couches (et ca devient tres vite difficile d'acceder aux infos voulues par des classes specialisees..), tu te retrouves avec un probleme bien mieux contenu: definir les interfaces haut niveau entre les modules. (note que des Facades ou Wrapper sont aussi utiles, parfois, dans cette approche)

pour du feedback plus precis, presente un diag UML de ton app ou tes modules !

merci pour tes conseils. Je vais compiler mes aides dans des libs sa sera plus claire.

Sinon qu 'est ce que tu veux dire par module, et par diag UML ? ya plein de diag UML ( j'ai un peu vu le diagramme de classes ).

Il parle d'un diagrammes de classes (et de diagramme de composant pour les modules ? ), je pense. Et comme outil UML, tu peux utiliser StarUML qui est pas mal et gratuit.

merci beaucoup, les modules ça m' a l' air de bien marcher.

relu,

Comment faire un systeme de collision sans faire des tonnes de downcasts ou de switchs qui compromettent un rajout de fonctionalité ?

Jmexplique : chaque type d' objet ( sphere, plan, boite.... ) à ses propres algorithmes de détections pour chaque objet. Donc au moment de décider c 'est la mort, et si je veux en rajouter un plus tard faut que je change tout les switches ou les downcasts et que je rajoute dans chaque classe l' algorythme correspondant.

je pense que le mieux, c'est que chaque objet ait des attribut et que tu decides de comment se fait la collision en fonction de ces attributs.
Comme solide, elastique, nondeformable, faitdesdommages...

Oé je fais bien sa comme sa pour les collisions. En fait ce dont je parle c 'est de la détection des collisions. Chaque objet à son propre algo.

Dsl de m' être mal exprimé.

ah, la detection de colisions...
tu n'as pas 50 algo non plus.
Je pense qu'il faut décrire de maniere synthetique ton objet. Dans la plupart des cas, il doit suffir de dire c'est une boite ou c'est une sphere.
Si tu as besoin de chose plus compliqué, il faut dire c'est une boite et une sphere du coup, tu fais deux tests de collision '(ou tu peux faire une boite englobante pour ne faire les deux test qu'en cas de necessité.

En theorie tes differentes façon de tester la collision devraient etre representés par des fonctions dans un module qui gere ta physique et non pas directement dans chaque classe.

Apres tu peut donc utiliser des attributs pour savoir quel type d'information tu possede pour chaque element, (du genre si c'est un plan, une sphere, une box qui est utilisé pour le representer durant les collisions). Comme ca tu te retrouve avec un seul switch dans ton module physique qui te dis quel methode utiliser selon les types des elements que tu test. Ta physique aura des fonctions du genre testPlanSphere , testBoxBox, testSphereSphere etc... toi tu appelera juste testCollision, fonction à laquelle tu passera les proprieté physique de ton element.

Je suis pas sur d'etre tres clair donc si personne comprend rien à ce que je raconte dite le...

Ok merci je vais voir ce que sa donne.

puisqu'on parle ici d'archi, et pas initialement d'algos de detections de collisions, je recommanderais un double-dispatching aka multi-virtuality ; cf. Scott Mayers dans More Effective C++. Tres adapte a ce genre de situations.

Exactement ce qu' il me fallait. merci LGV.