[POO] conception des classes

**poukill** · 29/06/2006, 14h57

Envoyé par Miles

Ben oui, si camera est de type Camera et pas Camera*.

D'accord...

Donc, par déduction. Si je travaille depuis la classe Choc. Comme j'ai un CFP*, je ne peux pas faire de :

Code :

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

cfp->getNomComposant();

C'est bien ça?

Une méthode pour palier à ce problème?

**Matthieu Brucher** · 29/06/2006, 15h36

Ben si, tu as un CFP*, donc tu y accèdes avec ->...
Dans ton exemple, tu avais une Camera, donc c'est directement '.', c'est du C++ classique...

**poukill** · 29/06/2006, 16h07

Ok ok, c'est que la POO a tendance à embrouiller mes connaissances en C++!

Je vais essayer de pondre une version, et demain je montre mes soucis (j'espère ne pas en recontrer mais bon...)

Je devrais rapidement passer du côté forum C++ je pense...

Merci Miles

**Matthieu Brucher** · 29/06/2006, 16h22

De rien

Effectivement, maintenant, ça peut être plus du C++ que de la conception

Le mieux est sans doute un nouveau sujet dans le forum C++, pour laisser une trace ici pour les autres

**poukill** · 30/06/2006, 09h01

OK ! Juste une dernière question Miles:
Quand je crée un Choc (c'est inévitablement le point de départ!), j'utilise le constructeur qui prend entre autre comme paramètres le numero_choc... Cette donnée étant très importante pour les autres classes, j'ai deux solutions:
1) Soit j'écris tous les constructeurs des autres classes de façon à ce qu'ils prennent comme paramètre numero_choc, de même pour les méthodes en ayant besoin. Je me débrouille alors pour boucler tout ce qui a besoin de numero_choc d'un coup dans le constructeur.
Inconvénient : Une fois que la classe est instancié:impossible de retrouver le numero_choc (à moins que tu aies une méthode !!)

2) Chaque classe a un attribut privé numero_choc que je rempli lors de l'appel du constructeur.
Inconvénient : Ca fait le même attribut dans toute les classes, qui est identique partout... Je sais pas si c'est génial!!!

J'aimerai vraiment avoir ton retour là dessus !

**Matthieu Brucher** · 30/06/2006, 09h06

Si tu en as besoin partout, de ce numéro, autant le donner partout, c'est pas un problème.

**poukill** · 30/06/2006, 09h11

Même si ça fait pas vraiment parti de la Classe (i.e : rien à voir avec l'objet )?

**Matthieu Brucher** · 30/06/2006, 09h19

C'est clair, c'est limite, mais bon, ça serait se casser la tête pour pas grand chose, AMHA.

**poukill** · 30/06/2006, 09h25

Oui, je pense aussi...
J'ai encore une p'tite interrogation: j'ai des fonctions (typiquement affichage par transparence de deux images) que je ne sais pas vraiment encore où ranger... Soit je crée une autre classe, soit je la laisse en fonction libre!

Je ne perçois pas bien les limites de la POO, j'ai l'impression que si je fais pas tout rentrer dans des classes, comme ils le font si bien à l'école, c'est pas de la POO propre ?

classe ou libre ?

**Matthieu Brucher** · 30/06/2006, 09h29

Une fonction libre peut appartenir à une classe, ça dépend si elle est fournie avec ou pas

L'avantage des fonctions libres, c'est que si elles sont bien faites, elles peuvent épargner la réécriture d'elles-mêmes : une classe polymorphique avec une fonction libre appelant des fonctions virtuelles.
Tout faire rentrer dans une classe, ça donne des trucs horribles comme la classe std::string qui est un grois bloc infâme.

**poukill** · 30/06/2006, 09h50

Envoyé par Miles

L'avantage des fonctions libres, c'est que si elles sont bien faites, elles peuvent épargner la réécriture d'elles-mêmes : une classe polymorphique avec une fonction libre appelant des fonctions virtuelles.

Dans mon cas, je parle surtout de fonction de mon cru (donc pas très bien faite

)!
CE qui me chagrine, c'est qu'une fonction AffichageMix() a peu de point commun avec une classe CFP (un peu quand même, mais bon)!

Comme tu le dis, j'ai peur qu'à la fin, tout soit mis n'importe comment dans la classe, ça va devenir le b...

D'un autre côté, une fonction libre, pour moi, c'est une fonction mis dans un fichier outils.cpp à côté. Bof bof

**poukill** · 30/06/2006, 10h29

J'ai choisi la solution de recopier le numero_choc là où j'en ai besoin. Ca me parait pas mal!

Une autre (dernière?) question:
Y a t-il un moyen pour que toutes les variables numero_choc soient identiques?
Ou bien faudra -til prévoir une mise à jour vers les autres classes lorsque je ferai:

Code :

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

choc.setNumeroChoc(36547)

Le problème peut-être: si j'ai envie de rajouter d'autres classes!

Merci!

**Matthieu Brucher** · 30/06/2006, 10h32

A priori, la seule manière qu'elle soient identiques, c'est que ce soit la même variable, et donc que ce soir une référence dans les classes filles, mais bof.

**poukill** · 30/06/2006, 10h43

Ok !
Je pense que le mieux est que dans la méthode qui modifie numero_choc, je fasse "descendre" l'info aux autres classes, qui elles n'auront pas le pouvoir de modifier directement cet attribut ?

**Matthieu Brucher** · 30/06/2006, 10h53

Oui, sauf que tu ne pourras jamais leur interdire d'écrire dans cette variable

**poukill** · 30/06/2006, 10h58

C'est juste...
Pb connu ou de conception ?

Je pense pas que ce soit si grave... Au pire, je peux le déclarer const dans les autres classes que choc ?

**Matthieu Brucher** · 30/06/2006, 11h03

C'est un problème qui est dû aux spécificités du langage : une variable d'une instance de classe peut être modifiée par cette instance, c'est normal.
Avec un const, tu ne pourras pas changer la valeur de la variable, depuis ton instance comme depuis l'extérieur.Je n'ai pas de solution simple à ce "problème".

**poukill** · 30/06/2006, 11h09

OK c'est bien ce que je craignais.

J'ai une idée:
Si CFP est une classe abstraite, et ne contient pas de méthode pouvant modifier numero_choc (private). Les deux classes filles (les seules pouvant être instanciées) n'auront donc pas accès à cet attribut, non?

Ainsi, seul choc pourra modifier numero_choc (car possède un pointeur CFP *)?

Dis moi si je me plante lamentablement dans mon raisonnement!