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

[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.