Discussion :

[grunk]

Bonjour à tous,

Je m'interroge sur la façon de faire des getter sur des membres de classe.
En imaginant la classe suivante :

Code :

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

1
2
3
4
5
6
7
8
9
class MaClasse
{
    public:
        MonObjet GetObjet();
        MonObjet& GetObjet2();
 
    private:
        MonObjet mObjet;
}

Mon background de dev java me fait plutôt pencher vers un retour par référence sur un Getter.
Cependant j'ai l'impression qu'en C++ c'est une mauvaise idée car si je fait :

Code :

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

1
2
3
MonObjet& resultat = o.GetObjet2();
//Ici destruction de MaClasse pour X raisons
resultat.methode(); // Crash ?

A aucun moment une référence sur un objet va m’empêcher de détruire l'objet initial et par conséquent me mettre quelque peu dans la mouise me trompe je ?

Du coup un retour par copie me semble plus sur , mais cela veux également dire que si l'objet retourné fait 10M en ram , je vais bouffer 10M pour potentiellement pas grand chose le temps que le scope de la copie se termine, non ?

Bref je suis un peu perdu sur la solution à adopter.

Toujours en se basant sur l'exemple de classe précédent si je fait un setter de ce type :

Code :

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

1
2
3
4
void Classe::SetObjet(MonObjet obj)
{
    mObjet = obj;
}

Que devient la mémoire précédement allouée par mObjet ? Est ce qu'elle sera libérée une fois la classe complète détruite ou simplement lors de la nouvelle copie ?

Merci

[prgasp77]

Bonjour,

si tu as besoin qu'un élément extérieur à ta classe accède et utilise un élément qui la compose, tu te retrouves dans un cas où plusieurs intervenants doivent se partager une ressource. J'ai moi aussi appris la POO dans les années 2000, où il était courant d'utiliser les accesseurs de manière systématique. Depuis quelques années, j'ai appris à m'en passer dans 19 cas sur 20 ; et je m'en porte bien mieux.

Si ce besoin est confirmé, il te faut mettre en palce une stratégie de partage de ressource. Elle peut être très simple (imposer que l'objet o doit exister quand on utiliser une référence récupérée via son accesseur) ou plus échafaudée ; je pense notamment au couple std::shared_ptr et std::weak_ptr. Mais sincèrement, est-ce que cela a du sens de conserver une référence vers un élément d'un objet quand l'objet a été détruit ?

EDIT :
Aparté : C++ a une gestion des variables et méthodes const qui apporte beaucoup :; si tu dois écrire un getter :

Code :

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

1
2
3
4
5
class Bobafett
{
    const Object& getObject() const;
    Object& getObject();
}

La première version retourne une référence vers un objet constant, il est donc possible d'appeler la méthode getObject() d'un Bobafett constant. La seconde (optionnelle), permet de modifier l'objet retourné, elle ne peut être appelée sur un Bobafett non constant.


Un point que je n'ai pas abordé et c'est une erreur. Tu veux peut-être partager une ressource qui n'appartiendrait pas à la classe.

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
class Obiwan
{
    Object& _resource;
public:
    Obiwan() : delete;
    Obiwan(Object& resource) : _resource(resource) {}
    /* Copy, assignment, move ... */
    const Object& resource() const { return _resource; }
    Object& getObject() { return _resource; }
}
 
 
int main(void)
{
    Object theResource;
    Obiwan kenobi(theResource);
   /* ... */
    const Object& kenobisobject = kenobi.resource();

Les contraintes sont les même que dans l'exemple que tu as cité, mais à la simple vue de la déclaration de la classe Obiwan, un développeur saura les contraintes imposées à l'utilisabilité de la référence accédée.

[koala01]

Salut,

De manière générale, les accesseurs ( == getters )ne doivent faire qu'une seule et unique chose : permettre d'obtenir une valeur particulière (sous entendu : en aucun cas permettre de modifier cette valeur).

Il y a bien quelques cas particuliers dans lesquels il est "opportun" de permettre de modifier la valeur obtenue (ex : l'opérateur [] de la classe std::vector), mais, dans l'ensemble, ils sont vraiment particulièrement rares

C'est la raison pour laquelle nous insistons toujours énormément sur le fait que les accesseurs soient fournis sous la forme de fonctions constantes uniquement. Cela permettra au compilateur de t'engueuler s'il se rend compte que le "contrat" passé par cette fonction ("je m'engage à ne pas modifier l'objet courant") devait ne pas être respecté

Du coup, tu peux soit renvoyer la donnée en question par valeur, soit le faire sous la forme d'une référence constante (si tant est que ce soit bel et bien un accesseur sur une donnée membre de la classe et non sur une donnée qui doit être évaluée à chaque passage dans la fonction).

A noter que prgasp77 a tout à fait raison : si tu t'amuses à fournir un "plein et entier" sous la forme d'un accesseur et d'un mutateur à toutes les données membres de ta classe, tu perd littéralement tout l'avantage de l'encapsulation.

Du coup, il ne vaut la peine de fournir un accesseur sur une donnée que si cela correspond à un service que l'on est effectivement en droit d'attendre de la part de la classe développée :
on s'attend à ce qu'une classe personne puisse répondre aux question Quel est ton nom? et Quel est ton prénom, à ce qu'une classe Date puisse répondre aux question Quel jour? Quel mois ou Quelle année ? etc, ce qui justifie clairement la présence de fonctions permettant de répondre à ces questions.

Par contre, la loi de Déméter nous dit que l'on ne devrait même pas savoir que la notion de RéservoirDeCarburant existe pour utiliser la notion de Voiture. Il ne sert absolument à rien de fournir une fonciton getReservoire

Et je m'arrêterai là et ne parlerai des mutateurs que si tu en fais explicitement la demande

[foetus]

Toujours en se basant sur l'exemple de classe précédent si je fait un setter de ce type :

Code :

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

1
2
3
4
void Classe::SetObjet(MonObjet obj)
{
    mObjet = obj;
}

Que devient la mémoire précédement allouée par mObjet ? Est ce qu'elle sera libérée une fois la classe complète détruite ou simplement lors de la nouvelle copie ?

Il faut faire gaffe , mais avec le C++11/ C++14 et les déplacements (move)/ Rvalue reference (&&) certaines optimisations du compilateur ont dues être supprimées.

Mais il y avait avant par exemple, des optimisations du compilateur qui s'appellent RVO (return value optimization) et NRVO (named return value optimization).

Dans ton exemple, il y a 2 recopies: 1 pour le passage de paramètre (copie 1) et 1 à l'intérieur de ta méthode (copie 2)
Mais un cas trivial comme dans ton exemple, le compilateur devrait détecter que ta méthode est simple (1 seule affectation) et devrait ne pas faire qu'1 seule copie (par contre peut-être que c'est avec un passage constant par valeur )

Mais ton exemple est mauvais, parce que tu fais une copie dans un objet temporaire qui est détruit après l'appel.
L'objet que tu passeras en paramètre ne sera pas modifié

[grunk]

Merci à tous pour vos réponses , c'est plus clair

[Bousk]

Code :

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

1
2
3
MonObjet& resultat = o.GetObjet2();
//Ici destruction de MaClasse pour X raisons
resultat.methode(); // Crash ?

o est lui-meme une reference vu la syntaxe, si effectivement ta reference est detruite entre temps, t'as un serieux probleme.

A aucun moment une référence sur un objet va m’empêcher de détruire l'objet initial et par conséquent me mettre quelque peu dans la mouise me trompe je ?

En C++ a aucun moment on t'empeche de te tirer une balle dans la tete, pour autant on evitera.

Code :

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

void f(const T& t) { delete const_cast<T*>(&t); }

Est possible, moyennant d'eventuelles erreurs de compile, pour autant tu le verras surement jamais en "vrai".