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.

[Luc Hermitte]

Si c'est pour faire des accesseurs/mutateurs inlinables, on perd un peu de l'intérêt de la chose à faire de simples copies.

Bref, tout cela a déjà été discuté à maintes reprises => recherche
De plus, c'est traité dans la FAQ...

[Médinoc]

On peut toujours les garder inline tant qu'on ne les complique pas, puis les passer non-inline dès qu'on fait un truc compliqué dedans...

D'une manière générale, le getter sera facilement inline puisqu'on y fait rarement une validation des données.
Par contre, le setter peut faire l'objet de contrôles plus compliqués.

[Jérôme_C]

J'ai cherché, mais je n'ai pas trouvé.

Dans la FAQ, les accesseurs sont traités, mais cela n'apporte pas une réponse clair à ma question.

Je suis tombé sur une discussion sur le sujet précisément après coup. Apparemment c'est un débat de fond qui tombe régulièrement, dans les autres sujets. En gros, le sujet annexe récurrent.

Au moins, j'aurais eu une réponse claire, même si on dérive vite... Merci

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

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

[koala01]

Salut,

A vrai dire, le débat fait rage parce qu'il pose la question de choisir entre pérénité et controle VS rapidité potentielle d'exécution (pas si potentielle que cela, en fait )

J'aurais, mais ce n'est qu'un avis perso , personnellement tendance à préférer les accesseurs/mutateurs dés le moments où je devrais créer une structure disposant de plusieurs données de type identique et, pire encore, si je ne sais pas à la base combien de donnée de meme type seront utilisées...

Cela me permettra, entre autre, de péréniser l'ensemble du code qui sera basé sur cette structure, tout en me permettant de changer d'optique de maintient en mémoire (passer plus facilement, par exemple de deux variables séparée à un tableau "C style", à un vecteur, une liste ou n'importe quel autre conteneur )

Pour les variables "uniques" (entend par là, les variables qui sont les seules d'un type donné dans la structure ), je dirais qu'il faut voir si tu accepte l'idée qu'elle soit modifiée "de l'extérieur" ou non, de voir le controle que tu veux imposer sur les modifications et de pondérer la réponse avec le controle le type en lui-même permet déjà, afin de décider s'il faut améliorer le controle sur la donnée (auquel cas, on passerait sur une variable private ou protected et sur un couple d'accesseur/mutateur... ou peut etre l'un des deux seulement ) ou si tu estimes que le controle est suffisant (auquel cas, elle peut très bien rester publique )

Mais j'ai bien conscience que cette optique reste très abstraite et très personnelle, et donc, en gros, la meilleure réponse que tu pourra sans doute obtenir tourne autour du "ca reste à toi de l'évaluer à chaque fois"

[Kujara]

A vrai dire, le débat fait rage parce qu'il pose la question de choisir entre pérénité et controle VS rapidité potentielle d'exécution (pas si potentielle que cela, en fait )

Encore un debat bien inutile, s'il fait rage.

Ca fait des années que les compilateurs savent parfaitement inliner des trucs aussi simple que des accesseurs / mutateurs.

Et pour ceux qui n'y croient pas( vous avez tort), il reste toujours forceinline ( __forceinline sous vc++, __attribute__(( always_inline)) sous g++ ), qui vous quaranti des perfs identiques a une variable publique...

[Médinoc]

Par contre, comme je l'ai dit, il faut qu'ils soient accessibles pour être inlinables.

Donc, soit ils sont définis dans chaque unité de compilation (typiquement en inline dans le fichier header, plutôt que dans un namespace anonyme), soit la génération de code à l'édition de liens (link-time code generation) doit être activée.

[koala01]

Je n'ai jamais dit qu'il était utile ou non stérile... j'ai dit que l'on rencontre régulièrement des gens qui se "chamaillent" sur la question...

Personnellement, je me demande d'ailleurs si perdre, en définitive et au pire quelques fréquences d'horloges représente réellement un drame par rapport au fait de devoir reparcourrir tout un code parce qu'on a, tout simplement, décidé de changer son fusil d'épaule concernant la manière dont certaines données sont maintenues au sein d'une structure...

Autant le dire: je fais partie de ceux qui préfèrent la pérénité du code

[Jérôme_C]

Bonjour,

Tout d'abord merci pour toutes ces réponses.

Même si la réponse de Luc n'est pas la plus claire, c'est celle qui finalement m'aide le plus. Elle m'a permis de creuser un peu tout ces concepts d'objets, interface, propriétés, ainsi que par ailleurs les classes, structures, variables membres et getter/setter.

J'ai l'impression que tout tient dans le fait de concevoir ou non en programmation orientée objet, la carte n'est pas le territoire, et l'instance de classe n'est pas l'objet. Avoir des classes, des variables membres privés et des getter/setter ne fait pas forcément un programme orienté objet.

Si j'ai bien compris ce que vous avez dit, c'est au programmeur de faire de l'objet. S'il ne fait pas de l'objet, juste des classes, car les classes c'est bien (autant que les structures), les getter/setter tel que je les ai décrits sont un artifice inutile.

Est-ce que je commet une hérésie en voulant résumant le problème ainsi en moins d'une page ?

[Luc Hermitte]

Même si la réponse de Luc n'est pas la plus claire, c'est celle qui finalement m'aide le plus.

Laquelle ? S'il n'y en a qu'une à retenir, c'est celle-là:

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

(C'est sûr qu'il faut faire un peu de recherche après. La FAQ étant un point de départ)

Avoir des classes, des variables membres privés et des getter/setter ne fait pas forcément un programme orienté objet.

Oui. Parfaitement.

Est-ce que je commet une hérésie en voulant résumant le problème ainsi en moins d'une page ?

Pas une hérésie. Mais il y a tellement d'aspects connexes qui vont orienter vers des accesseurs et pas de mutateurs, ou le contraire, ou rien.
-> immuabilité
-> propriétés internes à des hiérarchies
-> invariants
-> véritables services rendus vs couplage qui va chercher les données membres (ie rupture d'encapsulation)
-> etc

Même les javaistes ont des débats sans fin. Ils ont des frameworks qui les poussent à des couples accesseurs/mutateurs dans tous les sens. Et certains se rendent bien compte que c'est ridicule avec les classes qui au fond ne sont que des structures agrégeant des données sans fournir d'autre service.


Quant à l'inlining ... c'est d'un non pertinent. D'abord avoir un programme dont le design tient la route. Ensuite, on optimise ce qui l'est quand c'est reconnu comme point faible.

[Jérôme_C]

Luc, c'était bien de cette réponse dont je parlais.

La FAQ m'a été d'un grand secours...


Je crois avoir bien compris l'aspect lecture seule, lecture-écriture. J'ai même rencontré des écritures-seulement...

[koala01]

Je crois avoir bien compris l'aspect lecture seule, lecture-écriture. J'ai même rencontré des écritures-seulement...

A vrai dire, cela peut meme arriver beaucoup plus souvent qu'on ne le pense...

Il "suffit" que la donnée serve de manière uniquement interne (par exemple: le nombre de tour minute d'un moteur de voiture à boite automatique, qui permet de déterminer s'il faut ou non changer le rapport) mais qu'il faille disposer d'un "moyen externe" de faire varier la valeur...

L'exemple est très mauvais car il utiliserait plutot un comportement "augmenter" et un autre "diminuer" qu'un comportement "régler à"... mais l'idée est là