Discussion :

[Invité]

Bonsoir,

J'aurais aimé savoir quand construire une classe fille comment le savoir ?

Exemple concret : dans mon projet Qt il y a la classe QAudioInput(QAudioDeviceInfo, QFormat, QObject * parent=0) : on doit ici créer une classe fille qui pointera vers la classe mere ? Car ici on voit voit au paramètre parent ?
Merci d'avance et bonne année.

Cordialement, Gizmo.

[LittleWhite]

Bonjour,

L'histoire des liens parent / fille, ici, sont spécifique au design de Qt. Qt, d'une part, pour une bonne gestion de la mémoire mais aussi pour la hiérarchisation et l'emplacement des éléments, utilise un système qui ressemblerai à un arbre. Ainsi les liens mères / filles sont plus qu'utile, mais cela peut ne pas être pareille hors de Qt.

Sinon, pour réponse à votre première, nous créons une classe fille, lorsque nous voulons étendre les fonctionnalité de la classe mère (souvent par l'ajout de fonction), ou, lorsque nous voulons spécialisé la classe mère afin de faire une tache bien précise.

[Invité]

Bonjour et bonne année,
J'avais une petite question à propos de la classe QAudioInput, voir ici : si l'on traduit d'anglais à français brut cela donne ça : "construit un objet de type QAudioInput et l'attache à parent : qu'est-ce que cela signifie ? Est-ce qu'on doit obligatoirement créer une classe fille ?

Je dis cela car en observant la classe QMainWindow on s'aperçoit qu'elle a une structure comme ceci : Qt Creator crée automatiquement une classe fille appelée MainWindow avec apparemment le même paramètre que la classe mère en indiquant le paramètre pointeur parent.

J'aimerais juste connaître le principe : est-ce que ma piste est bonne ?

Merci d'avance. Cordialement, Gizmo.

[LittleWhite]

Alors, pour le QMainWindow, je ne sais pas ou est ce que vous lisez votre phrase ...

Mais, meme sans heritage (niveau C++ de la chose) on peut parler de parent et d'enfants, car comme je l'ai dit, Qt hierarchise les elements en arbre.

Il faut davoir que l'histoire de parent / fille de Qt comme vous semblez le decrire, n'a pas de rapport avec l'heritage mere -> fille du C++.
Imaginez la structure de donnee appelee "arbre"
http://upload.wikimedia.org/wikipedi...re_ordonne.svg
Et bah on voit bien que 1 n'a pas de parent (appele donc racine) et que les autres ont des parents. Qt se base de la meme facon.
Apres, ce type d'arbre est faisable en tout langage.

[gbdivers]

Bonjour gizmo27

Réponse très large pour la compréhension...

Il me semble que tu confonds 2 concepts : l'héritage et le système parent/enfant

- L'héritage (en général public) permet de créer une classe à partir d'une autre :

Code :

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

1
2
class A  { ... }
class B : public A { ... }

Dans ce cas, la classe B (on dit dérivée ou héritée, parler de classe "enfant" pour l'héritage est un abus de langage) est une classe A : tous les éléments public de A peuvent être utilisés avec B, tous éléments protected de A peuvent être utilisés dans B. D'un point de vue extérieur, B peut être manipulé comme si c'était une classe A. Pour résumé, B est une A (on parle de relation EST-UN pour l'héritage) dont une partie du comportement a été modifié.

- La relation enfant/parent est un système spécifique à Qt pour facilité la gestion de la mémoire et éviter les fuites mémoire (en autre, j'y reviendrai). Il n'y a pas de relation entre les parents et enfants (excepté l'héritage à QObject mais c'est plus un détail d'implémentation).
Donc, lorsque l'on a :

Code :

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

1
2
A a;
B b(&a);

Il n'y pas d'équivalence entre A et B : A et B sont des classes distinctes et une fonction manipulant A ne pourra pas utiliser (en général) B. B contient A

PS : la relation enfant/parent est utilisée dans certain cas pour autre chose que la gestion de la mémoire. Par exemple, les update d'un widget à ses enfants ou la transmission des signaux/slots


Pour répondre à tes questions :

Je dis cela car en observant la classe QMainWindow on s'aperçoit qu'elle a une structure comme ceci : Qt Creator crée automatiquement une classe fille appelée MainWindow avec apparemment le même paramètre que la classe mère en indiquant le paramètre pointeur parent.

MainWindow est une QMainWindow : c'est une fenêtre avec menus, barre de titre, barre de status, etc. Mais MainWindow fait "quelque chose" en plus que QMainWindow : elle va afficher des widgets ; ou un menu spécifique ; ou se dimensionner toute seule ; etc. On est bien dans une relation d'héritage.

On peut également fournir un objet parent à cette classe QMainWindow (et donc aussi à MainWinow puisque MainWindow est une QMainWindow) ce qui permet de détruire automatiquement MainWindow si l'objet parent est détruit.
Normalement, si on crée MainWindow dans la tas avec un new, il faudrait appeler un delete à la fin pour éviter les fuites mémoires. Avec le système enfant/parent, un objet parent appelle lui même delete sur ses enfants, ce qui évite de le faire soit même. Il y a donc plusieurs manière d'écrire le code, en fonction de si on utilise ou non le système enfant/parent :

Code :

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

1
2
3
MainWindow* w = new MainWindow();
...
delete w; // à la fin du programme

Code :

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

1
2
3
MainWindow* w = new MainWindow(parent);
...
// pas besoin de delete w;

J'avais une petite question à propos de la classe QAudioInput, voir ici : si l'on traduit d'anglais à français brut cela donne ça : "construit un objet de type QAudioInput et l'attache à parent : qu'est-ce que cela signifie ? Est-ce qu'on doit obligatoirement créer une classe fille ?

QAudioInput est une classe permettant de créer une interface vers une entrée audio. Cela permet de fournir une interface unique pour tout ceux qui veulent utiliser une entrée audio, sans avoir à se préoccuper du type réel d'entrée utilisé. Sans cela, si on avait plusieurs types d'entrées :

Code :

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

1
2
3
4
class MicroInput;
class PriseJackInput;
class UneAutreAudioInput;
etc.

une classe qui voudrait utiliser les entrées devrait fournir une fonction pour chaque entrée :

Code :

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

1
2
3
4
5
6
7
class QuiUtiliseInput
{
   void use_MicroInput(MicroInput* input);
   void use_MicroInput(MicroInput* input);
   void use_MicroInput(MicroInput* input);
   etc.
};

Cette solution est très lourde (beaucoup de code redondant) et peu évolutive (il faut modifier la classe pour prendre en charge un nouveau input).

La solution de l'héritage permet d'éviter cela :

Code :

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

1
2
3
4
5
6
7
8
9
class MicroInput : public QAudioInput {}
class PriseJackInput : public QAudioInput {}
class UneAutreAudioInput : public QAudioInput {}
etc.
 
class QuiUtiliseInput
{
   void useAudioInput(QAudioInput* input); // fonctionne pour touts les QAudioInput
};

Pour prendre en charge une nouvelle entrée, il suffit simplement de créer une classe héritant de QAudioInput et c'est tout.


Le paramètre parent est utilisé ici que pour la mémoire. Tu peux le fournir (et tu ne préoccupes pas de détruire l'objet crée) ou non (et il faut alors détruire l'objet manuellement) :

Code :

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

1
2
3
QAudioInput input = QAudioInput();
...
delete input;

ou

Code :

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

1
2
3
QAudioInput input = QAudioInput(parent);
...
// delete input; pas nécessaire

Donc au final, pour répondre à la question de savoir s'il faut créer une classe dérivée de QAudioInput : à priori non (mais précise ce que tu veux implémenter)

Bon courage

[Invité]

Merci pour l'explication c'est vrai qu'en plus on me l'a dit pour l'héritage mais c'est vrai que la confusion était presque inévitable pour moi
Merci de m'avoir expliqué cela : j'ai compris que l'héritage permettait entre autre l'ajout de fonctions nouvelles en plus des fonctions de la classe parente :ça c'est rentré mdr
Je vais essayer de me dépatouiller avec ça. Je relirai ça aussi plus tard : de toute façon je préfère intégrer les choses petit à petit c'est ma manière à moi : de toute façon je le fais pour moi alors vous savez j'ai le temps...

Juste une petite remarque, bien que ça n'est pas très grave : un peu plus haut quand vous dites B contient A : ça n'est pas plutôt B est contenu dans A ? Car un objet de B aura les fonctions de A et B alors qu'un objet dans A n'aura que les fonctions de A et pas celles de B non ?

A bientôt.

[gbdivers]

Juste une petite remarque, bien que ça n'est pas très grave : un peu plus haut quand vous dites B contient A : ça n'est pas plutôt B est contenu dans A ? Car un objet de B aura les fonctions de A et B alors qu'un objet dans A n'aura que les fonctions de A et pas celles de B non ?

Ce ne fonctionne pas selon la théorie des ensemble

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
class A {};
class B 
{
   B(A* a) : m_a(a) { }
private:
   A* m_a;
};
 
A::functionQuelconque()
{
   // pas d'objet B
}
 
B::functionQuelconque()
{
   // 1 objet A est accessible via m_a
}

Donc B contient A (c'est une composition ou une association, cf UML)

Précision : dans le cas de l'héritage, la classe B est une une classe A (ie la définition de la classe B contient la définition de la classe A). Dans le cas de la composition/association, un objet B contient un objet A.
Il faut bien comprendre cette différence entre la définition d'une classe (qui n'a pas d’existence en mémoire durant l’exécution) et l'instanciation d'une classe (= un objet réel en mémoire)

[Invité]

Alors ça n'est pas le patatoïde B qui est à l'intérieur du patatoïde A plus grand lui ? C'est dingue j'aurais pourtant juré...

Merci et bon week-end.