[POO] conception des classes

Version imprimable

Voir 40 message(s) de cette discussion en une page

11/07/2006, 14h30
poukill

T'y es presque! Camera ECRIT dans données. Ce sont des données de sortie pour une analyse future qui n'est pas encore faite! :D
Ces données sont destinées à etre utilisées par la suite!
11/07/2006, 14h40
Matthieu Brucher

Ah :koi: Donnees ne contient donc pas les données que le composant va "analyser" ?
11/07/2006, 14h51
poukill

Ben non !!!! ;)
Mais je dois peut etre me débrouiller autrement !
Tu m'avais conseillé de créer une classe Données il y a quelques jours dans ce topic pour ça! :mrgreen:
11/07/2006, 14h53
Matthieu Brucher

Ah, OK, donc j'ai rien compris... Je croyais que la caméra donnait au composant des données et que l'expérience travaillait ensuite sur ces données.
11/07/2006, 14h59
poukill

C'était ton idée à la base, que je n'ai fait que copier. J'espère ne pas l'avoir interprétée de travers...:mrgreen:
Mon problème est donc celui-là: je crée à partir de Camera des Donnees. Problème: la classe porte toujours le même nom...

Je crois que mon problème est débile, mais j'arrive pas à en voir le bout:

Récapitulatif:
1) J'ai un CFP qui contient une Camera, qui elle-même contient des Données (le tout par composition). (si tu veux je peux joindre le nouveau schéma)...
2) Je voudrai accéder aux Donnees. Comment faire? EN passant par CFP?
11/07/2006, 15h07
Matthieu Brucher

Oui, en passant par CFP.
Mais si c'est mon idée, en tout cas, je ne vois pas laquelle :D
11/07/2006, 15h29
poukill

http://www.developpez.net/forums/sho...&postcount=130

Mais je suis pas sur que c'est ce que tu voulais dire !!!! :mrgreen: :mrgreen:
11/07/2006, 15h34
Matthieu Brucher

OK, c'est bien ce que je pensais ;)
En fait, je t'ai posé la question avant, pour vérifier ça, mais ta réponse ne me donnait pas la bonne solution.
Les caméras devraient être indépendantes de tout, une classe singleton/registry qui retournent des données quand on les appelle et ces données sont stockées dans les CFP.
Mais la réponse que tu m'avais donnée m'indiquait que ces données étaient générées par le CFP, ou alors on s'est mal compris. En fait, on s'est mal compris :D
11/07/2006, 15h42
poukill

Citation:

Envoyé par poukill

Oui, en fait le double avantage que j'y voyais, c'est que :
1) C'est réellement ce qui se passe : une caméra par composant:
2) Lorqu'on détruit un CFP, il faut aussi détruire sa caméra associée.

Je pense que tout ça doit se dérouler correctement, non?

Pourtant, ce schéma est très intéressant: la caméra ne vit pas sa propre vie, puisque je la met dans CFP, mais cette vision a les deux avantages ci-dessus.

Tu penses que je devrai mettre ma caméra indépendante? (plus réel, moins pratique?)
Ou alors la remettre comme précédemment dans Choc?

Sinon j'avais pensé à stocker à la fois un CFP avec sa camera associé dans un std::pair, vu qu'ils vont bien ensemble! Je pense que c'est une idée pas trop mauvaise, mais de là à voir tous les enjeux qu'il y a derrière, je m'écclipse complet là ;)
11/07/2006, 15h48
poukill

1 pièce(s) jointe(s)

Pour info:

Agrandir l'image pour y voir quelque chose...

Un tout autre problème...

Je suis désolé d'enchainer les questions, mais j'ai l'impression d'enchainer les problèmes... Sur un gros projet tout seul, c'est pas facile du tout....:cry:

Merci encore en tous cas pour la patience...

J'ai bien compris (enfin!) le bout de code de Luc pour le passage par référence du Choc pour "remonter à la source".
L'exemple, très parlant dans le cas d'une composition (avec Camera ici), peut-il être appilqué à un CFP* ?

Exemple:
Code:

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 #ifndef CHOC_H #define CHOC_H #include "CImg.h" #include <iostream> #include <string> #include "cfp.h" // dépendance circulaire class Choc { public: Choc (int num_choc, std::string nom_cfp); ~Choc(); void ajouterComposant(std::string); void supprimerComposant(std::string); private: std::vector<CFP*> tableau_cfp; int numero_choc; std::string nom_composant; } #endif
Code:

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 class Choc; // déclaration en avant, nécessaire pour les dependances circulaires class CFP { public: CFP(Choc & c); ~CFP(); CImg <unsigned short> getImageIR(); virtual setImageIR(CImg <unsigned short>) = 0; CImg <unsigned short> getImageVisible(); void setImageVisible(); virtual setZone(int) = 0; int getZone(); ajusterTailleVisibleEtIR(); private: CImg <unsigned short> image_IR_ref; CImg <unsigned short> image_visible; int zone; Choc & getChoc() {return m_choc; } Choc const& getChoc() const {return m_choc; } int getChocNum() const; Choc & m_choc; // référence => on ne change pas de contexte! }
Le problème, c'est que je ne peux pas faire quelquechose comme :

Code:

Choc::Choc(....) : cfp(*this) { ... }

Est-ce que je peux créer un CFP* via un new, comme ça:
Code:

1 2 3 CFP * comp = new CFP(*this); cfp.push_back(comp);
Je n'ai vraiment aucunes idées si ce truc marche ... ;)

11/07/2006, 16h11
Matthieu Brucher

Citation:

Envoyé par poukill

Pourtant, ce schéma est très intéressant: la caméra ne vit pas sa propre vie, puisque je la met dans CFP, mais cette vision a les deux avantages ci-dessus.

Tu penses que je devrai mettre ma caméra indépendante? (plus réel, moins pratique?)
Ou alors la remettre comme précédemment dans Choc?

Sinon j'avais pensé à stocker à la fois un CFP avec sa camera associé dans un std::pair, vu qu'ils vont bien ensemble! Je pense que c'est une idée pas trop mauvaise, mais de là à voir tous les enjeux qu'il y a derrière, je m'écclipse complet là ;)

C'est une caméra qui doit être détruite ou les données qu'elle a acquise ?
11/07/2006, 16h17
poukill

Tout ! Si l'utilisateur décide de changer de composant à regarder, il faut tout supprimer ! :D
11/07/2006, 16h47
Matthieu Brucher

Bon, dans ce cas, autant garder les données dans la caméra...
12/07/2006, 08h34
poukill

OK je trouve ça logique aussi Miles!
Et en ce qui concerne mon message #171 ???
C'est un gros point qui bloque pour moi ! Car j'aimerai bien avoir une référence à Choc dans ma classe CFP Camera, mais je sais pas trop comment m'y prendre! (cf 171)

Merci d'avance ! :D
12/07/2006, 08h49
Matthieu Brucher

Oui, tu peux sauf que new CFP(...) va planter ;)
12/07/2006, 09h25
Luc Hermitte

Citation:

Envoyé par poukill

Question bête: Pourquoi un vector<CFP*> et pas un vector<CFP>?
Je ne peux pas tout stocker directement dans Choc? C'est pas une bonne idée?

Les vecteurs nécessitent que les objets stockés soient copiables.
Or tes CFP font parti d'une hierarchie d'objets polymorphes (si j'ai bien suivi). Sans feinte explicite, tu ne peut pas avoir de sémantique de copie sur les objets d'une hiérarchie polymorphes. Le défaut tend vers une sémantique d'entité avec parfois la "clonabilité".
Soit, pas de CFP dans des vecteurs. Qu'ils soient ou non instanciables.

Il ne faut pas avoir peur d'écrire plein de petites classes aux rôles bien spécialisés et aux noms qui retranscrivent bien ces rôles.

Promis, je prendrais le temps de me pencher sur ton diagramme, et de relire l'emsenble de tes specs ;)

choc.h

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
class Choc {
 
public:
	Choc (int num_choc, std::string nom_cfp);
	~Choc();
 
	void ajouterComposant(std::string);
	void supprimerComposant(std::string);
 
private:
	std::vector<CFP*> tableau_cfp;
	int numero_choc;
}

choc.cpp

Code:

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
Choc::Choc(int num_choc)
:numero_choc(num_choc)
{
	std::cout << "Choc numero " << numero_choc << "cree" <<std::endl ;
	ajouterComposant(nom_cfp);
}

Choc::~Choc()
{
	std::cout << "Choc détruit"<< std::endl;
}


void Choc::setNumeroChoc(int nchoc)
{
	numero_choc = nchoc;	
}

void ajouterComposant(std::string nom_cfp)
{
	CFP *cfp = new CFP(numero_choc, nom_cfp); // manque une ref à ce Choc!
	tableau_cfp.push_back(cfp);
}

void supprimerComposant(std::string nom_cfp)
{
	for (int i=0; i<tableau_cfp.size(); i++)
	{
        if (tableau_cfp[i]->getNomComposant() == nom_cfp)
		{
			tableau_cfp[i] = NULL;
		}
	}
}

Là Miles, je vois pas du tout: comment passer la référence à choc, lorsqu'on est pas dans la liste d'initialisation?8O

12/07/2006, 09h43
poukill

Citation:

Envoyé par Luc Hermitte

Les vecteurs nécessitent que les objets stockés soient copiables.
Or tes CFP font parti d'une hierarchie d'objets polymorphes (si j'ai bien suivi). Sans feinte explicite, tu ne peut pas avoir de sémantique de copie sur les objets d'une hiérarchie polymorphes. Le défaut tend vers une sémantique d'entité avec parfois la "clonabilité".
Soit, pas de CFP dans des vecteurs. Qu'ils soient ou non instanciables.

Il ne faut pas avoir peur d'écrire plein de petites classes aux rôles bien spécialisés et aux noms qui retranscrivent bien ces rôles.

Promis, je prendrais le temps de me pencher sur ton diagramme, et de relire l'emsenble de tes specs ;)

Merci Luc pour le tuyau!
Je suppose qu'il en va de même avec des std::list ???
Donc il faudrait que j'utilise un tableau de CFP* ?
12/07/2006, 09h46
Eusebe

Citation:

Envoyé par poukill

Là Miles, je vois pas du tout: comment passer la référence à choc, lorsqu'on est pas dans la liste d'initialisation?8O

Je ne comprend pas ton problème. le numéro de choc a bien été initialisé pourtant ??

Par contre, je suppose qu'il s'agit d'une faute de frappe, mais le prototype de ton constructeur dans choc.cpp n'est pas le même que dans choc.h (il manque std::string nom_cfp)
12/07/2006, 09h54
poukill

Citation:

Envoyé par Eusebe

Par contre, je suppose qu'il s'agit d'une faute de frappe, mais le prototype de ton constructeur dans choc.cpp n'est pas le même que dans choc.h (il manque std::string nom_cfp)

Un oubli, j'arrete pas de tout modifier tout le temps... Merci ;)

Citation:

Je ne comprend pas ton problème. le numéro de choc a bien été initialisé pourtant ??

C'est pas le numero de choc le pb...
Le problème, c'est qu'il faut que je donne au constructeur de cfp une référence au choc qui lui correspond.
Tu me suis ? :mrgreen:
du genre :

Code:

CFP (&Choc, .....)

Mais comment lui donner cette instance?8O
12/07/2006, 10h01
Eusebe

Ah ok, je n'avais pas en tête le prototype du constructeur de cfp ;)

Tu as essayé avec *this ?

Mais je ne suis pas sûr du tout que ça fonctionne, puisque ton objet n'est pas encore complètement créé...
12/07/2006, 10h05
poukill

Je ne pense pas que ça marche *this... C'est ce que Luc me proposait dans son code trois pages avant. Mais là c'était une composition, pas un pointeur.

Pour moi, *this ne marche que dans la liste d'initialisation...:cry:

Mais je ne suis pas si sur...
Je reste preneur d'idées en tous cas! :D
12/07/2006, 10h11
Matthieu Brucher

Citation:

Envoyé par poukill

Je ne pense pas que ça marche *this... C'est ce que Luc me proposait dans son code trois pages avant. Mais là c'était une composition, pas un pointeur.

Pour moi, *this ne marche que dans la liste d'initialisation...:cry:

Mais je ne suis pas si sur...
Je reste preneur d'idées en tous cas! :D

*this n'existe pas dans la liste d'initialisation d'une classe. Ca existe à partir du moment où la classe est crée.
12/07/2006, 10h12
poukill

Au temps pour moi: c'est une bonne nouvelle Miles! :D
12/07/2006, 10h14
poukill

Citation:

Envoyé par Miles

Oui, tu peux sauf que new CFP(...) va planter ;)

Au fait Miles, pourquoi ça va planter?8O

Code:

CFP *cfp = new CFP(*this, nom_cfp);
12/07/2006, 10h18
Matthieu Brucher

Parce que CFP a des méthodes virtuelles pures.
12/07/2006, 10h32
poukill

Oups :aie:
Bon, je suis mal barré là.
Je croyais que les pointeurs permettaient le polymorphisme.
CFP ne peux pas etre instancié, mais elle ne peut pas avoir de pointeur qui lui pointe dessus alors?

Une solution ? :(
12/07/2006, 10h34
Médinoc

Ben, si CFP possède des méthodes virtuelles pures, c'est donc une classe abstraite: Elle n'est pas supposée être instanciée.

Par contre, une classe abstraite est supposée avoir des classes dérivées, qui elles, peuvent être instanciées.
Généralement, on utilise le pointeur de classe abstraite pour pointer sur une instance de la classe dérivée.
12/07/2006, 10h35
Eusebe

Si CFP est une classe abstraite, c'est que tu ne devrais pas avoir besoin de la créer directement.

Est-ce que tu ne peux pas dans ton choc créer un objet d'une classe héritée de CFP ?
12/07/2006, 10h40
poukill

Citation:

Envoyé par Médinoc

Ben, si CFP possède des méthodes virtuelles pures, c'est donc une classe abstraite: Elle n'est pas supposée être instanciée.

of course !

Citation:

Par contre, une classe abstraite est supposée avoir des classes dérivées, qui elles, peuvent être instanciées.
Généralement, on utilise le pointeur de classe abstraite pour pointer sur une instance de la classe dérivée.

Oui, j'ai souvent vu ça, donc je voulais faire pareil, mais j'ai pris le problème à l'envers...

Citation:

Envoyé par Eusebe

Est-ce que tu ne peux pas dans ton choc créer un objet d'une classe héritée de CFP ?

Je voulais éviter, mais je n'ai pas le choix. Je vais donc partir là dessus!

Merci à vous! :D
12/07/2006, 11h19
poukill
Deux petites questions:
1) Le construteur d'une classe fille peut-il appeler le constructeur de la classe mère abstraite?

exemple:
Code:

1 2 3 4 5 Antenne::Antenne( Choc &c, std::string nom_cfp) :CFP(c, nom_cfp) { // bla bla bla }
2) Concernant le message de Luc sur mes vector: quelle solution adopter:
a) Prendre un autre conteneur (liste ?)
b) Utiliser un new/ delete[] (passage par pointeur)

Merci encore (et encore...) pour vos réponses!:roi:
12/07/2006, 11h24
Médinoc
1. oui.
2. b) (mais sans les crochets : utilise une liste de pointeurs, voire de boost::shared_ptr)
12/07/2006, 11h28
poukill

OK Merci Médinoc.

1) C'est quand même bizarre: une classe abstraite ne peut etre instancié, mais possède quand même un constructeur... No comment!

2) Hum.. Du côté de boost, pourquoi pas?
Je vais me renseigner un peu plus sur boost::shared_ptr
12/07/2006, 11h30
Matthieu Brucher

1) ben non, c'est logique, il peut y avoir des variables membres à initialiser.

Une autre question de débutant:
Comment faire pour stocker l'instance d'une classe dans une variable?
J'illustre mon problème dans l'exemple suivant:
Code:

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 class CFP { public: CFP(Choc & c, std::string nom_cfp); ~CFP(); CImg <unsigned short> getImageIR(); virtual setImageIR(CImg <unsigned short>) = 0; CImg <unsigned short> getImageVisible(); void setImageVisible(); virtual setZone(int) = 0; int getZone(); void ajusterTailleVisibleEtIR(); std::string getNomComposant(); private: Camera camera; CImg <unsigned short> image_IR_ref; CImg <unsigned short> image_visible; std::string nom_composant; int zone; Choc & getChoc() {return m_choc; } Choc const& getChoc() const {return m_choc; } int getChocNum() const; Choc & m_choc; // référence => on ne change pas de contexte! }
Code:

1 2 3 4 5 6 7 8 9 10 CFP::CFP(Choc & c, std::string nom_cfp) : m_choc(c), nom_composant(nom_cfp), Camera(c, nom_cfp) { std::cout << "Creation d'un objet CFP"<< std::endl; zone = 0; setImageVisible(); setImageIR(); ajusterTailleVisibleEtIR(); }
J'appelle effectivement le constructeur, mais comment stocker l'instance dans ma variable privé qui m'intéresse.
Intuitivement, j'avais pensé à

Code:

camera (Camera(c, nom_cfp))

, mais je me méfie de mes intuitions parfois!

Merci!

12/07/2006, 12h52
Matthieu Brucher

camera(...), comme pour tout constructeur d'une variable.
12/07/2006, 13h19
poukill

Au temps pour moi... :oops:
Je sais, je suis loin d'être au top, mais ça viendra un jour...
12/07/2006, 15h06
poukill

boost

Dans la mesure du possible, je souhaiterai utiliser boost::shared_ptr.
Je viens de regarder le tuto de Miles: http://miles.developpez.com/tutoriel...martptrs/#LIII

J'avoue ne pas avoir tout compris :oops:
Quel est l'avantage d'un tableau de boost::shared_ptr? Comment ça s'utilise? (je suis un peu noyé dans les constructeurs!)
12/07/2006, 15h17
Matthieu Brucher

tu as un std::vector<boost::shared_ptr<CFP> > vecteurCFP et pour initialiser un élément, tu fais un vecteurCFP[i].reset(new machin(...)); ou un vecteurCFP[i] = boost::shared_ptr<CFP>(new machin(...));

Voir 40 message(s) de cette discussion en une page