Partager via


Considérations sur les surcharges de procédures

Mise à jour : novembre 2007

Lorsque vous surchargez une procédure, vous devez utiliser une signature différente pour chaque version surchargée. Cela signifie généralement que chaque version doit spécifier une liste de paramètres différente. Pour plus d'informations, consultez « Signature différente » dans Surcharge de procédure.

Vous pouvez surcharger une procédure Function avec une procédure Sub, et inversement, à condition que leurs signatures soient différentes. Deux surcharges ne peuvent pas différer uniquement suivant que l'un a une valeur de retour et l'autre pas.

Vous pouvez surcharger une propriété de la même manière que vous surchargez une procédure et avec les mêmes restrictions. Toutefois, vous ne pouvez pas surcharger une procédure avec une propriété, ou inversement.

Alternatives aux versions surchargées

Vous disposez parfois d'alternatives aux versions surchargées, en particulier lorsque la présence d'arguments est facultative ou que leur nombre est variable.

N'oubliez pas que les arguments facultatifs ne sont pas nécessairement pris en charge par tous les langages et les tableaux de paramètres sont limités à Visual Basic. Si vous écrivez une procédure qui sera vraisemblablement appelée à partir du code écrit dans un des différents langages, les versions surchargées offrent la plus grande souplesse.

Surcharges et arguments facultatifs

Lorsque le code appelant peut éventuellement fournir ou omettre un ou plusieurs arguments, vous pouvez définir plusieurs versions surchargées ou utiliser des paramètres facultatifs.

Quand utiliser des versions surchargées

Pensez à définir une série de versions surchargées dans les cas suivants :

  • La logique dans le code de procédure est très différente suivant que le code appelant fournit un argument facultatif ou pas.

  • Le code de procédure ne peut pas vérifier de manière fiable si le code appelant a fourni un argument facultatif. Par exemple, c'est le cas s'il n'y a aucun candidat possible pour une valeur par défaut que le code appelant n'était pas supposé fournir.

Quand utiliser les paramètres facultatifs

Il peut être préférable d'utiliser un ou plusieurs des paramètres facultatifs dans les cas suivants :

  • La seule action requise lorsque le code appelant ne fournit pas un argument facultatif est de définir le paramètre à une valeur par défaut. Dans ce cas, le code de procédure peut être moins compliqué si vous définissez une version unique avec un ou plusieurs paramètres Optional.

Pour plus d'informations, consultez Paramètres facultatifs.

Surcharges et ParamArray

Lorsque le code appelant peut passer un nombre variable d'arguments, vous pouvez définir plusieurs versions surchargées ou utiliser un tableau de paramètres.

Quand utiliser des versions surchargées

Pensez à définir une série de versions surchargées dans les cas suivants :

  • Vous savez que le code appelant ne passe jamais plus qu'un petit nombre de valeurs au tableau de paramètres.

  • La logique dans le code de procédure est très différente selon le nombre de valeurs passées par le code appelant.

  • Le code appelant peut passer des valeurs de types de données différents.

Quand utiliser un tableau de paramètres

Un paramètre ParamArray est plus utile dans les cas suivants :

  • Vous n'êtes pas en mesure de prévoir combien de valeurs le code appelant peut passer au tableau de paramètres et elles pourraient représenter un grand nombre.

  • La logique de procédure implique de parcourir toutes les valeurs que le code appelant passe, en exécutant essentiellement les mêmes opérations sur chaque valeur.

Pour plus d'informations, consultez Tableaux de paramètres.

Surcharges implicites des paramètres facultatifs

Une procédure avec un paramètre Optional (Visual Basic) équivaut à deux procédures surchargées, l'une avec l'argument facultatif et l'autre sans cet argument. Vous ne pouvez pas surcharger une procédure avec une liste de paramètres correspondant à l'un ou l'autre de ceux-ci. Les déclarations suivantes illustrent ce principe.

Overloads Sub q(ByVal b As Byte, Optional ByVal j As Long = 6)
' The preceding definition is equivalent to the following two overloads.
' Overloads Sub q(ByVal b As Byte)
' Overloads Sub q(ByVal b As Byte, ByVal j As Long)
' Therefore, the following overload is not valid because the signature is already in use.
' Overloads Sub q(ByVal c As Byte, ByVal k As Long)
' The following overload uses a different signature and is valid.
Overloads Sub q(ByVal b As Byte, ByVal j As Long, ByVal s As Single)

Dans le cas d'une procédure possédant plusieurs arguments facultatifs, il existe un ensemble de surcharges implicites, qui peuvent se produire de manière logique, comme dans l'exemple précédent.

Surcharges implicites pour un paramètre ParamArray

Le compilateur considère qu'une procédure comportant un paramètre ParamArray possède un nombre infini de surcharges, qui se différencient selon ce que le code appelant passe au tableau de paramètres, notamment :

  • Une surcharge lorsque le code appelant ne fournit pas d'argument au ParamArray

  • Une surcharge lorsque le code appelant fournit un tableau unidimensionnel du type d'élément ParamArray

  • Pour chaque entier positif, une surcharge lorsque le code appelant fournit le nombre correspondant d'arguments dont le type d'élément est ParamArray

Les déclarations suivantes illustrent ces surcharges implicites.

Overloads Sub p(ByVal d As Date, ByVal ParamArray c() As Char)
' The preceding definition is equivalent to the following overloads.
' Overloads Sub p(ByVal d As Date)
' Overloads Sub p(ByVal d As Date, ByVal c() As Char)
' Overloads Sub p(ByVal d As Date, ByVal c1 As Char)
' Overloads Sub p(ByVal d As Date, ByVal c1 As Char, ByVal c2 As Char)
' And so on, with an additional Char argument in each successive overload.

Vous ne pouvez pas surcharger une procédure avec une liste de paramètres qui prend un tableau unidimensionnel pour le tableau de paramètres. Toutefois, vous pouvez utiliser les signatures des autres surcharges implicites. Les déclarations suivantes illustrent ce principe.

' The following overload is not valid because it takes an array for the parameter array.
' Overloads Sub p(ByVal x As Date, ByVal y() As Char)
' The following overload takes a single value for the parameter array and is valid.
Overloads Sub p(ByVal z As Date, ByVal w As Char)

Programmation sans type en remplacement de la surcharge

Si vous souhaitez permettre au code appelant de passer des types de données différents à un paramètre, Programmation sans type dans Visual Basic est une approche alternative. Vous pouvez affecter la valeur Off au commutateur de vérification de type avec l'instruction Option Strict ou l'option du compilateur /optionstrict. Vous ne devez donc pas déclarer le type de données du paramètre. Cependant, cette approche présente les inconvénients suivants par rapport à la surcharge :

  • La programmation sans type génère une exécution moins efficace du code.

  • La procédure doit tester tous les types de données pouvant être passés.

  • Le compilateur ne peut pas signaler d'erreur si le code appelant passe un type de données non pris en charge par la procédure.

Voir aussi

Tâches

Procédures de dépannage

Comment : définir plusieurs versions d'une procédure

Comment : appeler une procédure surchargée

Comment : surcharger une procédure qui accepte des paramètres optionnels

Comment : surcharger une procédure qui accepte un nombre indéfini de paramètres

Concepts

Procédures dans Visual Basic

Paramètres et arguments d'une procédure

Résolution de surcharge

Référence

Overloads