Discussion :

[manonoc]

bonjour,

Pour ma classe de vecteur, j'ai mis dans le .h:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
---------------------------------------------------------------
	const SCALAR			GetX() const	{return x;}
	const SCALAR			GetY() const	{return y;}
	const SCALAR			GetZ() const	{return z;}
 
	void					SetX(SCALAR s)	{x = s;}
	void					SetY(SCALAR s)	{y = s;}
	void					SetZ(SCALAR s)	{z = s;}
 
	SCALAR&					RefX()			{return x;}
	SCALAR&					RefY()			{return y;}
	SCALAR&					RefZ()			{return z;}
---------------------------------------------------------------

mais j'aurais tendance à ne me servir seulement de Ref (pour avoir une référence, mais aussi pour les affectations):

Code :

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

	e.RefX() = fabs(max0 - min0) / 2;

quand il faudrait mettre

Code :

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

	e.SetX(fabs(max0 - min0) / 2);

Finalement à quoi sert Set si on a un Ref ?

(vous allez me dire "quand on veut faire une affectation sans avoir besion d'une référence", mais alors finalement Set ne me sert pas)

par exemple les opérations du genre:

Code :

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

 e.RefX() *= 3;

sont plus rapides que:

Code :

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

 e.SetX(e.GetX() * 3)

non ?
(mais je suppose que cela se décide dans le compilo)

merci

[Luc Hermitte]

A quoi sert d'encapsuler si tu décapsules aussitôt avec un ref, ou même avec un couple set/get ?

Là, je ne vois pas l'intérêt de ne pas donner un accès direct aux 3 ordonnées.

[manonoc]

A quoi sert d'encapsuler si tu décapsules aussitôt avec un ref, ou même avec un couple set/get ?

Là, je ne vois pas l'intérêt de ne pas donner un accès direct aux 3 ordonnées.

avant je les avait mise en public, mais pour avoir un meilleur controle, je les ai mises en protected.
Sinon, comment veux tu mettre à jour d'une manière controlée les variables protected ?

Cela sert au controles de modifications pour les fonctions const, les arguments const:
SCALAR SqDistPointOBB(const Vector3& p) const;

les arguments passent par référence, donc plus rapidement que par copie, mais on ne peut pas les modifier.

[JolyLoic]

Et quel contrôle crois-tu avoir gagné en faisant ainsi ?

Pour plus de détails, voir le thread http://www.developpez.net/forums/d58...-constructeur/ qui bien que partant d'une question différente s'est assez attardé sur ce sujet.

[manonoc]

Et quel contrôle crois-tu avoir gagné en faisant ainsi ?

Pour plus de détails, voir le thread http://www.developpez.net/forums/d58...-constructeur/ qui bien que partant d'une question différente s'est assez attardé sur ce sujet.

Luc Hermitte parle du fait que s'il y a des accesseurs (set et get) alors pas la peine de mettre en protected, il faut mettre les variables en public.
Mais alors à quoi sert le const pour une fonction ?

Pour moi, il faut mettre en protected les variables membres, et faire des getters et setters. On protège ainsi ses accès.
Evidemment, quand on donne un Ref sur une variable membre, c'est comme si elle était publique. Mais ça se passe dans une fonction qui a le droit de modifier l'instance, donc tout va bien.

Sinon, je pense avoir gagné la sureté, que si je mets une fonction const, je serais sur que ma classe ne sera pas modifiée:

Dans une fonction prenant en argument un const vector3, je ne pourrais pas utiliser les Ref.

Il est bon d'avoir des fonctions que testent la classe, et des fonctions qui modifient la classe.

Comment faites vous ?

[JolyLoic]

Je ne suis pas certain de suivre ton raisonnement...

Si tu mets ta variable membre en public, on ne pourra quand même pas la modifier dans une fonction où on a passé un vecteur constant.

[Jean-Marc.Bourguet]

Pour moi, il faut mettre en protected les variables membres, et faire des getters et setters. On protège ainsi ses accès.

Contre qui? Contre quoi?

Evidemment, quand on donne un Ref sur une variable membre, c'est comme si elle était publique. Mais ça se passe dans une fonction qui a le droit de modifier l'instance, donc tout va bien.

Il me semblait que le contrôle d'accès était là pour limiter les endroits où on accède à la représentation interne avec deux objectifs principaux:
- pouvoir contrôler plus facilement que les invariants sont respectés,
- pouvoir changer la représentation interne.
Fournir une réference vers un membre, ça n'aide en rien le contrôle des invariants et ça contraint l'évolutivité de la classe.

Comment faites vous ?

Soit la classe est un conteneur -- et les membres sont publics -- soit elle est une valeur -- et elle est généralement invariante -- soit elle est une entité -- et on modifie son état interne avec une granularité autre que membre à membre.

Pour moi, tu es dans le second cas: tu fournis des constructeurs et des fonctions qui vont bien mais la première possibilité n'est pas exclue.