Discussion :

[Kaamui]

Bonjour,

J'ai une classe parente avec 2 méthodes setRect, prototype différent. Dansd une classe fille je surcharge l'une. Avec une instance de la classe fille j'appelle la méthode non surchargée de la parente, et j'ai une erreur 'method 'A' does not take 4 arguments'.

Sauriez-vous pourquoi ?

(je n'ai volontairement pas mis de code car je ne penses pas que cela soit nécessaire, mais si vous voulez un exemple concret dites le moi et je posterais cela)

[cob59]

Peut-être un problème de masquage de fonction ?

[Kaamui]

Effectivement ça a l'air d'être ça... ça veut dire qu'en surchargeant une méthode sur n définies (de même nom) dans la classe mère, je masque les n méthodes ? Pas top ça..

Merci Cob59 et merci la FAQ dvp

Je penses qu'on peut considérer le problème résolu.

[Kaamui]

J'aimerais vraiment savoir si "ça veut dire qu'en surchargeant une méthode sur n définies (de même nom) dans la classe mère, je masque les n méthodes ?" est le comportement défini par la norme ou si c'est un "undefined behavior laissé à la guise des créateurs de compilo... vous avez une idée ?

[Jean-Marc.Bourguet]

J'aimerais vraiment savoir si "ça veut dire qu'en surchargeant une méthode sur n définies (de même nom) dans la classe mère, je masque les n méthodes ?" est le comportement défini par la norme ou si c'est un "undefined behavior laissé à la guise des créateurs de compilo... vous avez une idée ?

Defini. A noter que c'est une question d'imbrication de portee et en rien propre aux classes, le meme comportement existe avec des namespaces et des blocs imbriques (mais pour les blocs, c'est rare car ceux qui s'amusent a y declarer des fonctions sont rares aussi).

[koala01]

Salut,

C'est un comportement parfaitement décrit dans la norme :

Pour pouvoir surcharger une fonction, il faut:

• qu'elle soit déclarée virtuelle
• qu'elle présente exactement la même signature dans la classe dérivée que dans la classe de base.

Si la fonction n'est pas déclarée virtuelle dans la classe de base, la norme précise qu'il y a "masquage" de la fonction de la classe de base.

Si la signature n'est pas identique à celle qui se trouve dans la classe de base mais que la fonction de la classe de base est déclarée virtuelle, tu "rajoutes" simplement une fonction supplémentaire (de même nom mais avec des arguments différents). Au temps pour moi, j'ai dit une bêtise ici...

Maintenant, on peut réellement se poser plusieurs questions :

1. Pourquoi tiens tu à fournir un mutateur sur le rectangle sous-jacent à ta classe, au mépris de la loi de Déméter
2. Pourquoi voudrais tu fournir à l'utilisateur la possibilité de modifier le rectangle sous-jacent sous une forme différente dans la classe dérivée

La première question devrait t'inciter à considérer le niveau d'encapsulation de ta classe car, le simple fait de fournir un mutateur implique que les modifications du rectangle sous-jacent peuvent intervenir n'importe où et que tu laisses la responsabilité à l'utilisateur de ta classe de vérifier que le rectangle qu'il veut défini soit cohérent par rapport à ta classe.

Cela n'ira pas sans poser un certain nombre de problèmes car toute décision susceptible de modifier la manière dont le rectangle sous-jacent est représenté dans ta classe impliquera de nombreux changements, sur lesquels tu n'as strictement aucun contrôle à l'heure actuelle.

La deuxième question devrait t'inciter à réfléchir à l'intérêt réel qu'il y a à fournir, dans la classe dérivée uniquement, une possibilité supplémentaire d'appliquer le changement.

Pourquoi rendre l'interface publique de ta classe dérivée plus inutilement plus complexe, alors que tu disposes déjà d'une solution pour appliquer le changement n'est-ce pas d'une certaine manière contrevenir à l'ISP (Interface Segregation Principle) qui te conseille de garder des interfaces les plus simples possibles Dans le pire des cas, pourquoi ne pas donner cette possibilité supplémentaire directement dans la classe de base Après tout, c'est bien elle qui prend la responsabilité de la gestion du rectangle sou-jacent... Pourquoi voudrais tu "l'amputer" d'une partie de cette responsabilité

[Kaamui]

J'ai une classe Qt qui contient deux méthodes setRect :

Code :

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

1
2
3
 
void	setRect ( const QRectF & rect );
void	setRect ( qreal x, qreal y, qreal width, qreal height );

Ma classe dérivée doit effectuer une vérification avant d'appeler le sectRect parent...

Je comprends parfaitement qu'il y ait masquage de fonction sur la fonction que j'ai redéfini puisque c'est ce que je voulais, mais je m'attendais pas à ce que l'autre fonction (non surchargée) soit elle aussi masquée.

Certes dans mon cas précis ça m'a protégé (et tu viens de m'aider à me rendre compte qu'on a probablement pas respecté LSP puisque notre classe est censée représenter des ellipses ou des cercles (forme particulière d'ellipse)), mais dans d'autres cas ça pourrait être ennuyeux je trouve :/

Le problème est qu'en l'occurence, Qt ne fournit pas de classe pour les cercles, donc je suis bien obligé de me rabbattre sur les ellipses pour gérer cette demande => donc obligé de surcharger setRect => donc étonné de voir qu'une surcharge masque les n fonction de même nom de la classe mère

[Jean-Marc.Bourguet]

Ceci est du code valide:

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
19
20
21
22
23
24
25
26
27
28
29
struct s1 {
    int i;
    int f();
};
 
struct s2: s1 {
    double i;
    int f(double);
};
 
namespace n1 {
int i;
int f();
 
namespace n2 {
double i;
int f(double);
}
}
 
void f() {
    int i;
    int f();
 
    {
        double i;
        int f(double);
    }
}

et le meme que les double i masquent les int i (ce dont je doute que ca te surprennes a partir du moment ou tu sais que les classes sont considerees comme des portees imbriquees), les int f(double) masquent les int f().

[koala01]

Le problème est qu'en l'occurence, Qt ne fournit pas de classe pour les cercles, donc je suis bien obligé de me rabbattre sur les ellipses pour gérer cette demande => donc obligé de surcharger setRect => donc étonné de voir qu'une surcharge masque les n fonction de même nom de la classe mère

Si ce n'est que ta classe Circle (ou n'importe quoi d'autre) ne peut pas plus hériter de ta classe Elipse qu'une classe Square ne pourrait hériter d'une classe Rectangle

Tu te retrouves dans les deux cas avec des invariants beaucoup plus forts pour les classes Square et Circle, dans le sens où tu en arrives toujours à un invariant du genre de width == height, et que c'est en contradiction avec la règle qui veut que les invariants de la classe mère soient respectés dans la classe fille.

C'est, d'une certaine manière, le plus gros reproche que je pourrais faire à Qt : ne pas respecter la loi de Déméter en de nombreuses occasions, bien que je comprenne parfaitement la raison qui pousse à en arriver à ce point.

Comme tu ne peux pas surcharger les fonctions setRect (qui, autant que je le sache, ne sont pas virtuelles), tout ce que tu pourrais faire, c'est envisager de faire dériver une classe CheckedElipse de la classe Elipse et qui exposerait une fonction isCircle() qui vérifie que la hauteur du rectangle sous-jacent est bien égale à sa largeur (ou, selon le cas, qui vérifie que le diametre horizontal correspond bien au diamètre vertical).

autre solution consisterait créer une fonction libre qui vérifie que les dimensions concordent, proche de

Code :

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

1
2
3
bool isValidForCircle(QRect const & rect){
    return rect.width() == rect.height();
}

Mais ce serait de toutes manières toujours à l'utilisateur de faire la vérification, de préférence a priori pour éviter les modifications indues

[Kaamui]

(ce dont je doute que ca te surprennes a partir du moment ou tu sais que les classes sont considerees comme des portees imbriquees)

ça me surprends

Comme tu ne peux pas surcharger les fonctions setRect (qui, autant que je le sache, ne sont pas virtuelles)

Je ne peux que les masquer, mais je pensais pouvoir n'en masquer qu'une (je pensais que la totalité de la signature d'une fonction faisait office "d'identité", pas juste son nom...)

tout ce que tu pourrais faire, c'est envisager de faire dériver une classe CheckedElipse de la classe Elipse et qui exposerait une fonction isCircle() qui vérifie que la hauteur du rectangle sous-jacent est bien égale à sa largeur

[...]

autre solution consisterait créer une fonction libre qui vérifie que les dimensions concordent, proche de

Code :

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

1
2
3
bool isValidForCircle(QRect const & rect){
    return rect.width() == rect.height();
}

Mais ce serait de toutes manières toujours à l'utilisateur de faire la vérification, de préférence a priori pour éviter les modifications indues

ça ne ferait pas que décaler le pb ? Et pourquoi le mot "exposer" ?

[koala01]

ça ne ferait pas que décaler le pb ?

Tout dépend de ta manière d'utiliser les différents objets.

Si tu travailles en respectant "correctement" l'idiome Model View Controller, cela aura au moins l'avantage de limiter ce genre de vérification à un seul module tout en indiquant clairement à l'utilisateur qu'il est important que cette vérification soit faite

Et pourquoi le mot "exposer" ?

Pour faire la distinction entre les fonctions membres publiques et celles qui se trouvent dans des niveaux d'accessibilité plus restreints, tout simplement.

J'aurais pu écrire une phrase proche de "qui définirait la fonction machin dans l'accessibilité publique", mais c'est beaucoup plus long à écrire et je suis du genre fainéant

[oodini]

Pour pouvoir surcharger une fonction, il faut:

• qu'elle soit déclarée virtuelle
• qu'elle présente exactement la même signature dans la classe dérivée que dans la classe de base.

Tu confonds redéfinition et surcharge.

[Flob90]

@Kaamui: Ce n'est pas étonnant si tu considères que ce n'est qu'une question de portée comme l'a dit Jean-Marc. Quand tu appels une fonction, le compilateur détermine un ensemble de portée de départ où rechercher la fonction (juste le nom, l'accessibilité et la signature ça vient après). Si il ne trouve pas dans cet ensemble il remonte dans les portées parentes.

C'est ce qui se passe pour les fonctions membres, tu as un objet d'une certaines classe (type statique), il va rechercher ta fonction dans cette classe, si il trouve le nom il s'arrête, dans ton cas il trouve directement le setRect déclaré dans la classe fille donc il s'arrête.

Edit: Si tu tiens à réimporter les fonctions de la classe mère dans la portée de la classe fille, utilise un using Mere::foo; dans ta classe fille (partie publique).

[Jean-Marc.Bourguet]

et de meme que les double i masquent les int i (ce dont je doute que ca te surprennes a partir du moment ou tu sais que les classes sont considerees comme des portees imbriquees)

ça me surprends

C'est un peu (beaucoup même) le principe de l'imbrication de portée le fait que des définitions internes masquent les définitions externes.

Je ne peux que les masquer, mais je pensais pouvoir n'en masquer qu'une (je pensais que la totalité de la signature d'une fonction faisait office "d'identité", pas juste son nom...)

Le principe est qu'on fait une recherche et qu'on arrête celle-ci une fois le nom trouvé. Puis on cherche la meilleure fonction avec ce nom en appliquant une série de règles relativement complexes à cause des conversions implicites, arguments par défaut et de la possibilité de templates de fonction à instancier.

A noter qu'il n'y a pas d'arguments très fort pour dire que dans le cas des fonctions on ne pourrait pas collecter toutes les surcharges avant de choisir. De mémoire dans D&E (j'ai pas le bouquin ici) Stroustrup dit qu'outre le fait que c'est plus homogène (on traite tous les identificateurs de la même façon -- en passant au moment où on cherche les définitions, on n'a aucune idée si c'est une définition de fonction, de variable, de template, de type... qu'on va trouver) c'est pour éviter des problèmes que d'autres modifications introduites depuis éviteraient maintenant. Je suppose que quand on s'en est rendu compte, changer cet aspect de la collecte des fonctions à surcharger aurait causé trop de problèmes.

[Kaamui]

Merci pour ces superbes réponses (où vous allez chercher toutes ces connaissances si précises, parce que j'aimerais les avoir aussi )

Il faudrait rajouter un bouton "Résolu de manière exhaustive" Merci en tout cas je comprends mieux un tas de chose : encore un exemple du fait que je serais bien incapable de me passer de ce superbe forum !

@Koala01, malheureusement le projet est assez énorme déjà (reprise de maintenance) et même s'il a une base assez bien codée, les différentes mains qui sont passées dessus ensuite ont fini par rendre le code assez ingérable et les pattern implémentés n'ont pas du tout été respectés. C'est un logiciel open-source du nom d'Open-Sankoré si vous voulez en savoir plus