Utiliser un objet d'une classe dans une autre

Salut à tous, enfaîte j'ai un soucis avec mon code Qt : Je possède 2 classes (disons a et b), j'aimerai créer une List de a dans la classe b, donc dans le "private" de ma classe b, je définis cela : QList<a> List_a; sauf qu'il me renvoie que "a" n'est pas déclaré, donc je vois pas trop comment faire...

Merci de votre aide :)

Salut,

Comment as tu écris tes deux classes? (je ne te donne pas la réponse de suite afin que tu puisses comprendre d'où vient ce problème).

Alors j'ai résolu (contourné) le problème en utilisant un QList, mais je sais pas trop si c'est cool :/ j'aimerai savoir pourquoi cela ne marche pas :/

la classe A (JSon) :

Code:

---

1 2 3 4 5 6 7 8 9 10

class Parametre;   class JSon { public: JSon(); QList<Parametre> Param_Vect; private: };

---

La classe B (parametre) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

class Parametre { public: Parametre(QJsonObject object); QString m_id; QString m_nom_D; QString m_nom_E; QString m_nom_F; QString m_desc_D; QString m_desc_E; QString m_desc_F; QJsonArray m_choix_D; QJsonArray m_choix_E; QJsonArray m_choix_F; QJsonArray m_code_choix;   private:     };

---

Ici, Parametre est déclaré mais pas défini (c'est donc un type incomplet).
Mais si tu rajoutes un #include "Parametre.h" avant la définition de la classe JSon...

Ok enfaite c'est bon ca marche avec le vecteur c'est cool :)
J'avais déjà mis les includes dans le code (mais pas dans le post) donc je pense que ce n'etait pas ca, c'etait un problème d'index car j'ai indiqué la taille du QVector et ca a marché :)
Enfin bref merci :)

Edit : J'ai une autre question dans la même veine : j'ai une instance de ma classe JSon nommé "test" dans mon main, maintenant j'aimerai récuperer un attribut (public) de cette instance pour l'utiliser dans une 3eme classe, sauf que je m'y parviens pas, Qt ne me le propose pas en autocomplétion (donc j'en déduis que c'est faux... Mais pourquoi ? :/

- je n'ai rien compris au problème initiale
- ne fais pas trop confiance à l'auto-complétion qui peut facilement se planter/perdre selon le projet et l'IDE

Bonjour.

Citation:

---

Envoyé par Agudolive

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

class Parametre { public: Parametre(QJsonObject object); QString m_id; QString m_nom_D; QString m_nom_E; QString m_nom_F; QString m_desc_D; QString m_desc_E; QString m_desc_F; QJsonArray m_choix_D; QJsonArray m_choix_E; QJsonArray m_choix_F; QJsonArray m_code_choix;   private:     };

---

---

Mettre des variables membres publiques est une mauvaise pratique.
Il est préférable d'encapsuler les données et de fournir à l'utilisateur des accesseurs (getters) et des mutateurs (setters).

Exemples de motivations :

• Si un jour tu veux fusionner m_nom_D, m_desc_D et m_choix_D en un seul objet (pareil pour E et F), si tu as fait de l'encapsulation, tu n'auras pas besoin de changer le code des utilisateurs de ta classe Parametre.
• Si un jour ton programme est lent à compiler et que beaucoup de modules incluent Parametre.h, si tu as fait de l'encapsulation, tu pourras gratter du temps de compilation en utilisant la technique du pointeur opaque. Ainsi, les modules qui incluront Parametre.h (directement ou indirectement) ne seront plus forcément obligés d'inclure <QJsonArray>.
  Par contre, si tu n'as pas fait d'encapsulation, tu ne pourras pas car ce serait trop long et pénible de changer le code dans chacun des modules qui incluent Parametre.h.

Remarque : Si tes accesseurs et des mutateurs sont en ligne, il n'y aura pas de perte de performance par rapport à l'absence d'encapsulation.

Salut,

Citation:

---

Envoyé par Pyramidev

Bonjour.

Mettre des variables membres publiques est une mauvaise pratique.
Il est préférable d'encapsuler les données et de fournir à l'utilisateur des accesseurs (getters) et des mutateurs (setters).

---

Oh, par pitié, non!!!!

Avoir des accesseurs, cela peut se comprendre si (et SEULEMENT SI) on est en droit d'estimer que l'obtention de la donnée en question correspond bel et bien à un service qui doit être rendu par notre classe.

Par contre, la présence des mutateurs est -- non seulement -- en contradiction flagrante avec la loi de Déméter(*), mais elle est aussi le symptôme fort que l'on réfléchit beaucoup plus à notre classe en terme des données qu'elle contient qu'en termes des services qu'elle doit rendre.

Si, d'une manière ou d'une autre, on en vient à fournir un accesseur ET un mutateur sur un donnée quelconque de notre classe, on en revient SYSTEMATIQUEMENT au même problème que si la donnée avait été placée dans l'accessibilité publique : c'est à l'utilisateur de notre classe de veiller à respecter TOUTES LES REGLES (pré conditions / post conditions / invariants) imposées par la classe, alors que cela aurait du être le travail ... de la classe, justement.

Alors, pour en revenir au problème d'origine, peut-être que la notion de paramètre ne doit être effectivement envisagée que pour ce qu'elle est : un agglomérat de données de types divers et variés, quitte à ce que ce soit la classe / les fonctions qui le manipule(nt) qui s'occupe de faire respecter les règles que l'on souhaite imposer sur cet agglomérat.
(*) En fait, la loi de Déméter s'énonce comme suit

Citation:

---

Envoyé par loi de Déméter

Si un objet de type A utilise en interne un objet de type B, l'utilisateur de l'objet de type A n'a pas à devoir connaitre le type B pour manipuler le type A.

---

Mais, je commence à préférer un énoncé plus personnel qui serait proche de

Citation:

---

Si un objet a de type A utilise en interne une donnée b de type B, l'utilisateur de l'objet a n'a pas à connaitre la valeur de a.b pour pouvoir manipuler son a

---

car le problème n'est pas forcément de permettre (ou non) à l'utilisateur de récupérer des données (plus ou moins) complexes sous une forme proche de celle qui est utilisée pour les représenter, mais bien de forcer l'utilisateur à connaitre exactement la valeur de ces données afin de déterminer par lui-même, au risque d'oublier une règle ou une obligation quelconque, une "nouvelle valeur" pour cette donnée.

Bien sur, cela s'écarte de "la lettre" de la loi de Déméter, mais, AMHA, cela se rapproche bien d'avantage de son sens ;)

À noter que les Data Transfer Objects (DTO) (Objets de Transport de Données) sont exempts des règles d'encapsulation, parce qu'exposer les données est le seul service qu'ils rendent.