Udostępnij za pośrednictwem

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

  • Artykuł

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 w tym, że ma wartość zwracaną, a druga nie.

Właściwość można przeciążyć w taki sam sposób, jak przeciążenie procedury i z tymi samymi ograniczeniami. Nie można jednak przeciążyć procedury z właściwością lub na odwrót.

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 przypadek, jeśli nie ma możliwego kandydata dla wartości domyślnej, że nie można oczekiwać podania kodu wywołującego.

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 paramArrays

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 obsłużyć ParamArray parametr 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 z listą parametrów odpowiadającą jednej z tych czynności. 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 rozważa procedurę z parametrem ParamArray , aby mieć nieskończoną liczbę przeciążeń, różniąc się od siebie w tym, co kod wywołujący przekazuje do tablicy parametrów w następujący sposób:

  • Jedno przeciążenie elementu , gdy kod wywołujący nie dostarcza argumentu do elementu ParamArray

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

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

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 z listą parametrów, która przyjmuje tablicę jednowymiarową dla tablicy parametrów. Można jednak użyć podpisów 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 Off sprawdzania typów na za pomocą opcji Ścisłe instrukcji lub opcji -optionstrict kompilatora. 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 być testowana dla każdego typu danych, który przewiduje powodzenie.

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

Zobacz też