Bonsoir,
Je me souviens que lors de mon examen d'embauche, j'avais eu une question
sur un bout de code, avec le temps et après avoir regardé le livre de
Bjarne, je n'ai pas encore vu le bout de code en question dans une
littérature.
class Person {
public:
Person (void);
~Person (void);
};
class Employe : public virtual Person {
public:
Employe (void);
~Employe (void);
};
Que signifie le "public virtual Person" ?
1) Je rend le classe Person virtuelle lors de l'héritage ?
2) Je ne sais vraiment pas.
Bonsoir,
Je me souviens que lors de mon examen d'embauche, j'avais eu une question
sur un bout de code, avec le temps et après avoir regardé le livre de
Bjarne, je n'ai pas encore vu le bout de code en question dans une
littérature.
class Person {
public:
Person (void);
~Person (void);
};
class Employe : public virtual Person {
public:
Employe (void);
~Employe (void);
};
Que signifie le "public virtual Person" ?
1) Je rend le classe Person virtuelle lors de l'héritage ?
2) Je ne sais vraiment pas.
Bonsoir,
Je me souviens que lors de mon examen d'embauche, j'avais eu une question
sur un bout de code, avec le temps et après avoir regardé le livre de
Bjarne, je n'ai pas encore vu le bout de code en question dans une
littérature.
class Person {
public:
Person (void);
~Person (void);
};
class Employe : public virtual Person {
public:
Employe (void);
~Employe (void);
};
Que signifie le "public virtual Person" ?
1) Je rend le classe Person virtuelle lors de l'héritage ?
2) Je ne sais vraiment pas.
par contre, je n'ai pas d'exemple 'réaliste' en tête qui justifierait le
besoin concret de ce mécanisme plutot que de s'organiser autrement.
par contre, je n'ai pas d'exemple 'réaliste' en tête qui justifierait le
besoin concret de ce mécanisme plutot que de s'organiser autrement.
par contre, je n'ai pas d'exemple 'réaliste' en tête qui justifierait le
besoin concret de ce mécanisme plutot que de s'organiser autrement.
Je comprends mieux, et je vois l'intérêt surtout dans le cas de l'héritage
multiple qui peut engendrer de sérieux problèmes.
Je comprends mieux, et je vois l'intérêt surtout dans le cas de l'héritage
multiple qui peut engendrer de sérieux problèmes.
Je comprends mieux, et je vois l'intérêt surtout dans le cas de l'héritage
multiple qui peut engendrer de sérieux problèmes.
On Thu, 05 May 2005 03:51:04 +0200, Samuel Krempp
:
par contre, je n'ai pas d'exemple 'réaliste' en tête qui
justifierait le besoin concret de ce mécanisme plutot que de
s'organiser autrement.
Le besoin est assez fréquent dans les hiérarchies de classes
gérant une interface graphique (GUI).
Classe de base : "Fenetre"
Une classe dérivée est "Bouton" : une fenêtre particulière qui
réagit au clic de souris en lançant une commande.
On crée souvent des types particuliers de fenêtres, par
exemple, une fenêtre avec un fond de couleur, ou une fenêtre
dont le texte est traduit automatiquement, etc. Il s'agit là
encore de classes dérivées de "Fenetre".
Si maintenant on veut créer une classe "bouton avec fond de
couleur", on se retrouve à dériver de Bouton _et_ de
"Fenetre_avec_fond_de_couleur".
Et comme un objet de cette classe correspond à une seule
fenêtre à l'écran, la plupart des membres doivent être uniques
-- d'où l'héritage virtuel.
On Thu, 05 May 2005 03:51:04 +0200, Samuel Krempp
<krempp@crans.truc.en.trop.ens-cachan.fr>:
par contre, je n'ai pas d'exemple 'réaliste' en tête qui
justifierait le besoin concret de ce mécanisme plutot que de
s'organiser autrement.
Le besoin est assez fréquent dans les hiérarchies de classes
gérant une interface graphique (GUI).
Classe de base : "Fenetre"
Une classe dérivée est "Bouton" : une fenêtre particulière qui
réagit au clic de souris en lançant une commande.
On crée souvent des types particuliers de fenêtres, par
exemple, une fenêtre avec un fond de couleur, ou une fenêtre
dont le texte est traduit automatiquement, etc. Il s'agit là
encore de classes dérivées de "Fenetre".
Si maintenant on veut créer une classe "bouton avec fond de
couleur", on se retrouve à dériver de Bouton _et_ de
"Fenetre_avec_fond_de_couleur".
Et comme un objet de cette classe correspond à une seule
fenêtre à l'écran, la plupart des membres doivent être uniques
-- d'où l'héritage virtuel.
On Thu, 05 May 2005 03:51:04 +0200, Samuel Krempp
:
par contre, je n'ai pas d'exemple 'réaliste' en tête qui
justifierait le besoin concret de ce mécanisme plutot que de
s'organiser autrement.
Le besoin est assez fréquent dans les hiérarchies de classes
gérant une interface graphique (GUI).
Classe de base : "Fenetre"
Une classe dérivée est "Bouton" : une fenêtre particulière qui
réagit au clic de souris en lançant une commande.
On crée souvent des types particuliers de fenêtres, par
exemple, une fenêtre avec un fond de couleur, ou une fenêtre
dont le texte est traduit automatiquement, etc. Il s'agit là
encore de classes dérivées de "Fenetre".
Si maintenant on veut créer une classe "bouton avec fond de
couleur", on se retrouve à dériver de Bouton _et_ de
"Fenetre_avec_fond_de_couleur".
Et comme un objet de cette classe correspond à une seule
fenêtre à l'écran, la plupart des membres doivent être uniques
-- d'où l'héritage virtuel.
On Thu, 05 May 2005 04:19:26 +0200, Stephane Wirtel
:
Je comprends mieux, et je vois l'intérêt surtout dans le cas
de l'héritage multiple qui peut engendrer de sérieux
problèmes.
C'est pas pour rien que Sun a éludé le problème...
On Thu, 05 May 2005 04:19:26 +0200, Stephane Wirtel
<stephane.wirtel@belgacom.net>:
Je comprends mieux, et je vois l'intérêt surtout dans le cas
de l'héritage multiple qui peut engendrer de sérieux
problèmes.
C'est pas pour rien que Sun a éludé le problème...
On Thu, 05 May 2005 04:19:26 +0200, Stephane Wirtel
:
Je comprends mieux, et je vois l'intérêt surtout dans le cas
de l'héritage multiple qui peut engendrer de sérieux
problèmes.
C'est pas pour rien que Sun a éludé le problème...
Normalement, l'héritage ne doit pas aller très loin.
Si la classe que tu dérives n'est pas, elle, conçue comme une
classe de base, ce n'est pas la peine que l'héritage soit
virtuel.
Il y a aussi des cas de mixin. Trouver un bon exemple n'est pas
facile, mais je sais que je m'en suis servi deux ou trois fois,
où il semblait la solution qui convenait le mieux.
Sauf, évidemment, on ne peut pas
créer un AbstractMouseEventHandler et
AbstractKeyboardEventHandler, avec des comportements par défaut
pour les évenemments qui nous intéressent pas, et puis en hérite
des deux.
Normalement, l'héritage ne doit pas aller très loin.
Si la classe que tu dérives n'est pas, elle, conçue comme une
classe de base, ce n'est pas la peine que l'héritage soit
virtuel.
Il y a aussi des cas de mixin. Trouver un bon exemple n'est pas
facile, mais je sais que je m'en suis servi deux ou trois fois,
où il semblait la solution qui convenait le mieux.
Sauf, évidemment, on ne peut pas
créer un AbstractMouseEventHandler et
AbstractKeyboardEventHandler, avec des comportements par défaut
pour les évenemments qui nous intéressent pas, et puis en hérite
des deux.
Normalement, l'héritage ne doit pas aller très loin.
Si la classe que tu dérives n'est pas, elle, conçue comme une
classe de base, ce n'est pas la peine que l'héritage soit
virtuel.
Il y a aussi des cas de mixin. Trouver un bon exemple n'est pas
facile, mais je sais que je m'en suis servi deux ou trois fois,
où il semblait la solution qui convenait le mieux.
Sauf, évidemment, on ne peut pas
créer un AbstractMouseEventHandler et
AbstractKeyboardEventHandler, avec des comportements par défaut
pour les évenemments qui nous intéressent pas, et puis en hérite
des deux.
(05 May 2005 11:30,
<4279e78e$0$27953$) a
Normalement, l'héritage ne doit pas aller très loin. Si la
classe que tu dérives n'est pas, elle, conçue comme une classe
de base, ce n'est pas la peine que l'héritage soit virtuel.
comment ça ?
Il y a aussi des cas de mixin. Trouver un bon exemple n'est
pas facile, mais je sais que je m'en suis servi deux ou trois
fois, où il semblait la solution qui convenait le mieux.
que veux-tu dire par 'cas de mixin' ?
Y-a-t-il des bons exemples de cas où l'on veut obtenir
plusieurs fois une même base par des chemins différents (bref
où l'on veut précisément pas d'héritage virtuel) ?
Sauf, évidemment, on ne peut pas créer un
AbstractMouseEventHandler et AbstractKeyboardEventHandler,
avec des comportements par défaut pour les évenemments qui
nous intéressent pas, et puis en hérite des deux.
ces classes seraient utiles si l'on est quasi-toujours
interessé par les mêmes évenements (et qu'on veut éviter de
taper les 3 ou 4 autres méthodes vides), mais à priori on peut
facilement s'en passer. Je suis bien d'accord que la
contrainte de Java sur les interfaces est une limitation, mais
dans ce cas là ça me semble pas trop gènant.
kanze@none (05 May 2005 11:30,
<4279e78e$0$27953$626a14ce@news.free.fr>) a
Normalement, l'héritage ne doit pas aller très loin. Si la
classe que tu dérives n'est pas, elle, conçue comme une classe
de base, ce n'est pas la peine que l'héritage soit virtuel.
comment ça ?
Il y a aussi des cas de mixin. Trouver un bon exemple n'est
pas facile, mais je sais que je m'en suis servi deux ou trois
fois, où il semblait la solution qui convenait le mieux.
que veux-tu dire par 'cas de mixin' ?
Y-a-t-il des bons exemples de cas où l'on veut obtenir
plusieurs fois une même base par des chemins différents (bref
où l'on veut précisément pas d'héritage virtuel) ?
Sauf, évidemment, on ne peut pas créer un
AbstractMouseEventHandler et AbstractKeyboardEventHandler,
avec des comportements par défaut pour les évenemments qui
nous intéressent pas, et puis en hérite des deux.
ces classes seraient utiles si l'on est quasi-toujours
interessé par les mêmes évenements (et qu'on veut éviter de
taper les 3 ou 4 autres méthodes vides), mais à priori on peut
facilement s'en passer. Je suis bien d'accord que la
contrainte de Java sur les interfaces est une limitation, mais
dans ce cas là ça me semble pas trop gènant.
(05 May 2005 11:30,
<4279e78e$0$27953$) a
Normalement, l'héritage ne doit pas aller très loin. Si la
classe que tu dérives n'est pas, elle, conçue comme une classe
de base, ce n'est pas la peine que l'héritage soit virtuel.
comment ça ?
Il y a aussi des cas de mixin. Trouver un bon exemple n'est
pas facile, mais je sais que je m'en suis servi deux ou trois
fois, où il semblait la solution qui convenait le mieux.
que veux-tu dire par 'cas de mixin' ?
Y-a-t-il des bons exemples de cas où l'on veut obtenir
plusieurs fois une même base par des chemins différents (bref
où l'on veut précisément pas d'héritage virtuel) ?
Sauf, évidemment, on ne peut pas créer un
AbstractMouseEventHandler et AbstractKeyboardEventHandler,
avec des comportements par défaut pour les évenemments qui
nous intéressent pas, et puis en hérite des deux.
ces classes seraient utiles si l'on est quasi-toujours
interessé par les mêmes évenements (et qu'on veut éviter de
taper les 3 ou 4 autres méthodes vides), mais à priori on peut
facilement s'en passer. Je suis bien d'accord que la
contrainte de Java sur les interfaces est une limitation, mais
dans ce cas là ça me semble pas trop gènant.
C'est pas pour rien que Sun a éludé le problème...
Par « Sun », je suppose que tu veux dire « Java ».
Alors, pas
vraiment. Le problème est toujours là
C'est pas pour rien que Sun a éludé le problème...
Par « Sun », je suppose que tu veux dire « Java ».
Alors, pas
vraiment. Le problème est toujours là
C'est pas pour rien que Sun a éludé le problème...
Par « Sun », je suppose que tu veux dire « Java ».
Alors, pas
vraiment. Le problème est toujours là
En général, la couleur du fond est une attribute de la classe.
On ne va pas en faire une classe exprès pour ça.
En général, la couleur du fond est une attribute de la classe.
On ne va pas en faire une classe exprès pour ça.
En général, la couleur du fond est une attribute de la classe.
On ne va pas en faire une classe exprès pour ça.
