Pourquoi les méthodes qui prennent une quantité illimitée de paramètres définissent-elles souvent des surcharges avec moins de paramètres?

Par exemple, la System.IO.Path.Combineméthode dans .NET a les surcharges suivantes:

Combine(params String[])
Combine(String, String)
Combine(String, String, String)
Combine(String, String, String, String)

Quel est le point des trois derniers?

Le premier couvrirait tous, comme si vous regardiez de près, il utilisait le paramsmot - clé. L'argument de la compatibilité ascendante ne couvrirait que la Combine(String, String)variante, car c'était la seule version jusqu'à ce que .NET 4.

object-oriented parameters method-overloading

— Alex
source

Réponses:

La raison principale est la performance. Le sucre syntaxique "arguments illimités" est en réalité un tableau de chaînes. Si vous ne passez qu'une chaîne, pourquoi créer un tableau avec une seule chaîne? Surtout si environ 90% des invocations de cette méthode seront avec 3 arguments ou moins, l’objet tableau plus lourd n’est pas nécessaire. Il est un peu plus léger en mémoire et prend un peu moins de temps de traitement car vous n'avez pas besoin de boucle pour définir la méthode. Si vous avez trois chaînes, il vous suffit de coder pour trois chaînes.

— Greg Burghardt
source

Une autre chose à noter est que passer Combineavec zéro ou un segment de chemin n’a même aucun sens, mais la paramsversion vous permet de le faire.

— Matthieu

La raison du nombre de surcharges acceptant différents nombres d'arguments n'est pas pour la lisibilité. C'est pour les performances en raison de la surcharge occasionnée par la génération d'un tableau de chaînes, puis leur traitement. La raison de l'acceptation params string[]est la lisibilité.

— Greg Burghardt

La performance en est en effet la raison, et je pense que c’est précisément pour le moment où une fonction doit être appelée à partir de boucles internes . Comme le note l'annotation de Brad Abrams à la p. 27 du Langage de programmation C #, troisième édition : "[L] e modèle C # crée effectivement une allocation d'objet supplémentaire (le tableau contenant) à chaque appel. C'est rarement un problème, mais en interne. -Scénarios de type boucle, où cela pourrait devenir inefficace, nous suggérons de fournir des surcharges pour les cas classiques et d’utiliser la paramssurcharge uniquement pour les cas extrêmes . Un exemple est la StringBuilder.AppendFormat()famille des surcharges. "

— Eliah Kagan

@LowFlyingPelican Mono et le .NET Framework ne sont pas identiques. Si vous regardez la version .NET Framework , c'est en fait une solution très différente.

— Alex

@ LowFlyingPelican: La raison d'être du framework .NET est la performance. La raison pour laquelle Mono a implémenté cette méthode était la compatibilité de l'API avec .NET. La raison pour laquelle Mono a mis en œuvre cette méthode de cette manière était la simplicité de mise en œuvre (du fait qu’ils disposent de beaucoup moins de ressources que Microsoft).

— jhominal

Sucre syntaxique.

Lors de la manipulation de chemins de fichiers, il est extrêmement courant d'avoir un petit nombre de valeurs fixes. Dans ces cas, il est plus pratique de les utiliser directement plutôt que de les empaqueter dans un tableau.

— Gort le robot
source

Avec les paramètres, vous le dites déjà. msdn.microsoft.com/en-us/library/w5zay9db.aspx Pas besoin d'un tableau.

— Thomas Junk

En C #, vous avez un point, Thomas. Cependant, .NET prend également en charge d'autres langages sans params.

— Karl Bielefeldt

@ThomasJunk Ce lien est mort pour moi, malheureusement, mais je suis sûr que vous avez raison car mon C # est médiocre. Je viens de voir de nombreuses bibliothèques avec de nombreuses langues qui le font juste pour permettre un code plus propre.

— Gort le robot