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
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
Paramètres et arguments d'une procédure