Partager via

Considérations sur les surcharges de procédures (Visual Basic)

  • Article

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 Procédure surchargée.

Vous pouvez surcharger une procédure Function avec une procédure Sub, et vice versa, à condition qu’elles aient des signatures différentes. Deux surcharges ne peuvent pas différer uniquement dans celle-ci ayant une valeur de retour et l’autre ne le fait pas.

Vous pouvez surcharger une propriété de la même façon 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 avez parfois des 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 que les tableaux de paramètres sont limités à Visual Basic. Si vous écrivez une procédure susceptible d’être appelée à partir du code écrit dans l’un des différents langages, les versions surchargées offrent la plus grande flexibilité.

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

Vous pouvez envisager de définir une série de versions surchargées dans les cas suivants :

  • La logique du code de procédure est sensiblement différente selon que le code appelant fournit un argument facultatif ou non.

  • Le code de procédure ne peut pas tester de manière fiable si le code appelant a fourni un argument facultatif. C’est le cas, par exemple, s’il n’existe aucun candidat possible pour une valeur par défaut que le code appelant ne pouvait pas fournir.

Quand utiliser des paramètres facultatifs

Vous pouvez préférer un ou plusieurs paramètres facultatifs dans les cas suivants :

  • La seule action requise lorsque le code appelant ne fournit pas d’argument facultatif consiste à définir le paramètre sur 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 ParamArrays

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

Vous pouvez envisager de définir une série de versions surchargées dans les cas suivants :

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

  • La logique dans le code de procédure est sensiblement différente selon le nombre de valeurs que le code appelant passe.

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

Quand utiliser un tableau de paramètres

Vous êtes mieux servi par un paramètre ParamArray dans les cas suivants :

  • Vous ne pouvez pas prédire le nombre de valeurs que le code appelant peut passer au tableau de paramètres, et il peut s’agir d’un grand nombre.

  • La logique de procédure se prête à itérer toutes les valeurs que le code appelant passe, effectuant essentiellement les mêmes opérations sur chaque valeur.

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

Surcharges implicites pour les paramètres facultatifs

Une procédure avec un paramètre facultatif équivaut à deux procédures surchargées, une avec le paramètre facultatif et une sans celui-ci. Vous ne pouvez pas surcharger une telle procédure avec une liste de paramètres correspondant à l’un de ces éléments. Les déclarations suivantes illustrent cela.

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)

Pour une procédure avec plusieurs paramètres facultatifs, il existe un ensemble de surcharges implicites, arrivé par logique similaire à celle de l’exemple précédent.

Surcharges implicites pour un paramètre ParamArray

Le compilateur considère qu’une procédure avec un paramètre ParamArray doit avoir un nombre infini de surcharges, qui diffèrent les unes des autres dans ce que le code appelant passe au tableau de paramètres, comme suit :

  • Une surcharge pour laquelle le code appelant ne fournit pas d’argument au ParamArray

  • Une surcharge pour laquelle le code appelant fournit un tableau unidimensionnel du type d’élément ParamArray

  • Pour chaque entier positif, une surcharge pour laquelle le code appelant fournit ce nombre d’arguments, chacun du type d’élément 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 telle procédure avec une liste de paramètres qui utilise un tableau unidimensionnel pour le tableau de paramètres. Toutefois, vous pouvez utiliser les signatures des autres surcharges implicites. Les déclarations suivantes illustrent cela.

' 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 comme alternative à la surcharge

Si vous souhaitez autoriser le code appelant à passer différents types de données à un paramètre, une autre approche est la programmation sans type. Vous pouvez définir le commutateur de vérification de type sur Off avec l’instruction Option Strict ou l’option du compilateur -optionstrict. Vous n’avez pas besoin de déclarer le type de données du paramètre. Toutefois, cette approche présente les inconvénients suivants par rapport à la surcharge :

  • La programmation sans type produit du code d’exécution moins efficace.

  • La procédure doit tester chaque type de données qu’elle prévoit d’être passée.

  • Le compilateur ne peut pas signaler une erreur si le code appelant transmet un type de données que la procédure ne prend pas en charge.

Voir aussi