Discussion :

[talrashha]

Hello,

C'est plus par curiosité qu'autre chose mais je suis tombé sur un comportement que je ne comprend pas vraiment entre surcharge et héritage.
Voici un premier bout de code sur la surcharge:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public class MaClasse
{
    public void Test(int i)
    {
 
    }
    public void Test(object i)
    {
         Test((int)i);
    }
}

Si je fais ce code de test:

Code :

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

1
2
3
MaClasse elt = new MaClasse();
object o = 2;
elt.Test(o);

Le code va passer dans la fonction "Test(object)", caster mon paramètre en int, et appeler la fonction "Test(int)"... parce que mon type "int" est plus haut dans la hiérarchie d'héritage que object. Donc la, je suis content. Maintenant un autre code:

Code :

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

1
2
3
4
5
6
7
public class NewList<T> : List<T>
{
      public void Add(object o)
      {
          Add((T)o);
      }
}

Ici, on est plus ou moins dans la même situation. La classe List<T> a une methode "Add(T)", et donc j'avais espéré que mon code de Add(object) allait utiliser le Add(T) en second appel.... et bien non. Il va juste s'appeler en boucle et partir en StackOverflow.

Pour être tout a fait franc, il n'y a même pas besoin de lancer le code... Faire "F12" sur la ligne Add((T)o); vous emmènera a la ligne public void Add(object o).

Quelqu'un pourrait-il m'expliquer la différence?

[theMonz31]

c logique:

tu appelles Add() dans la méthode Add() donc ça part en boucle.

C'est quoi le rapport entre l'exemple 1 et le second ? ya autant de rapport qu'entre le chocolat et la choucroute !

[talrashha]

Ben le rapport c'est que dans ma tete je vois pas de difference entre

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
 
        public abstract class Foo
        {
            public void Test(int i)
            {
 
            }
        }
        public class Bar : Foo
        {
            public void Test(object i)
            {
                Test((int)i);
            }
        }

et

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
        public class Bar 
        {
            public void Test(int i)
            {
 
            }
            public void Test(object i)
            {
                Test((int)i);
            }
        }

Et que clairement ces codes ont un comportement complément différent, et donc apparemment une fonction hérité est moins visible qu'une fonction directement code dans une classe...

[François DORIN]

Bonjour,

La différence est tout à fait normal. C'est le jeu de l'héritage. Les deux exemples ne sont pas équivalents.

Dans le premier cas, la classe définie 2 surcharges d'une même méthode. A la compilation, le compilateur peut choisir la surcharge appropriée (et dans les cas où il ne le peut pas, il génère une erreur "appel ambigu").

Dans le second cas, la classe définie dispose :

• D'une méthode Add(object) ;
• D'une méthode héritée Add(T).

Ainsi, la classe NewList ne dispose que d'une seule surcharge de la méthode Add, et hérite d'une autre méthode Add.

Lorsque le compilateur se retrouve fasse à un objet de type NewList, et qu'il doit appeler la méthode Add, il regarde la surcharge définie au niveau de la classe et choisi celle qui convient. Uniquement dans le cas où cela ne serait pas le cas, le compilateur recherche dans la hiérarchie si une méthode peut convenir.

Dans ton cas, pour lever l'ambiguïté (qui n'en est pas une pour le compilateur), tu dois utiliser la syntaxe base.Add lorsque tu appelles la méthode Add au sein de ta méthode Add. Ainsi, tu précises que dans la méthode Add de ta classe NewList, tu appelles la méthode Add définie par héritage.

[talrashha]

Ahh ca c'est une explication qui me plait bien. Et finalement ca parait être une bonne décision de la part du compilateur de pas visiter systématiquement toutes les dépendances, parce que ca pourrait rapidement vite causer des ambiguïtés sur des fonctions ultra-standard telle que Equals.

Par contre, ca met en évidence un "bug" dans Visual Studio, qui ne devrait pas me proposer cette syntaxe:

Il devrait au moins y avoir un warning ou quelque chose.

Merci

[François DORIN]

Il devrait au moins y avoir un warning ou quelque chose.

C'est pas vraiment un bug. On est dans le cas d'une surcharge très particulière où la seule différence réside dans le type du paramètre, qui dans un cas est spécialisé et dans l'autre générique, et pour lequel la méthode générique peut être appelée à tous les coups.

Maintenant, dans la plupart des cas, la surcharge met en oeuvre un nombre de paramètres variables et/ou des types d'objet totalement différents, non reliés entre eux par une relation d'héritage. Et là, on est bien content que Visual Studio nous propose toutes les possibilités