De l'article Anders Hejsberg interview, "la façon dont nous faisons la résolution de surcharge en C# est différente de tout autre langage" Quelqu'un peut-il fournir quelques exemples avec C# et Java?Résolution de surcharge C#?
Que Anders voulait en venir ici était que l'équipe de conception originale conçue explicitement l'algorithme de résolution de surcharge pour avoir certaines propriétés qui ont travaillé bien avec des scénarios de versioning, même si ces propriétés semblent en arrière ou prêtant à confusion si l'on considère les scénarios sans versioning . Probablement l'exemple le plus courant est la règle en C# qui, si une méthode sur une classe plus dérivée est un candidat applicable, est automatiquement meilleure que toute méthode sur une classe moins dérivée, même si moins La méthode -derived a une meilleure correspondance de signature. Cette règle n'est pas, à ma connaissance, trouvée dans d'autres langues qui ont une résolution de surcharge. Cela semble contre-intuitif; S'il y a une méthode qui correspond mieux à une signature, pourquoi ne pas la choisir? La raison en est que la méthode correspondant à la meilleure correspondance de signature a peut-être été ajoutée dans une version ultérieure et introduit ainsi une défaillance de "classe de base fragile".
Pour plus d'idées sur la façon dont diverses langues gérer les échecs de la classe de base fragile, voir
http://blogs.msdn.com/b/ericlippert/archive/tags/brittle+base+classes/
et pour plus de réflexions sur la résolution de surcharge, voir
http://blogs.msdn.com/b/ericlippert/archive/tags/overload+resolution/
vous obtenez paginé chaque fois que votre nom est mentionné dans une question pour s'assurer qu'il est répondu indépendamment de l'heure de la journée;)? – R0MANARMY
C++ cache automatiquement toutes les fonctions avec le même nom, si l'on est défini dans une classe plus dérivée. "using base :: functionname" declaration (qui "réapparaît" le nom), l'effet est similaire, ce n'est pas exactement la même chose, car en C++ ces noms cachés ne seront pas du tout pris en compte, même s'il n'y a pas de surcharge. La classe dérivée est applicable, mais elle sert la même chose - les nouvelles fonctions dans les classes de base ne seront pas appelées involontairement. –
La façon dont C# gère la surcharge d'une perspective interne est ce qui est différent.
La citation complète de Anders:
Je me suis toujours décrit comme un homme pragmatique . C'est drôle, parce que versioning a fini par être l'un des piliers de notre conception de la langue. Il apparaît dans la façon dont vous remplacer les méthodes virtuelles en C#. En outre, la façon dont nous faisons résolution de surcharge en C# est différent de toute autre langue que je connais, pour raisons de la version. Chaque fois que nous regardé à la conception d'une caractéristique particulière , nous aurions toujours vérifier avec le versionnage. Nous demandons, "Comment est-ce que le changement de version change cela? Comment fonctionne cette fonction depuis une perspective de version ?" Il se trouve que la plupart des conception de la langue avant a donné très peu pensé à cela.
Eh bien .... cela explique son [autre question] (http://stackoverflow.com/questions/2926470/c-language-design-pillars) – R0MANARMY
Je commencerais à [Eric Le blog de Lippert] (http://blogs.msdn.com/b/ericlippert/archive/tags/overload+resolution/). Il y a 8 postes marqués avec ** résolution de surcharge **. – R0MANARMY
Pourquoi avez-vous besoin d'un exemple? En Java, vous pouvez facilement remplacer une fonction dans une sous-classe, en C# vous marquez la fonction comme virtuelle, puis vous pouvez la surcharger. –
@ R0MANARMY: C'est la bonne réponse à cette question. Si vous postez comme une réponse, je vais l'augmenter. –