Udostępnij za pomocą

Rozważania dotyczące przeciążania procedur (Visual Basic)

W przypadku przeciążenia procedury należy użyć innego podpisu dla każdej przeciążonej wersji. Zwykle oznacza to, że każda wersja musi określać inną listę parametrów. Aby uzyskać więcej informacji, zobacz "Różne podpisy" w temacie Przeciążanie procedury.

Można przeciążyć procedurę Function procedurą Sub i odwrotnie, pod warunkiem, że mają różne podpisy. Dwa przeciążenia nie mogą się różnić tylko tym, że jedno ma wartość zwracaną, a drugie nie.

Właściwość można przeciążyć w taki sam sposób, jak procedurę, i z tymi samymi ograniczeniami. Nie można jednak przeciążać metody właściwością lub odwrotnie.

Alternatywy dla przeciążonych wersji

Czasami istnieją alternatywy dla przeciążonych wersji, szczególnie gdy obecność argumentów jest opcjonalna lub ich liczba jest zmienna.

Należy pamiętać, że opcjonalne argumenty nie muszą być obsługiwane przez wszystkie języki, a tablice parametrów są ograniczone do języka Visual Basic. Jeśli piszesz procedurę, która prawdopodobnie zostanie wywołana z kodu napisanego w dowolnym z kilku różnych języków, przeciążone wersje oferują największą elastyczność.

Przeciążenia i argumenty opcjonalne

Jeśli kod wywołujący może opcjonalnie podać lub pominąć jeden lub więcej argumentów, można zdefiniować wiele przeciążonych wersji lub użyć opcjonalnych parametrów.

Kiedy należy używać przeciążonych wersji

W następujących przypadkach można rozważyć zdefiniowanie serii przeciążonych wersji:

  • Logika w kodzie procedury różni się znacznie w zależności od tego, czy kod wywołujący dostarcza opcjonalny argument, czy nie.

  • Kod procedury nie może niezawodnie przetestować, czy kod wywołujący dostarczył opcjonalny argument. Jest to na przykład sytuacja, gdy nie ma możliwego kandydata na wartość domyślną, a kod wywołujący nie może być oczekiwany, by go dostarczyć.

Kiedy należy używać parametrów opcjonalnych

W następujących przypadkach możesz preferować co najmniej jeden opcjonalny parametr:

  • Jedyną wymaganą akcją, gdy kod wywołujący nie dostarcza opcjonalnego argumentu, jest ustawienie parametru na wartość domyślną. W takim przypadku kod procedury może być mniej skomplikowany, jeśli zdefiniujesz jedną wersję z co najmniej jednym Optional parametrem.

Aby uzyskać więcej informacji, zobacz Parametry opcjonalne.

Przeciążenia i tablice parametryczne

Gdy kod wywołujący może przekazać zmienną liczbę argumentów, można zdefiniować wiele przeciążonych wersji lub użyć tablicy parametrów.

Kiedy należy używać przeciążonych wersji

W następujących przypadkach można rozważyć zdefiniowanie serii przeciążonych wersji:

  • Wiesz, że kod wywołujący nigdy nie przekazuje więcej niż niewielkiej liczby wartości do tablicy parametrów.

  • Logika w kodzie procedury różni się znacząco w zależności od liczby wartości, które przekazuje kod wywołujący.

  • Kod wywołujący może przekazywać wartości różnych typów danych.

Kiedy należy używać tablicy parametrów

Lepiej jest użyć ParamArray parametru w następujących przypadkach:

  • Nie można przewidzieć, ile wartości kod wywołujący może przekazać do tablicy parametrów i może to być duża liczba.

  • Logika procedury nadaje się do iterowania przez wszystkie wartości przekazywane przez kod wywołujący, wykonując zasadniczo te same operacje na każdej wartości.

Aby uzyskać więcej informacji, zobacz Tablice parametrów.

Niejawne przeciążenia parametrów opcjonalnych

Procedura z opcjonalnym parametrem jest równoważna dwóm przeciążonym procedurom, po jednym z opcjonalnym parametrem i jednym bez niego. Nie można przeciążyć takiej procedury listą parametrów odpowiadającą któremukolwiek z tych przypadków. Poniższe deklaracje ilustrują to.

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)

W przypadku procedury z więcej niż jednym opcjonalnym parametrem istnieje zestaw niejawnych przeciążeń, do którego dotarła logika podobna do tego w poprzednim przykładzie.

Niejawne przeciążenia parametru ParamArray

Kompilator uznaje, że procedura z parametrem ParamArray ma nieskończoną liczbę przeciążeń, które różnią się tym, co kod wywołujący przekazuje do tablicy parametrów w następujący sposób:

  • Gdy kod wywołujący nie dostarcza argumentu do ParamArray, stosowane jest jedno przeciążenie.

  • Jedno przeciążenie, gdy wywołujący kod dostarcza jednowymiarową tablicę ParamArray typu elementu

  • Dla każdej dodatniej liczby całkowitej jedno przeciążenie, gdy kod wywołujący dostarcza taką liczbę argumentów, każdy z typu elementu ParamArray

Poniższe deklaracje ilustrują te niejawne przeciążenia.

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.

Nie można przeciążyć takiej procedury, używając listy parametrów, która przyjmuje jednowymiarową tablicę jako tablicę parametrów. Można jednak używać sygnatur innych niejawnych przeciążeń. Poniższe deklaracje ilustrują to.

' 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)

Programowanie bez typów jako alternatywa dla przeciążenia

Jeśli chcesz zezwolić kodowi wywołującego na przekazywanie różnych typów danych do parametru, alternatywne podejście to programowanie bez użycia typów. Możesz ustawić przełącznik sprawdzania typów na Off za pomocą instrukcji Option Strict lub opcji kompilatora -optionstrict. Następnie nie trzeba deklarować typu danych parametru. Jednak takie podejście ma następujące wady w porównaniu z przeciążeniem:

  • Programowanie bez typów generuje mniej wydajny kod wykonywania.

  • Procedura musi testować każdy typ danych, który przewiduje, że zostanie przekazany.

  • Kompilator nie może zasygnalizować błędu, jeśli kod wywołujący przekazuje typ danych, którego procedura nie obsługuje.

Zobacz także

  • Last updated on