Discussion :

[Avatar36]

Bonjour,

J'essaye en vain de faire un accesseur pour un vecteur d'une classe. J'ai fait des accesseurs pour tous les attributs de ma classe mais je n'arrive pas à faire celui du vecteur. J'utilise Qt mais à prioris ça n'a pas d'incidence sur mon problème. Je précise que j'ai cherché déjà plein d'exemples sur le net et qu'ils ne marchent pas chez moi, inutile de m'accabler de reproches.

voici la déclaration dans le .h:

Code :

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

1
2
3
std::vector<QString> genres[5];
 
const std::vector<QString> &getGenres();

et dans le .cpp:

Code :

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

1
2
3
4
const std::vector<QString>& Film::getGenres()
{
    return genres;
}

C'est la copie conforme d'un des exemples que j'ai trouvé mais il me renvoie l'erreur: invalid initialization of reference of type 'const std::vector<QString>&' from expression of type 'const std::vector<QString>*'
Au passage, est-ce que vous pouvez me donner le code pour faire un Set pour modifier les valeurs du vecteurs?
Merci d'avance.

Cordialement

[Ehonn]

Bonjour

Remplace

Code :

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

std::vector<QString> genres[5];

par

Code :

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

std::vector<QString> genres;

Le deuxième est un tableau (taille dynamique) de QString.
Le premier est un tableau (taille fixe à 5) de tableau (taille dynamique) de QString.

Si ta méthode ne modifie pas l'objet, tu "dois" l'indiquer :
Remplace

Code :

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

const std::vector<QString> &getGenres()

par

Code :

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

std::vector<QString> const & getGenres() const

et

Code :

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

const std::vector<QString> &getGenres()

par

Code :

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

std::vector<QString> const & Film::getGenres() const

PS: Utilise la balise [CODE]

[koala01]

Salut,

Maintenant que l'on t'a donné la solution, je tiens quand meme à insister sur le fait que, à mon sens, tu ne devrais pas prévoir un accesseur sur ton vecteur de Qstring, pas plus que tu ne devrais prévoir un mutateur (que je subodore que tu as aussi prévu) d'ailleurs!

Ce que tu aurais très largement intérêt à faire, c'est de réfléchir aux services que tu es en droit d'attendre de la part des ta classes qui sont en rapport avec la présence de ce tableau.

Car il existe une règle érigée en loi qui s'appelle la loi de Déméter qui nous dit que, si un objet de type A (ta classe Film) utilise en interne un objet de type B(le std::vector<QString>), l'utilisateur de la classe A (la classe Film) ne devrait pas avoir à connaître la classe B pour pouvoir utiliser son objet de type A.

C'est encore plus vrai pour tout ce qui a trait aux conteneurs : Typiquement, il ne devraient servir qu'au maintient en interne des données utilisées par la ta classes

[ternel]

Rien n'empêche, par contre, de prévoir un itérateur... si c'est dans le sens réel de la classe. (en ce cas, prévoir a la fois begin() et end(), et un ++)

L'itérateur masque le vecteur, sans cacher la sémantique de collection de genres.

[PilloBuenaGente]

Bonsoir,

L'itérateur masque le vecteur, sans cacher la sémantique de collection de genres.

Excusez moi, mais en quoi l'iterateur masquerait-il le vecteur ? Pour appeler un iterateur, on est obliger de specifier son conteneur non ? (à part peut être pour le c++11 avec auto ?)

[Bousk]

Non parce que tu itères sur les objets contenus dans la collection, quelle que soit la colletion.

[Avatar36]

Mon problème est résolu, le code marche. En fait j'avais déjà essayé le code mais il n'avait pas marché. J'ai fermé puis réouvert QtCreator et là ça a marché sans buguer -_-'
Merci pour vos réponses. Concernant la loi de Déméter, cela voudrait-il dire qu'il ne faut pas utiliser de vecteur dans une classe? Car il se trouve que c'est exactement ce qu'il me faut. A ce moment là, (je compare avec Java où tous les types sont des objets) cela voudrait dire qu'il ne faut pas utiliser de int, QString etc... dans une classe? J'avoue ne pas très bien saisir cette remarque.

[koala01]

Mon problème est résolu, le code marche. En fait j'avais déjà essayé le code mais il n'avait pas marché. J'ai fermé puis réouvert QtCreator et là ça a marché sans buguer -_-'
Merci pour vos réponses. Concernant la loi de Déméter, cela voudrait-il dire qu'il ne faut pas utiliser de vecteur dans une classe? Car il se trouve que c'est exactement ce qu'il me faut. A ce moment là, (je compare avec Java où tous les types sont des objets) cela voudrait dire qu'il ne faut pas utiliser de int, QString etc... dans une classe? J'avoue ne pas très bien saisir cette remarque.

Non, cela veut juste dire que ton vecteur doit être correctement encapsulé et que l'utilisateur de ta classe n'a pas à savoir que tu utilise un std::vector, un QList, un tableau de taille fixe ou un tableau de taille dynamique géré à la main.

Ce genre d'information correspond typiquement à ce que l'on appelle un détail d'implémentation! La solution consiste à fournir "tout ce qu'il faut" à l'utilisateur de la classe pour qu'il puisse l'utiliser sans avoir besoin de s'inquiéter de ces détails. Par exemple :

• un alias sur le type d'itérateur utilisé par la collection te permettant de fournir les fonctions begin, end et find, si cela s'avere utile
• une fonction addXXX (nom à adapter) permettant de rajouter une information dans la collection
• d'autres fonctions en rapport avec la présence de la collection, en fonction des besoins queta classe doit satisfaire

[Avatar36]

Merci pour cette réponse. C'est on ne peut plus clair il me semble. C'est bien de la manière dont j'ai procédé.

Cordialement

[koala01]

Heuu... j'ai juste oublié une chose importante : à aucun prix il ne faut un getVector() ou un setVector(std::vector<> const &) !!!!

Et j'ai l'impression que tu as, justement, fourni ces deux fonctions

[Avatar36]

C'est effectivement ce que j'ai fait. Mais quel est le problème du coup? Et comment puis récupérer mon vecteur alors? Car mon but est effectivement de renvoyer un tableau dynamique. Dans mon cas c'est pour ranger les acteurs d'un film. Et comme il n'y a pas forcément le même nombre d'acteurs entre un film et un autre, un tableau dynamique me semblait adapté. Mais pour ça je suis obligé de le stocker dans mon objet "film".

[ternel]

Le film n'a pas à proposer à un utilisateur de trier l'ordre de ses auteurs.
C'est une propriété interne.

Un film ne changeant pas d'auteur une fois réalisé, il ne devrait y avoir que des constructeurs et des fonctions de lecture.
Inspire-toi de <algorithm> pour l'usage des itérateurs dans le constructeur

[Bousk]

C'est effectivement ce que j'ai fait. Mais quel est le problème du coup? Et comment puis récupérer mon vecteur alors?

Quelle est la plus-value d'une classe avec SetVector et GetVector plutôt que de manipuler directement le vector en question ?

[Avatar36]

Et bien c'était pour respecter l'encapsulation
Sans ça tout serait public. Concernant l'ordre, à vrai dire je n'y accordais pas d'importance. Je souhaitais que le logiciel aille récupérer des infos sur internet et remplirait donc tout seul ces cases. Mais même si les infos sont rentrées à la main, elles seront enregistrées dans l'ordre dans lequel elles seront rentrées. Je ne comprends pas bien le problème. De plus, si le logiciel récupère les mauvaises infos ou n'importe quoi d'autre, l'utilisateur doit être en mesure de corriger les erreurs. D'où ma volonté de faire un modificateur pour chaque variable.

[Iradrille]

Et bien c'était pour respecter l'encapsulation
Sans ça tout serait public.

Si tu as un getter et un setter pour un attribut, autant le mettre public.

Tu peux permettre de modifier un élément du vecteur, sans pour autant exposer le vecteur.

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
class Foo {
   std::vector<int> m_vec;
 
public:
   void add(int val) { m_vec.push_back(val); }
 
   void data(int ind, int val) { m_vec.at(ind) = val; }
   int data(int ind) const { return m_vec.at(ind); }
   int& data(int ind) { return m_vec.at(ind); }
};
 
Foo f;
for(int i=0; i<5; ++i) { f.add(i); } // ajoute 5 éléments
std::cout << f.data(1); // affiche le 2eme élément du vector
f.data(2, 10); // set le 3eme élément à 10
f.data(3) = 42; // set le 4eme élément à 42

[ternel]

Globalement, l'encapsulation ce n'est pas "les attributs sont privés", mais un principe plus large.
Du point de vue de la classe, ça ressemble à "je dis ce que je peux faire, pas comment".

La partie publique d'une classe est plus orienté "métier" que la partie privée, plus haut niveau.

Le std::vector<std::string> est un détail, les auteurs sont utiles.
Pour des raisons de performance, tu pourrais vouloir remplacer le vector par une liste, un arbre ou un zergling, ca ne doit impacter ni l'utilisation de la classe, ni même sont interface publique.

Pour le protégé c'est un peu plus négociable, même si je préfère personnellement le laisser invariant.

[Avatar36]

Dans un cours sur un site, il est écrit en gros que tous les attributs d'une classe doivent être privés. Le risque étant que sinon on peut appeler la variable de la classe sans le vouloir. Même si je suis d'accord que dans mon cas tout public ou non ça revient au même sauf que je ne risque pas de modifier mes attributs du film sans le vouloir. Et si je suis ton exemple avec le vecteur, je vois pas trop la différence avec moi. Si tu remplace Foo par Films et tu rajoutes les attributs du films, tu as à peu près le même code que moi . Ou alors c'est moi qui ai pas vu la différence.

[Bousk]

Et bien c'était pour respecter l'encapsulation

Une encapsulation qui n'apporte rien, c'est inutile.

A partir du moment où tu as un setter aussi explicite qui remplace le membre, c'est strictement équivalent.
Je pense pas qu'il faille être beaucoup plus stupide pour écrire maClass.SetVector(monVector); que maClass.vector = monvector;. Donc le risque d'appeler la variable sans le vouloir..
Commençons par utiliser la const-correctness et ça arrivera moins.

[Avatar36]

Ben c'est quand même bien quand on part de zero. Mais après cela s'adresse à de vrai débutants et il est vrai que quand on partage le code, il vaut certainement mieux respecter cette règle pour éviter les conflits donc le faire tout le temps n'est pas mal, c'est simplement plus lourd. Mais effectivement dans mon cas c'est inutile. De manière générale je pense pas que ce soit très utile quand on est seul à travailler sur un projet. En tout cas merci, ça m'a pas mal éclairé. Petit à petit je m'approcherai d'un code propre et clair.

[Iradrille]

Et si je suis ton exemple avec le vecteur, je vois pas trop la différence avec moi. Si tu remplace Foo par Films et tu rajoutes les attributs du films, tu as à peu près le même code que moi . Ou alors c'est moi qui ai pas vu la différence.

Il y à une différence majeure :
Imaginons que demain tu ai besoin d'utiliser un autre type de conteneur, une list, ou une map par exemple, l'utilisation reste identique : seul le code de la classe change.
Tu n'as donc pas à savoir quel type Foo (ou Film) manipule en interne.