Przeładowania metod to podstawy języka. Niestety, nieumiejętnie stosowane, mogą przystworzyć problemów nawet zaawansowanym programistom. Z tego względu, uważam, że należy po prostu unikać tych przeładować, które są zbyt trudne w zrozumieniu – powodują niepotrzebne zamieszanie.

Zacznijmy od klasycznego przykładu, który jest zrozumiały dla każdego:

private static void Main(string[] args)
{
      Display("Hello World");
      Display(5);
}

private static void Display(string text)
{
  Console.WriteLine("string");
}

private static void Display(int number)
{
  Console.WriteLine("int");
}

Nie ma tutaj żadnej zagadki – pierwsze wywołanie wykona funkcje z parametrem string a drugie z int. Nieco mniej zrozumiałą konstrukcją może być:

private static void Main(string[] args)
{
      Display(5);
}
private static void Display(double arg)
{
  Console.WriteLine("double");
}
private static void Display(Int16 arg)
{
  Console.WriteLine("int16");
}
private static void Display(int arg)
{
  Console.WriteLine("int");
}
private static void Display(float arg)
{
  Console.WriteLine("float");
}

Która funkcja zostanie wywołana? Teoretycznie każda z nich spełnia wymagania ponieważ 5 może być skonwertowane zarówno do int16 jak i int, float, double czy long. C# zawsze będzie starał się dobrać najlepsze dopasowanie. Mamy tutaj do czynienia z całkowitą liczbą, stąd int16,int,long są lepszymi kandydatami niż zmiennoprzecinkowe (skomplikowane) zmienne typu double czy float.

I tutaj mała pułapka… Może wydawać się, że int16 jest lepszy niż int ponieważ zajmuje mniej pamięci, a żeby pomieścić cyfrę 5, 16 bitów w zupełności wystarcza. Deklarując jednak każdą zmienne, możemy określić jej typ za pomocą specyfikatorów, a mianowicie (źródło, stackoverflow):

var d = 1.0d; // double
var f = 1.0f; // float
var m = 1.0m; // decimal
var i = 1; // int
var ui = 1U; // uint
var ul = 1UL; // ulong
var l = 1L; // long

Stąd wynika, że jak przekażemy liczbę całkowitą, bez specyfikatora, zostanie użyty typ Int32. Powinno być już jasne, która metoda zostanie wykonana, gdy wywołamy:

Display(5.00);

Będzie to oczywiście wersja z Double – aby wywołać float musielibyśmy napisać 5.00f.

A co jeśli mamy następujący kod?

internal class Program
{
   private static void Main(string[] args)
   {
           Display(5.00);
   }

   private static void Display(float arg)
   {
       Console.WriteLine("float");
   }
}

Wywoła to błąd kompilacji – 5.00 to double a nie float – nie ma tutaj niejawnej konwersji. Natomiast, niejawna konwersja ma miejsce z typu mniej dokładnego do bardziej, tzn.:

internal class Program
{
   private static void Main(string[] args)
   {
           Display(5.00f);
   }

   private static void Display(double arg)
   {
       Console.WriteLine("double");
   }
}

Widać, że jest trochę tutaj niespodzianek. To jednak dopiero początek. C# naprawdę potrafi zaskoczyć,  jeśli chodzi o wywoływanie metod. Powyższe pułapki są mimo wszystko logiczne i wiadomo, czego można spodziewać się.

Rozważmy następujący przykład:

internal class Program
{
   private static void Main(string[] args)
   {
       Child child = new Child();
       child.Display((int) 5);
   }
}

internal class Parent
{
   public void Display(int arg)
   {
       Console.WriteLine("int");
   }

}

internal class Child : Parent
{
   public void Display(double arg)
   {
       Console.WriteLine("double");
   }
}

Child dziedziczy po Parent. Nie mamy tutaj do czynienia z method hiding, ponieważ sygnatury metod są różne od siebie. Jest to wciąż klasyczny przykład przeładowywania metod. Normalnie, Display z Integer zostałby wywołany, ponieważ jest to lepsze dopasowanie. C# jednak w przypadku dziedziczenia, zawsze weźmie najpierw pod uwagę metodę znajdującą się bliżej w hierarchii klas. Operujemy na Child, dlatego najpierw będzie C# próbował znaleźć dopasowanie w Child, a dopiero potem w Parent. Z tego względu Display(double) wygrywa i zostanie wykona.

Jest to poważna pułapka i osobiście unikam takiego kodu. Wystarczy, że zmienimy wskaźniki na:

private static void Main(string[] args)
{
  Parent child = new Child();
  child.Display((int) 5);
}

I w takim przypadku, wersja z Int zostanie wywołania a nie z double, jak powyżej.

Kolejną pułapką są wirtualne metody i ich przeciążenia:

internal class Program
{
   private static void Main(string[] args)
   {
       Child child = new Child();
       child.Display((int) 5);
   }
}

internal class Parent
{
   public virtual void Display(int arg)
   {
       Console.WriteLine("int");
   }
}

internal class Child : Parent
{
   public override void Display(int arg)
   {
       Console.WriteLine("override int");
   }
   
   public void Display(double arg)
   {
       Console.WriteLine("double");
   }
}

Korzystamy ze wskaźnika Child, zatem najpierw próbujemy znaleźć dopasowanie w Child. Mamy przeciążoną metodę Display(int) i logiczna odpowiedź brzmiałaby, że “override int” zostanie wywołany. Twórcy C# jednak, zdecydowali się ignorować przeciążenia i w pierwszej kolejności zostaną rozpatrzone wszystkie inne metody w Child – w tym przypadku będzie to Display(double)!

W przyszłym poście, kolejne dziwne przeładowania wykorzystujące dziedziczenie – to właśnie one powodują największe problemy i powinny być unikane.