Discussion :

[Jérôme_C]

Bonjour,

Je me familiarise peu à peu avec un projet développé par des personnes qui ne sont plus dans la société. Et je me pose une question :

Quel est l'intérêt de créer des propriétés privés dans une classe si dans cette même classe des getter/setter publics sont systématiquement créés pour ces propriétés ?

Code l'entête :

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
class CCaracteristquesObjet  
{
public:
	CCaracteristquesObjet();
	virtual ~CCaracteristquesObjet();
 
	double GetHauteur();
	void SetHauteur(double value);
 
	double GetLargeur();
	void SetLargeur(double value);
 
protected:
	double m_dHauteur;
	double m_dEmprise;
};

Code Un getter/setter type trouvé partout dans le code :

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

1
2
3
4
5
6
7
8
9
double CCaracteristquesObjet::GetHauteur()
{
	return m_dHauteur;
}
 
void CCaracteristquesObjet::SetHauteur(double value)
{
	m_dHauteur= value;
}

Personnellement, j'aurais tendance à considérer comme équivalent et plus simple de supprimer les getter/setter et d'avoir des propriétés publiques.

Est-ce que dans certains cas, tel que sont ces getter/setter ou après quelques légères modifications, il y aurait un réel intérêt de créer de getter/setter de cette façon ?

[loufoque]

Argh de la notation hongroise !

[poukill]

Y'a pas de réel intérêt, si ce n'est l'encapsulation à tout prix dans ton cas.
On pourrait considérer que ce n'est pas normal d'avoir accès à des variables directement car tu en fais ce que tu en veux. L'intérêt d'avoir des méthodes est le contrôle. Tu ne laisses pas le client de ta classe faire n'importe quoi. Tout est correctement initialisé, et la classe respecte ses préconditions, postconditions et invariants.

Dans certains cas, il arrive cependant qu'on laisse des variables publiques, mais ce sont des pratiques à éviter, globalement.

Hope it helps !

[Médinoc]

L'avantage, c'est que tu peux à tout moment changer ce qu'il y a "sous le capot".
Comme par exemple, rajouter un contrôle si tu n'accepte que les valeurs positives, etc.

Par contre, je conseillerais de toujours implémenter ces accesseurs en inline, ainsi il n'y aura pas d'impact sur la performance.

[poukill]

Oui enfin de toute façon c'est le compilo qui décide alors... C'est quand même un peu mitigé cet "inline"...

[Médinoc]

En effet, mais si la fonction est dans un autre fichier source, le compilo ne pourra absolument pas l'inliner.
Donc, il faut lui donner au moins la possibilité de le faire.

[NiamorH]

Oui enfin de toute façon c'est le compilo qui décide alors... C'est quand même un peu mitigé cet "inline"...

Je suis pas d'accord, on arrive a savoir assez facilement ce que parviendra ou pas le compilateur à inliner. Dans ce cas, il n'y a aucun doute (je peux me tromper mais bon...) sur le fait qu'il y arrivera.

Si on ne pouvait pas être sûr de certains inline, les bases de la métaprog seraient remises en cause. (en fait, par "c'est le compilo qui décide", il faut plutôt entendre "le compilateur n'est pas censé indiquer une erreur lorsqu'un inline est impossible à effectuer").

Jérôme, pour la réponse, celles que Médinoc et Luc t'ont donné me semblent relativement claires :

Dans l'état actuel, cette encapsulation ne sert à rien, mais si dans le futur on souhaite contrôler un peu mieux l'accès à la donnée (ajouter un contrôle pour ne pas la rendre inférieure à zéro par exemple), on pourra le faire facilement :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
inline double
CCaracteristquesObjet::GetHauteur() const
{
  return m_dHauteur;
}
 
inline void
CCaracteristquesObjet::SetHauteur(double value)
{
  if (value >= 0.)
    m_dHauteur= value;
}

Le concept de propriété évoqué par Luc me semble intéressant. Luc, disposes-tu d'une définition claire ?

[Luc Hermitte]

Sauf qu'il ne peut pas avoir pas y raison de réponse complète qui tienne en moins d'une page ...

Y'a pas de réel intérêt, si ce n'est l'encapsulation à tout prix dans ton cas.

Il n'encapsule rien du tout. Il expose au contraire toutes ses variables membres.

Il faut commencer par distinguer variables membres et propriétés. Après on peut parler sérieusement.

[Alp]

Qui plus est, il n'y a pas de réponse ultime à cette question.

Pourquoi ? Cela dépend de la nature de ton attribut, entre autres. Tu voudras parfois faire des vérifications avant donner la main au code qui veut s'en servir, d'autres fois des vérifications avant de changer sa valeur.

Par contre, quelle que soit la nature, un avantage de mettre un couple getter/setter est que l'on peut changer le code facilement, et que cela se répercutera sur tout ton programme. En effet, si tu travaillais directement sur l'attribut en public, tu devrais modifier chaque code appelant, ce qui risquerait d'être assez long et désagréable.