Faut-il déclarer les méthodes en utilisant des surcharges ou des paramètres optionnels en C# 4.0 ?

Question

Je regardais Discussion d'Anders sur C# 4.0 et avant-première de C# 5.0 Je me suis demandé, lorsque les paramètres optionnels seront disponibles en C#, quelle sera la manière recommandée de déclarer les méthodes qui n'ont pas besoin que tous les paramètres soient spécifiés ?

Par exemple, quelque chose comme le FileStream possède une quinzaine de constructeurs différents qui peuvent être divisés en "familles" logiques, par exemple les constructeurs ci-dessous à partir d'une chaîne de caractères, les constructeurs à partir d'un fichier IntPtr et ceux d'un SafeFileHandle .

FileStream(string,FileMode);
FileStream(string,FileMode,FileAccess);
FileStream(string,FileMode,FileAccess,FileShare);
FileStream(string,FileMode,FileAccess,FileShare,int);
FileStream(string,FileMode,FileAccess,FileShare,int,bool);

Il me semble que ce type de schéma pourrait être simplifié en ayant trois constructeurs à la place, et en utilisant des paramètres optionnels pour ceux qui peuvent être mis par défaut, ce qui rendrait les différentes familles de constructeurs plus distinctes [note : je sais que ce changement ne sera pas fait dans la BCL, je parle de manière hypothétique pour ce type de situation].

Qu'en pensez-vous ? À partir de C# 4.0, sera-t-il plus logique de faire des groupes de constructeurs et de méthodes étroitement liés une seule méthode avec des paramètres optionnels, ou y a-t-il une bonne raison de s'en tenir au mécanisme traditionnel de surcharge multiple ?

Answer 1

Je prendrais en considération les éléments suivants :

• Votre code doit-il pouvoir être utilisé dans des langages qui ne prennent pas en charge les paramètres optionnels ? Si c'est le cas, pensez à inclure les surcharges.
• Y a-t-il des membres de votre équipe qui s'opposent violemment aux paramètres optionnels ? (Il est parfois plus facile de s'accommoder d'une décision que l'on n'aime pas que de la défendre).
• Êtes-vous sûr que vos valeurs par défaut ne changeront pas d'une version à l'autre de votre code ou, si c'est le cas, vos interlocuteurs seront-ils d'accord avec cela ?

Je n'ai pas vérifié le fonctionnement des valeurs par défaut, mais je suppose qu'elles seront intégrées dans le code d'appel, de la même manière que les références à const champs. En général, cela ne pose pas de problème - les modifications d'une valeur par défaut sont de toute façon assez importantes - mais ce sont des éléments à prendre en compte.

Answer 2

Lorsqu'une surcharge de méthode effectue normalement la même chose avec un nombre différent d'arguments, les valeurs par défaut sont utilisées.

Lorsqu'une surcharge de méthode exécute une fonction différemment en fonction de ses paramètres, la surcharge continuera d'être utilisée.

J'ai utilisé optional à l'époque de VB6 et cela m'a manqué depuis, cela réduira beaucoup la duplication des commentaires XML en C#.

Answer 3

J'utilise Delphi avec des paramètres optionnels depuis toujours. Je suis passé à l'utilisation de surcharges à la place.

Car lorsque vous allez créer d'autres surcharges, vous allez invariablement entrer en conflit avec une forme de paramètre optionnel, et vous devrez alors les convertir en non optionnels de toute façon.

Et j'aime l'idée qu'il y a généralement un seul super et les autres sont des enveloppes plus simples autour de celle-ci.

Answer 4

Je vais certainement utiliser la fonctionnalité des paramètres optionnels de la version 4.0. Elle permet de se débarrasser des ridicules ...

public void M1( string foo, string bar )
{
   // do that thang
}

public void M1( string foo )
{
  M1( foo, "bar default" ); // I have always hated this line of code specifically
}

... et place les valeurs à l'endroit où l'appelant peut les voir ...

public void M1( string foo, string bar = "bar default" )
{
   // do that thang
}

C'est beaucoup plus simple et beaucoup moins sujet aux erreurs. J'ai en fait vu cela comme un bogue dans le cas de la surcharge ...

public void M1( string foo )
{
   M2( foo, "bar default" );  // oops!  I meant M1!
}

Je n'ai pas encore joué avec le compilateur 4.0, mais je ne serais pas choqué d'apprendre que le compilateur émet simplement les surcharges pour vous.

Answer 5

Les paramètres optionnels sont essentiellement des métadonnées qui indiquent au compilateur qui traite un appel de méthode d'insérer les valeurs par défaut appropriées à l'endroit de l'appel. En revanche, les surcharges permettent au compilateur de sélectionner une méthode parmi d'autres, dont certaines peuvent elles-mêmes fournir des valeurs par défaut. Notez que si vous essayez d'appeler une méthode qui spécifie des paramètres optionnels à partir d'un code écrit dans un langage qui ne les supporte pas, le compilateur exigera que les paramètres "optionnels" soient spécifiés, mais comme appeler une méthode sans spécifier de paramètre optionnel équivaut à l'appeler avec un paramètre égal à la valeur par défaut, il n'y a pas d'obstacle à ce que de tels langages appellent de telles méthodes.

Une conséquence importante de la liaison des paramètres facultatifs au site d'appel est que des valeurs leur seront attribuées en fonction de la version du code cible dont dispose le compilateur. Si un assemblage Foo a une méthode Boo(int) avec une valeur par défaut de 5, et l'assemblage Bar contient un appel à Foo.Boo() le compilateur le traitera comme un Foo.Boo(5) . Si la valeur par défaut est modifiée en 6 et que l'assemblage Foo est recompilé, Bar continuera d'appeler Foo.Boo(5) à moins ou jusqu'à ce qu'il soit recompilé avec cette nouvelle version de Foo . Il convient donc d'éviter d'utiliser des paramètres facultatifs pour des éléments susceptibles de changer.