Discussion :

[the_angel]

Bonjour,

Je me pose une question simple, vaut-il mieux renvoyer un référence à un objet ou une copie de cette objet avec un getter ?

Je suppose qu'il est préférable de renvoyer une référence pour ne pas surcharger la mémoire.
D'un autre côté, ça va à l'encontre du principe d'encapsulation. Si c'est une donnée critique de la classe on risque ainsi de permettre à l'utilisateur de mettre un objet dans un état invalide...

Au final, est-il conseillé de favoriser la robustesse et de renvoyer des copies d'objet ou de renvoyer des références constantes et faire confiance à l'utilisateur pour ne pas mal les utiliser ?
Mais dans ce cas, comment faire pour récupérer un objet attribut d'une classe et le stocker dans une deuxième en tant que référence ?

Merci d'avance pour vos réponses, bonne journée.

[rouliane]

Bonsoir,

Passer une référence en retour d'un getter c'est absurde, et pas l'interêt du tout. Il faut pouvoir maitriser ce que les utilisateurs vont faire de ton code. Un getter tu passes une copie, c'est tout.

Le setter est là pour pouvoir modifier ton attribut.

Autre point : une référence constante n'est pas modifiable

[Bousk]

Bonjour,

Passer une référence en retour d'un getter c'est absurde, et pas l'interêt du tout.

Faux.
Un getter peut servir à retourner ce que l'on souhaite, et il peut être intéressant de retourner l'élément en soit, et pas une copie. Un utilisateur peut avoir besoin/utilité de cet élément et le droit de le modifier.

Il faut pouvoir maitriser ce que les utilisateurs vont faire de ton code. Un getter tu passes une copie, c'est tout.

Retourner une copie est, amha, une erreur.
Un getter, devrait retourner une const&, que l'utilisateur copiera s'il veut travailler avec une copie. Mais retourner une const& permet de répondre à priori à tous ses besoins.


Donc aucune réponse absolue, tout dépend de ton architecture et ce que tu souhaites faire. Retourner une copie ne me semble jamais une bonne idée, mieux vaut retourner une const&, mais retourner une référence non constante peut être envisageable, toujours selon les besoins/spec/... .

[the_angel]

Merci pour vous réponses.

Je suis d'accord avec Bousk, malgré tout le retour par référence constante permet à l'utilisateur de ne pas utiliser le setter :

Code :

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

1
2
3
4
5
6
7
int i = 5;
const int& cri = i;
int& ri1 = (int&)cri;
int& ri2 = const_cast<int&>(cri);
//cri = 3; // Intedit
ri1 = 3; // i = 3
ri2 = 1; // i = 1

Ce qui est un problème.
D'un côté, c'est le devoir de l'utilisateur de ne pas manipuler les données de l'objet, qu'il n'est pas sensé connaître.
D'un autre, c'est celui du concepteur de ne pas lui en donner les moyens...

Je pense donc continuer à utiliser le retour par référence constante.

Bonne journée.

[Bousk]

Oui j'ai effectivement évincé volontairement le cas const_cast.
Dans un code à priorio correct et normal, un const_cast ne devrait pas s'y trouver.
Après si l'utilisateur fait un const_cast sur ton const& get, je pense qu'il faut
- insulter l'utilisateur
- le laisser tout seul dans sa merde

[the_angel]

Bon bha, merci pour l'avis

Je met en résolu pour la peine.

[bacelar]

J'ai une remarque à 2$.

Je suis à peu près d'accord avec les arguments de cette discussion, sauf que le problème initial est un peu mal cerné.

Si on donne un moyen pour l'utilisateur de faire une connerie, la loi de Murphy nous dit que le problème n'est pas "si cela pourra arriver" mais "quand cela arrivera".
Donc, ne jamais donner à l'utilisateur un moyen pour faire des conneries.

Donc, vous me direz qu'il faut donner des références const, et c'est là que je ne suis pas. Il ne faut pas obligatoirement une référence const mais une référence (const ou non) sur un type d'interface ou de classe ne déclarant que les actions "licites" pour l'utilisateur de ce getter. Cela peut donc multiplier le nombre de guetter, si les cas d'usages sont très différents les uns des autres.

Si l'utilisateur utilise des const_cast, des "down_cast", des reinterpre_cast ou la réflexion en faisant sauter les limites de visibilité, il a franchi la ligne jaune et c'est à lui qu’incombe la responsabilité des disfonctionnement que cela pourrait entraîner.
Mais attention, il faut qu'aucune des actions "valides" de l'utilisateur de la classe ne l'oblige à utiliser ces "cochonneries", et c'est loin d'être évident sans une batterie de test unitaire de la classe dans les cas d'usages identifiés.