Greg's Devblog Par un développeur, pour les développeurs

Surcharge en C#

Après avoir pas mal joué avec la surcharge en Java, je suis tombé par hasard ce matin sur un billet parlant de la surcharge en C#. J'ai hésité à lire, ça m'a paru trop simple, et pourtant ce que j'y ai lu m'a plutôt surpris.

Voici donc l'extrait de code en question :

using System;

class Parent
{
    public void Foo(String str)
    {
        Console.WriteLine("Parent.Foo");
    }
}
class Child : Parent
{
    public void Foo(Object str)
    {
        Console.WriteLine("Child.Foo");
    }
}
class Example
{
    static void Main()
    {
        Child child = new Child();
        child.Foo("test");
    }
}

Alors... Quelle est la méthode appelée ? Ca parait évident que la réponse est Parent.Foo, non ? En tout cas c'est ce que j'ai répondu, et j'ai perdu !

La réponse se trouve dans la doc (RTFM !) :

the set of candidates for a method invocation does not include methods marked override(Section 7.3), and methods in a base class are not candidates if any method in a derived class is applicable

Ce qui veut dire que dans notre exemple précédent, comme la classe fille Child expose la méthode Foo(Object) qui est applicable pour Foo("test"), alors on ne regarde pas du tout les méthodes disponibles dans la classe mère... On passe donc à côté d'une méthode plus précise et a priori plus intuitive.

Pourquoi ce comportement a-t-il été retenu ? D'après le site d'où j'ai trouvé cet exemple, le but est en fait d'assurer un comportement homogène dans le temps pour les sous-classes. Reprenons l'exemple précédent, mais en ignorant la méthode Foo(String) de Parent. On a donc une belle petite classe Child, dans laquelle on a implémenté une méthode qui est sensée pouvoir matcher avec n'importe quel objet...

Et là, un jour, sans rien nous demander, les personnes à l'origine de la Parent décident de la mettre à jour et de rajouter une méthode Foo(String). Et voilà, avec le comportement habitudel on se retrouve tout d'un coup avec des objets qui ne vont plus passer par la méthode Child.Foo, mais vont être capturés par la méthode Parent.Foo... Avec le choix fait dans .NET, au moins on est sûr de ne pas être dérangé.

Je reste assez partagé sur si c'est un choix pertinent ou pas. J'ai comme l'impression que ça risque de poser plus de problèmes que ça ne va en régler. Mais de toute façon, si j'ai bien appris une chose à propos de la surcharge, c'est bien qu'à partir du moment où on a une ambiguité, on va avoir des merdes :p

Source : Togaroga