Conception d'une classe : casse-tête
Bonjour,
Je dirais que je me débrouille pas mal en C ainsi qu'en programmation impérative en général, mais j'ai un problème avec la programmation orientée objet.
Jusqu'à présent je ne faisais que des petits programmes en C++, mais récemment j'ai voulu essayer quelque chose : créer un shoot'em'up en C++.
J'ai écumé un peu le net à la recherche de méthodes pour concevoir des classes en C++, mais je tombe la plupart du temps sur des articles pour débutant.
Je suis tombé également sur le "gang of four" mais je pense que cela ne correspond pas trop à mon problème.
Je tombe aussi sur de nombreux exemples de shared_ptr, d'auto_ptr mais leur exemples sont faits sur-mesure et sont beaucoup trop simples par rapport à ce qu'on peut rencontrer dans un vrai programme.
Le fait qu'il n'y ait pas "une seule meilleur solution" ou même "le choix entre plusieurs solutions avec chacune leur avantage" me déroute au point que j'ai déjà recommencé plusieurs fois mon code pourtant bien avancé.
Mon principal problème se situe pour l'instant au niveau de la conception de la classe "GameScreen" (écran de jeu) qui correspond à une situation de jeu.
Comme j'en ai un peu marre de me casser la tête là dessus et que je ne trouve rien sur le net, je voulais vous demander comment vous l'implémenteriez.
J'ai déjà les classes "Vessel" (vaisseau) qui dérive de "DisplayElement". Pourquoi cette dérivation ? Car je compte par exemple rajouter "Bomb" ou "Obstacle" qui dériveraient aussi de "DisplayElement".
La classe GameScreen représente l'écran qui défile et donc beaucoup de créations/destructions d'objets.
Code:
1
2
3
4
5
6
7
8
9
10
11
| class GameScreen {
public:
GameScreen();
~GameScreen();
...
private:
Container _renderingList;
GUI _gui;
}; |
Il me faut aussi stocker quelque part la cible d'un éventuel missile guidé lancé par le joueur, de préférence dans la classe "GUI".
Jusque là quelques unes de mes implémentations incluaient :
- Le passage uniquement par un identifiant, sauf que c'est très lourd à force
Ma classe "GUI" stockerait alors un ElementID
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| class GameScreen {
public:
typedef int ElementID;
ElementID createVessel();
ElementID createObstacle();
ElementID getElementAtPosition(int x, int y); // 0 = aucun
void setElementPosition(ElementID, int x, int y);
etc.
private:
std::map<ElementID,DisplayElement*> _renderingList;
Element _nextElementID; // incrémenté à chaque fois pour distribuer des IDs
}; |
- L'utilisation de shared_ptr pour pouvoir accéder aux éléments de l'extérieur
Mais si un vaisseau est détruit, le shared_ptr stocké dans GUI va empêcher sa destruction réelle (il ne va plus être affiché à l'écran mais il existera toujours, et la croix rouge que le GUI dessine dessus sera elle toujours affichée)
Il faudrait un moyen de signaler au GUI que la cible vient d'être détruite, sans pour autant casser l'indépendance que je pense nécessaire entre les différentes classes
Code:
1
2
3
4
5
6
7
8
9
| class GameScreen {
public:
std::shared_ptr<DisplayedElement> createVessel();
std::shared_ptr<DisplayedElement> createObstacle();
std::shared_ptr<DisplayedElement> getElementAtPosition(int, int);
private:
std::list<std::shared_ptr<DisplayedElement> > _renderingList;
}; |
Bien que ce problème puisse ici être résolu sans trop de problème (le GameScreen n'a qu'à vérifier si la cible du GUI correspond à un élément lorsqu'il est détruit), cela peut être je pense plus contraignant dans certains cas
Au delà de l'implémentation de cette classe, je cherche plutôt des guides ou tutoriaux de règles à respecter en C++ pour une bonne gestion de ce genre de problèmes
En gros je voudrais connaître "les trucs que tout le monde connaît mais que c'est écrit nulle part", comme "les règles d'or à respecter" ou je ne sais quoi :P
Merci d'avance
