Discussion :

[poukill]

Miles, j'ai deux trois questions de débutant (cf nouveau schéma post précédent).

1) Les variables privées comme ça c'est OK ?

2) Les classes filles peuvent-elle avoir des variables qui ne sont pas dans la classe mère? Si oui, est-ce souhaitable? (en fait je ne pense pas que ce soit pas possible, mais n'étant pas sur...)

3) Les classes choc et PDC sont un peu "toutes seules" non?

[Matthieu Brucher]

Ca a l'air correct
Oui, les classes filles peuvent avoir pleins de variables différentes, la classe mère n'aura que les points communs, en gros.

[poukill]

Ok d'accord !
Une question plus "pointue": l'instance CFP qui est dans la classe choc aura t-elle accès à la variable numero_choc?

[Matthieu Brucher]

Non, sauf si tu prévois un pointeur pour "remonter". Et attention, tu stockes un pointeur vers CFP, pas une instance directement

[poukill]

AAAH ok.
On stocke un pointeur et pas une instance? Pourquoi?
Là du coup je vais devoir créer un max de méthode dans Choc pour remplir mes champs de CFP !

Quand on stocke un pointeur comme ça, quels sont les droits d'accès (private, protected, public) vers là ou on pointe ?

[Matthieu Brucher]

Tu ne pourras pas stocker une instance de CFP puisqu'en tant que telle, elle n'existe pas, c'est un composant abstrait, c'est l'antenne qui sera quelque chose, et pour accéder à une antenne à travers un CFP, il va te falloir un pointeur.

[poukill]

Ok d'accord, je commence à comprendre !

1) Dans l'hypothèse où CFG serait seul, sans classes filles. Pourrait-on stocker directement l'instance dans choc ?

2)

c'est l'antenne qui sera quelque chose

Donc, on ne peut pas créer d'objet CFP? Il faudra passer obligatoirement par les classes filles (j'ai fait un peu de java avant donc... c'est un peu différent je pense) ?

3) Vu que CFP est une classe abstraite, faut-il la déclarer comme abstract (comme en java)?

Merci bcp bcp pour ton aide !

[poukill]

Salut !

OK j'ai bien compris... De plus, je viens de potasser un bouquin de C++ là dessus, j'y vois plus clair!
Par contre, voici une question plus embetante pour moi:

Pour implémenter une fonction du genre "is_readable (std::string &file)", comme celà est fait dans la FAQ, faut-il créer une classe fichier (pour rester dans l'esprit de la POO), ou bien alors le laisser comme une fonction, et donc créer un fichier outils.cpp où tous ces petits test seront implémentés (moins propre ???)

Merci !

[Matthieu Brucher]

Les 2 se défendent, mais je préfèrerais les fonctions libres qu'une classe

[Luc Hermitte]

Je me pose plusieurs questions:
1) Dans quels cas faire hériter une classe d'une autre?
2) Une classe avec une seule variable est-elle abbérante?
3) Une classe peut-elle contenir des données qui ne pas vraiment propre à elle? (exemple : dans mon cas, une classe Composant qui contiendrait une variable numero_experience...)

Bref, je vous remercie d'avance d'éclaircir ma lanterne.

1) Il y en a plusieurs. Le plus répandu, qu'il est important d'assimiler avec les langages statiquement typés comme le C++ (Java, ...), c'est l'héritage en vu de la substituabilité. Là où on attend un objet d'un type Parent, on peut accepter (sans rupture de contrats et d'invariants) un objet d'un type fils. C'est le LSP (principe de substitution de Liskov), c'est fortement lié au polymorphisme d'inclusion (obtenu en C++ avec les fonctions membres virtuelles), c'est très étroitement lié à l'héritage public en C++.
C'est à dire, hériter publiquement implique que la syntaxe du langage permet de tenter de substituer un objet d'un type fils là où l'on attend un type parent. Si ces types n'ont pas été écrits pour être substituables, alors le risque de mauvaises surprises est assez élevé en cas d'héritage public. Exemples types de non substituabilité: en informatique, un carré n'est-pas-un rectangle, une liste triée n'est-pas-une liste.
On entend aussi parfois parler d'héritage "est-un", celui qui permet d'"être utilisé en place de"

L'héritage peut aussi être utilisé pour "réutiliser du code". Une classe peut être "implémentée en termes" d'une autre classe. C'est une alternative à la délégation (un traitement est délégué à une autre classe) ; alternative plus fortement couplée. Le C++ permet facilement de mettre en oeuvre ce type d'héritage sans permettre, syntaxiquement parlant, la substitution. Cela se fait avec l'héritage privé. Je crois qu'Eiffel a aussi sa propre façon de faire pour mettre en oeuvre un héritage de réutilisation. Java et quelques autres en sont incapables, i.e. seule la composition peut être utilisée pour définir proprement une liste triée à partir d'une liste dans ces langages.
C'est un héritage qui a beaucoup été vendu (à tord AMHA) dans les années 80/90.

Il y a d'autres approches de l'héritage que j'utilise assez peu: pour rajouter du code à une classe existante, ... J'avais croisé un résumé plutôt pas mal sur wikipédia (en français ou en anglais, je ne sais plus).

2) J'écris régulièrement des classes sans données. Parce que le pattern stratégie ne requiert pas nécessairement la présence d'une donnée -- je spécialise des comportements en fonction de la stratégie courante (qui se substitue à une classe qui décrit de manière assez "abstraite" le traitement à réaliser). Parce que parfois en méta-prog j'ai besoin de classes particulières polices, traits ou autres qui ne définissent que des types ou des fonctions.
...
La donnée encapsulée n'est pas ce qui caractérise une classe chez moi. Je réfléchis beaucoup plus en termes d'abstraction. La donnée encapsulée n'étant alors généralement qu'un détail d'implémentation.

3) On essaie d'avoir un couplage intelligent entre les classes. Même si on peut pafois avoir des classes de données, il est tout à fait courant d'avoir des classes qui définissent en fait des rôles. Personnellement, j'ai tendance à priviliéger cette dernière approche -- je manipule en fait assez eu des classes de données. Du coup, les données contenues ne sont qu'un détail d'implémentation (bis). Je m'interresse avant tout aux rôles et services que fournit la classe.

Une autre question que je me pose: dois-je déclarer CFP comme classe virtuelle??? Quelles sont les conséquences (je viens du C et du java!!!!)?
Faudra t-il recoder toutes les méthodes dans les classes filles comme en java?

Il n'y a pas de "classes virtuelles" en C++. On a des ABC (Abstract Base Classes) qui sont des classes abstraites. Toutes leurs fonctions peuvent être virtuelles pures (sans implémentation), ce qui ressemble beaucoup aux interfaces de Java, mais aussi à celles que l'on trouve chez COM. Seules certaines fonctions peuvent être virtuelles pures. Cela est un moyen de programmer nativement (avec de l'huile de coude) par contrats -- Java ne le permet pas sans passer par des outils externes de préprocessing.
Il est impossible d'instancier un objet d'une classe à laquelle il reste des fonctions membres virtuelles pures.

NB: il existe aussi la notion de "classe de base virtuelle" qui est :
- relative aux classes qui héritent (A peut être une classe de base virtuelle pour B, mais juste une classe de base pour C)
- lié à l'héritage multiple et au partage de membres.

i.e. "virtuel" est utilisé dans deux contextes différents.

Oui, je me souviens de mes cours de POO en java. L'idée était toujours d'appeler une méthode de la classe mère...

Beurk. Je n'aime pas cette approche car il est très facile d'oublier d'appeller ce qui doit l'être. Quand cela est possible (pas toujours pratique de la mettre en oeuvre simplement), je préfère le design pattern template method->

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct Base {
    void f() {
        trucs_f_toujours_faits_pre();
        do_spe_f();
        trucs_f_toujours_faits_post();
    }
private:
    virtual do_spe_f() { /*rien par defaut; ou virtuel pur*/}
};
 
struct Specialization : public Base {
private:
    virtual do_spe_f() { /*trucs propres à la spécialisation*/}
};

2) Les classes filles peuvent-elle avoir des variables qui ne sont pas dans la classe mère? Si oui, est-ce souhaitable? (en fait je ne pense pas que ce soit pas possible, mais n'étant pas sur...)

J'espère bien que c'est le cas. Les classes filles qui définissent des données, voient ces données se rajouter à celles de la classe mère. Si les données portent le même nom, alors on perd l'accès (simple) aux données (au plus protégées) de la classe mère. Il y a un processus de masquage, valable sur tous les membres (données comme fonctions), à quelques nuances près.

...virtuel pur

Quand on ne peut pas fournir de comportement par défaut qui ait un sens pour une fonction membre, alors "virtuelle pure" est le meilleur choix.
C'est aussi la seule façon de définir une ABC: une ABC est une classe qui dispose d'au moins une fonction membre virtuelle pure.

<pinaillage>"méthode" ne fait pas partie de la terminologie C++. Certains comprennent ça comme "fonction membre". D'autres considèrent que ce sont des "fonctions membre virtuelles", ce qui me parait assez consistant avec la définition UML : une méthode étant une spécialisation (ou implémentation ?) d'une opération.
</>

Pour implémenter une fonction du genre "is_readable (std::string &file)", comme celà est fait dans la FAQ, faut-il créer une classe fichier (pour rester dans l'esprit de la POO), ou bien alors le laisser comme une fonction, et donc créer un fichier outils.cpp où tous ces petits test seront implémentés (moins propre ???)

C'est le genre de cas où la fonction membre serait statique (car elle ne porte sur aucun objet en particulier) (-> fonction membre de classe). Ici, il me semble que c'est avant tout un artifice pour déclarer la fonction dans une portée, pas pour dire que les fonctions membres des objets (!= classe) peuvent être implémentées à l'aide de fonctions, dans la même thématique, mais qui ne portent sur aucun objet en particulier.
Bref, j'utiliserai un espace de noms. En plus, c'est extensible.

Oui, mais les variables ne sont pas dans la classe ? Je ne peux donc pas faire un simple get ? (cf pièce jointe)
Ma question est donc : comment accéder aux classes par composition? L'amitié est - elle dans mon cas un bon moyen (cf schéma ?)

Cela sent le code orienté données. As-tu réellement besoin des données contenues dans l'objet référencé, ou alors veux-tu réaliser un traitement sur ces données contenues dans l'objet référencé.
Même la sérialisation des données est un traitement qui peut être délégué à l'objet qui connait le mieux les données qui définissent son état.

[poukill]

C'est le genre de cas où la fonction membre serait statique (car elle ne porte sur aucun objet en particulier) (-> fonction membre de classe). Ici, il me semble que c'est avant tout un artifice pour déclarer la fonction dans une portée, pas pour dire que les fonctions membres des objets (!= classe) peuvent être implémentées à l'aide de fonctions, dans la même thématique, mais qui ne portent sur aucun objet en particulier.
Bref, j'utiliserai un espace de noms. En plus, c'est extensible.

Je dois avouer que je n'ai pas tout compris.
Un espace de noms? Je ne vois pas pour l'instant l'intérêt. Pour l'instant, je n'ai fait que les utiliser, mais je n'en ai jamais créé !

Grave. Un attribut n'est pas nécessairement une propriété. Si tu rajoutes un truc public, c'est pour rajouter un nouveau service, une nouvelle responsabilité. Ce qui faut se demander, c'est si c'est ajout a du sens ou non. En fonction de cela => public ou pas.

Oui d'accord. C'est finalement très logique. Une fois que l'on a bien en tête qui fait quoi, celà devient relativement facile à écrire!

J'écris régulièrement des classes sans données. Parce que le pattern stratégie ne requiert pas nécessairement la présence d'une donnée -- je spécialise des comportements en fonction de la stratégie courante (qui se substitue à une classe qui décrit de manière assez "abstraite" le traitement à réaliser). Parce que parfois en méta-prog j'ai besoin de classes particulières polices, traits ou autres qui ne définissent que des types ou des fonctions.

Ceci m'amène à une nouvelle question assez générale : celle du couplage entre classes. Admettons que je crée d'autres classes. Apparemment, il vaut mieux créer plus de classes, et ainsi minimiser les couplages entre elles, que de rattacher à tout prix des fonctions ou attribut faisant moyennement parti des classes déjà existantes!
Question : est-ce que le design des classes est mauvais si l'ordre de création des classes depuis la classe principale est important?

Exemple : Ma classe Choc est la classe principale, base du programme.

Voici la déclaration de son constructeur:

Code :

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

1
2
3
4
5
Choc::Choc(int num_choc, std::string nom_cfp) 
:numero_choc(num_choc), Camera(num_choc, nom_cfp), Ecran(), ...
{
	std::cout << "Choc numero " << num_choc << "cree" <<std::endl ;
}

En rouge, la partie qui coince pour moi... En effet, il est par exemple possible que Camera aie besoin d'Ecran, car dans son constructeur, je fais appel à camera.getLargeurEcran().
Question donc: Parmis ces deux solutions, laquelle est "bonne":

1) Mes constructeurs sont très complets, et remplissent tous les attributs privés du premier coup (et pas par 0 ou NULL). Dans ce cas, ils vont avoir besoin d'info chez d'autres classes (mieux placés pour contenir l'info) via une méthode publique...
Problème : il faut que la classe qui détinet l'info en question soit déjà crée.

2) Mes constructeurs de classes ne remplissent que les champs qu'ils sont sûr de connaître, et on remplit ensuite gentillement au fur et à mesure ce qu'il manque via méthodes...

J'espère avoir été clair!

Merci beaucoup!

[poukill]

Je me demandais... Je suis toujours parti sur :
* de l'héritage
* de la composition
pour créer mon diagramme des classes

Alors voilà : une classe seule (c'est à dire qui n'utilise pas d'héritage et où aucunes autres classes ne l'utilisent par composition) est-elle une abérration?

Je me pose la question puisque :

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
class CFP {

	friend ajusterTailleVisibleEtIR();

public:
	CFP(int num_choc, std::string nom_cfp);
	~CFP();

	CImg <unsigned short> getImageIR();
    virtual setImageIR(CImg <unsigned short>);

	CImg <unsigned short> getImageVisible();
	setImageVisible();

	CImg <unsigned short> warping();

	std::string getNomComposant();
	setNomComposant(std::string);

	virtual setZone(int);
	int getZone();

	affichageMix(float, bool, float, bool);


private:
	PDC pdc;
	CImg <unsigned short> image_IR;
	CImg <unsigned short> image_visible;
	CImg <>champ_deformation;
	std::string nom_composant;
	int zone;
	int numero_choc;
	float coeff_mul;

}

PDC pourrait être retiré de cette classe. Ainsi ma classe PDC serait sans liens avec les autres classes. Mais elle possederait des méthodes pour interagir avec les autres...

Y a t-il une règle générale à suivre dans mon cas?

Merci

Poukill, qui pose et se pose bcp de questions !

[Matthieu Brucher]

Est-ce que la classe CFP a besoin d'une instance de PDC ?

[poukill]

(ça fait 10 minutes que je me torture l'esprit pour une ligne de question... )

Un Composant Face au Plasma ne possède pas des Points de Controles, d'un point de vue terre à terre.
Cepedant, pour l'implémentation, oui, CFP va avoir besoin de PDC. Parce que je lui ai donné ce rôle...

Le truc génant pour moi c'est les histoires de contructeurs (cf mon message plus haut).
Mais ta question m'a permis de trouver la réponse: oui il faut que je laisse PDC. J'en suis maintenant convaincu.

Et pour mon message d'avant, qu'en penses-tu?

[Luc Hermitte]

Des classes sans composition ni héritage ne sont pas des abérrations. J'en ai des tonnes des comme ça.

Ne connaissant pas ton problème, j'ai un peu de mal à voir tes histoires de couplages. p.ex. En quoi un numéro de choc est-il pertinent pour construire une caméra ? Pourquoi une caméra est associée à un choc ? Ne vit-elle pas sa propre existance en dehors de tout choc ?
Ne peut-elle pas être synthonisée au dernier moment dans la fonction de Choc qui a besoin de la caméra ?

Pour les constructions. L'idéal, en ce qui me concerne, c'est ton cas 1) (on fait tout dans la liste d'initialisation). Parfois, on n'a pas le choix et des initialisations doivent être retardées.

C'est très bien un objet qui fourni des fonctions réalisant les services dont on n'a besoin. Nul besoin de tout composer. La bétonière n'est pas un élément du maçon. Par contre, elle est là et il peut aller y accéder lorsqu'il en a besoin. Le maçon est sur un chantier où un certains nombre de ressources sont disponibles -- là, on est un peu dans une logique entité.

Dans une logique plus informaticienne, on peut définir une classe de calcul, p.ex un classe qui définit le processus de préparation du béton armé. (On pourrait faire ça avec une fonction, mais une classe peut avoir du sens aussi, surtout si le temps est une donnée externe avec laquelle il faut se synchroniser).
Dans la construceur tu prendras ton ciment, les graviers, l'electricité, le tuyau d'arrosage, le manipulateur,... Cela servira à initialiser des ressources locales à l'algorithme. Ses services vont être de démarrer le processus, de réagir à des événements (rajout d'"ingrédients"), de programmer des événements (timer, observation d'un état "acceptable", ...). Une fois l'état acceptable atteint, on peut aller chercher ce qui a été préparé.

C.-à-d. une classe qui va ponctuellement être instanciée dans une fonction (en fonction du contexte d'exécution) pour réaliser un traitement fonction de ce contexte courant. A la fin de la fonction cliente, plus besoin de l'objet. Il n'y a pas de composition.

Un attribut, tant que ce n'est qu'un attribut (donnée d'implémentation), ce n'est pas choquant de le dupliquer. Le tout est de savoir d'où il vient et comment tu pourras le transmettre aux divers traitements qui en ont besoin.
Enfin. Cela ne me choque pas si l'attribut est avant tout une valeur immuable. Si'il s'agit d'une entité autonnome, cela veut dire que l'on va soit sortir les pointeurs, soit mettre en place des mécanismes complexes de propagation des changements d'état.

[poukill]

Est-ce que ce code est correct ?

Code :

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

1
2
3
4
std::vector< std::pair <int, int> >& PDC::getTableauDepart() const
{
	return &tableau_depart;
}

Puis dans la classe principale je l'appelle comme ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
void Warping::affichageDepart()
{
	std::vector< std::pair <int, int> >::const_iterator i;

	std::vector< std::pair <int, int> >& depart = pdc.getTableauDepart();

	for (i=depart.begin(); i != depart.end(); i++) {
		int x = i->first;
		int y = i->second;
        depart.draw_rectangle(x-1,y-1,x+1,y+1,red,1);
		depart.display(depart_disp);
    }
}

[Eusebe]

si tableau_depart est bien un pointeur vers un std::vector< std::pair <int, int> >, je pense que c'est bon.

Edit : si comme dans ce post, tableau_depart n'est pas un pointeur vers un vector mais un vector, il ne faut pas que tu fasses

Code :

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

return &tableau_depart;

mais

Code :

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

return tableau_depart;

dans getTableauDepart()

[Matthieu Brucher]

Est-ce que ce code est correct ?

Code :

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

1
2
3
4
std::vector< std::pair <int, int> >& PDC::getTableauDepart() const
{
	return tableau_depart;
}

Pas de & devant, on renvoie l'objet, pas un pointeur.

[Luc Hermitte]

Si ta fonction est const et que l'objet que tu renvoies est un attribut de l'objet PDC, alors il te faudra renvoyer une référence constante.

[poukill]

Merci à vous trois. C'est sur ce point que j'hésitais!
On renvoit bien une référence, c'est à dire l'objet lui même en fait...

Je viens de résoudre de mon côté un autre problème, je vous le soumet rapidement, pour voir si c'est pas complètement débile. Je crois qu'il y a peu de règles générales, donc bcp de possibilités, mais peut-être y a t-il des choses à ne pas faire?

J'ai une classe Warping qui fait son boulot dans le cadre de mon programme. Elle possède un constructeur avec plusieurs arguments, qui va à son tour appeler quelques fonctions membres assez spécialisées pour sauvegarder des Points de controle dans un fichier d'un nom précis, etc...
Le problème, c'est que j'aurai bien besoin d'appeler cette Classe Warping pour autre chose plus tard! Et passer des arguments que l'on a pas, ça pose problème!

J'ai donc pensé à une surchage de constructeur, qui va appeler à son tour des fonctions membres, toutes surchargées, car il ne faut pas faire exactement la même chose...

Ces surcharges sont-elles une bonne idée?

Merci