Discussion :

[Romain227]

Bonsoir,

débutant en C++, je voudrais savoir comment je pourrais définir des objets "fixes". Je m'explique : je crée une classe, et dans l'implémentation des méthodes, je voudrais pouvoir faire référence à / travailler sur des objets précis de cette même classe (voire d'une autre), qui sont toujours les mêmes.

Dois je déclarer des attributs statiques correspondant à ces objets dans la définition de ma classe? Quelle est la meilleure façon de faire?

Merci beaucoup,

Romain.

[bretus]

Bonsoir,

Généralement, quand on a besoin d'accès statiques à des objets, on a un problème d'architecture.

Vous pourriez précisez le cas où vous avez besoin de ça?

[3DArchi]

Bonjour,

Comme bretus, je ne suis pas sur de bien comprendre ton problème. Peux-tu détailler.

Sinon, trivialement, crées des instances nommées au bon scope et utilises les:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
class ma_classe
{
// ...
};
 
int main()
{
  ma_class inst1;
  ma_class inst2;
  m_class inst3;
 
   fonction(inst1);
   fonction(inst2);
   // ...
}

[oodini]

Je m'explique : je crée une classe, et dans l'implémentation des méthodes, je voudrais pouvoir faire référence à / travailler sur des objets précis de cette même classe (voire d'une autre), qui sont toujours les mêmes.

Ces contraintes ne sont pas suffisantes pour avoir recours aux objets statiques.
Un objet statique doit exister durant toute la durée de vie du programme. Est-ce ici nécessaire ?

[Steph_ng8]

Bonjour,
Si tu ne peux/veux pas faire des instances nommées, tu peux créer une collection spécifique pour les instances dont tu as besoin.
Après le type de collection dépend de la manière par laquelle tu accéderas aux instances : index, clé, etc.

[Romain227]

Bonjour,


Voici le contexte : l'objectif pour moi est de réaliser l'animation basique d'un personnage 2D (avancer, courir, sauter, se baisser, faire demi-tour, etc...)

actuellement la gestion de tout ça se fait avec une classe "Animation" ou des instances de cette classe sont créees, chacune correspondant à un mouvement défini (par exemple l'animation "courir" est un objet fait de plusieurs frames qui décortiquent le mouvement de course).

je cherche maintenant à créer une classe nommée ici arbitrairement personnage ou je gèrerais les différents mouvements du personnage. Je me sens obligé à l'heure actuelle d'intégrer dans cette classe les animations prédéfinies correspondants aux mouvements de ce personnage.

Supposons par exemple que je souhaite implémenter la méthode courir, j'écrirais quelque chose (sans aucun souci de rigueur ici ) comme :

if (personnage.getAnimation() != saut) personnage.setAnimation(course);

les objets saut et course étant des objets animations.

N'ayant pas beaucoup d'expérience dans la structure d'un tel code (mais ne cherchant pas non plus à révolutionner le monde), je ne sais pas s'il s'agirait d'une bonne façon d'implémenter les choses.

Merci beaucoup,

Romain

[r0d]

Bonjour,

il y plusieurs façons de prendre le problème. Je préconise pour ma part le design pattern State.
Ton bonhomme aura différents états (running, idle, jumping, ...), et une unique fonction Draw(), qui appelera le Draw() de l'état courant.
Cette méthode a ses inconvénients (compliqué s'il y a beaucoup d'états; attention aux transitions), mais elle est assez souple et générique.

Bien amicalement,
r0d.

[koala01]

Salut,

Bonjour,

il y plusieurs façons de prendre le problème. Je préconise pour ma part le design pattern State.
Ton bonhomme aura différents états (running, idle, jumping, ...), et une unique fonction Draw(), qui appelera le Draw() de l'état courant.
Cette méthode a ses inconvénients (compliqué s'il y a beaucoup d'états; attention aux transitions), mais elle est assez souple et générique.

Bien amicalement,
r0d.

En fait, je séparerais bien encore un peu plus les responsabilités..
Le bonhomme aurait effectivement différents états, mais la seule responsabilité de l'état serait... d'indiquer ce que fait le bonhomme à l'instant T.

Il y aurait un "Drawer" dont la responsabilité serait effectivement l'affichage de... ce que l'on pourrait lui fournir en paramètre.

ce "Drawer" pourrait d'ailleurs être spécialisé en fonction de la bibliothèque graphique utilisée et récupérerait l'état de l'élément qu'on lui demande de tracer d'une part, la séquence de frame correspondante de l'autre sur base d'un identifiant fourni par l'état, pour arriver au final à afficher l'animation.

cela donnerait quelque chose comme

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
class Perso
{
   public:
       void animate()
       {
           drawer_->animate(*this);
       }
       State const & state() const{return *state_;}
    private:
        Drawer * drawer_;
        State * state_;
};
 
class Drawer
{
   public:
       Drawer(AnimationHolder * frames)frames_(frames)
       void animate(Perso & perso)
       {
           State const & st =perso.state();
           int stateId= st.id()
           AnimationHolder ::const_iterator start;
           AnimationHolder ::const_iterator end;
           frames_.find(st.id(),start,end); // void FrameHolder::find(int, const_iterator &, const_iterator & ) :D
          drawFrames(start,end);//affiche toutes les frames ;)
       }
   private:
       void drawFrames(AnimationHolder::const_iterator start,
                       AnimationHolder::const_iterator end)
       {
            while(start != end)
            {
                (*start)->draw(/*paramètres éventuels */);
                ++it;
            }
       }
       AnimationHolder * frames_;
}

Et quand même quelques explications

AnimationHolder serait une classe de base pour une classe dont la seule responsabilité est de maintenir en mémoire l'ensemble des animations, qui sont elles meme un ensemble de frame.

Frame est une classe de base des différentes représentations de frames qui peuvent exister (une frame directX est sans doute différente d'une frame OpenGl )

Le AnimationHolder est créé (et remplis d'animations) lors de l'initialisation de la partie (que ce soit dans la fonction main ou dans la classe Game, selon ce qui est fait ).

La fonction find du AnimationHolder va rechercher l'animation correspondant à l'id obtenue par l'état et redéfinir les itérateurs start et end pour qu'ils correspondent aux itérateurs respectif de la première frame et de la fin de l'animation trouvée.

Le Drawer, créé juste après, reçoit en paramètre le AnimationHolder, qui sera gardé sous la forme d'un membre.
Le personnage est créé en dernier et reçoit (d'une manière ou d'une autre) un pointeur sur le Drawer de manière à ce qu'il lui serve de membre.

Nous obtenons donc un ordre de dépendance proche de

Code :

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

1
2
3
4
5
6
 
       State
      /
Perso
      \
       Drawer  --> AnimationHolder--> Animation --> Frame

dont chaque classe peut être dérivée de manière indépendante (ou peu s'en faut, car, si l'on rajoute un état, il faudra penser à rajouter... une animation, et donc des frames )

Toutes ces classes font bien sur partie de hiérarchies de classes totalement indépendantes

[r0d]

C'est effectivement une autre façon de voir les choses.
Pour ma part, au plus j'avance dans le "monde du orienté objet", au plus j'ai tendance à laisser toujours plus de responsabilité aux classes elles-même.
Par exemple, et pour rester dans le cadre de ce sujet, un bonhomme doit se débrouiller pour s'afficher lui-même. Il doit lui-même posséder ses images, gérer ses états et transitions, etc. Ce qui n'empêche pas de passer par des "helpers" (décorateurs, factory, etc., et même pourquoi pas - Ô ultime hérésie - des fonctions libres; souvent très utiles pour factoriser du code).

L'avantage de cette façon de fonctionner est un découplage fort. Chaque classe se débrouille, et ainsi on peut changer le comportement de nos classes sans toucher aux classes qui manipulent ces dernières, et vice-versa.

Mais encore une fois, c'est un choix, avec ses avantages et ses inconvénients. Un des inconvénients de cette "ultra-responsabilisation" est qu'on peut se retrouver avec des classes énormes et difficiles à diviser.

[koala01]

C'est effectivement une autre façon de voir les choses.
Pour ma part, au plus j'avance dans le "monde du orienté objet", au plus j'ai tendance à laisser toujours plus de responsabilité aux classes elles-même.
Par exemple, et pour rester dans le cadre de ce sujet, un bonhomme doit se débrouiller pour s'afficher lui-même. Il doit lui-même posséder ses images, gérer ses états et transitions, etc. Ce qui n'empêche pas de passer par des "helpers" (décorateurs, factory, etc., et même pourquoi pas - Ô ultime hérésie - des fonctions libres; souvent très utiles pour factoriser du code).

L'avantage de cette façon de fonctionner est un découplage fort. Chaque classe se débrouille, et ainsi on peut changer le comportement de nos classes sans toucher aux classes qui manipulent ces dernières, et vice-versa.

Mais encore une fois, c'est un choix, avec ses avantages et ses inconvénients. Un des inconvénients de cette "ultra-responsabilisation" est qu'on peut se retrouver avec des classes énormes et difficiles à diviser.

...Ou se retrouver avec un "PropertyManager" transformé en singleton, composé de tellement d'accesseurs et de mutateurs qu'il en devient difficile de savoir si l'on dispose déjà d'une propriété particulière et qui, combe de malheur, va écrire dans trois fichiers différents : un dans le dossier personnel de l'utilisateur et deux dans des dossiers accessibles en écriture uniquement par l'administrateur

Sans compter qu'il devient alors très difficile de décider d'hériter de ce genre de classe, car tu ne sera jamais sur d'avoir bien redéfini toutes les fonctions qui sont sensées l'être

[Romain227]

Bonjour,

merci pour votre aide, même si je trouve cela un peu rude à comprendre pour le débutant que je suis (je connais une grande partie des concepts du langage, l'aggrégation de tout ça dans un code tel que le design pattern m'est beaucoup plus difficile à comprendre).

En reprenant le code de Koala, a quel niveau dois je définir le passage à un état suivant (en supposant que j'ai construit un diagramme d'états exhaustifs pour mon personnage) et le code à exécuter lorsque mon personnage se trouve dans un état donné? Comment dire, par exemple, que l'état "courir" n'est réalisable que si le personnage était dans un état précédent particulier?

Peut-être est ce la compréhension de la structure du pattern qui m'échappe, je devrais probablement m'arrêter dessus un bon moment.

Thx,

Romain

[Emmanuel Deloget]

Bonjour,

merci pour votre aide, même si je trouve cela un peu rude à comprendre pour le débutant que je suis (je connais une grande partie des concepts du langage, l'aggrégation de tout ça dans un code tel que le design pattern m'est beaucoup plus difficile à comprendre).

En reprenant le code de Koala, a quel niveau dois je définir le passage à un état suivant (en supposant que j'ai construit un diagramme d'états exhaustifs pour mon personnage) et le code à exécuter lorsque mon personnage se trouve dans un état donné? Comment dire, par exemple, que l'état "courir" n'est réalisable que si le personnage était dans un état précédent particulier?

Peut-être est ce la compréhension de la structure du pattern qui m'échappe, je devrais probablement m'arrêter dessus un bon moment.

Thx,

Romain

Je dirais que c'est la compréhension non pas du pattern, mais de ce qu'est un automate à état, qui t'échappe un peu.

Shameless plug: cf. http://blog.emmanueldeloget.com/inde...chines-a-etats (en dehors des considérations de langage).

[Romain227]

^ merci pour le lien.

En fait oui et non, c'est clair sur le lien que tu m'as fourni (où son application se situe au niveau des basculement d'écrans d'un JV) ; appliqué à la description d'un personnage, j'ia plus de mal.

exemple qui me passe par la tête au moment où j'écris ces lignes:

un personnage peut marcher et porter une caisse. Si je définis un état "marcher" et un état "porter", et en supposant que mon personnage peut marcher en portant, dois je définir un état "marcher + porter"?

Est ce judicieux d'associer une animation à un état? (l'animation "marcher + porter" étant différente de l'animation "marcher" ou l'animation "porter")

edit: question bête je pense, il faut a priori décrire autant d'états que nécessaires.

++ et bonne journée,

Romain