[POO] conception des classes

**poukill** · 11/07/2006, 14h30

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!

Ces données sont destinées à etre utilisées par la suite!

**Matthieu Brucher** · 11/07/2006, 14h40

Ah

Donnees ne contient donc pas les données que le composant va "analyser" ?

**poukill** · 11/07/2006, 14h51

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!

**Matthieu Brucher** · 11/07/2006, 14h53

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.

**poukill** · 11/07/2006, 14h59

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...

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?

**Matthieu Brucher** · 11/07/2006, 15h07

Oui, en passant par CFP.
Mais si c'est mon idée, en tout cas, je ne vois pas laquelle

**poukill** · 11/07/2006, 15h29

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

Mais je suis pas sur que c'est ce que tu voulais dire !!!!

**Matthieu Brucher** · 11/07/2006, 15h34

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

**poukill** · 11/07/2006, 15h42

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à

**poukill** · 11/07/2006, 15h48

Pour info:

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

**poukill** · 11/07/2006, 15h55

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....

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 :

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
#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 :

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
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 :

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

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

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

Code :

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

1
2
3
 
CFP * comp = new CFP(*this);
cfp.push_back(comp);

Je n'ai vraiment aucunes idées si ce truc marche ...

**Matthieu Brucher** · 11/07/2006, 16h11

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 ?

**poukill** · 11/07/2006, 16h17

Tout ! Si l'utilisateur décide de changer de composant à regarder, il faut tout supprimer !

**Matthieu Brucher** · 11/07/2006, 16h47

Bon, dans ce cas, autant garder les données dans la caméra...

**poukill** · 12/07/2006, 08h34

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 !

**Matthieu Brucher** · 12/07/2006, 08h49

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

**Luc Hermitte** · 12/07/2006, 09h25

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

**poukill** · 12/07/2006, 09h33

choc.h

Code :

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

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 :

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
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?

**poukill** · 12/07/2006, 09h43

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* ?

**Eusebe** · 12/07/2006, 09h46

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?

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)

[POO] conception des classes

C++

Discussions similaires

Partager

Partager