Konstruktory — obiekt gotowy do działania

Czego się dziś nauczysz

Przygotowanie: lekcje 01–39. Przewidywany czas: 90 min z zadaniami. Przykłady wymagają .NET 8 lub nowszego, z włączonymi ImplicitUsings i Nullable.

Obiekt, który przez chwilę jest niegotowy

W lekcjach 37–39 obiekt powstawał pusty, a dane wkładaliśmy do niego po utworzeniu:

Bilet b = new Bilet();
b.Wydarzenie = "Turniej retro";
b.Cena = 20.50m;
b.Miejsca = 2;

b.Pokaz();

Trzy wiersze przypisań po każdym new. Działa, dopóki nikt nie zapomni ani jednego z nich — a zapomni, bo nic go nie pilnuje:

Bilet c = new Bilet();
c.Wydarzenie = "Noc robotow";
// zapomniana cena i liczba miejsc

c.Pokaz();        // Noc robotow, 0,00 zl, miejsc 0

Bilet za zero złotych na zero miejsc przeszedł bez żadnego ostrzeżenia. I to jest dokładnie ten rodzaj błędu, który wychodzi dopiero przy rozliczeniu kasy.

Nazwa klasy, brak typu wyniku i this

Konstruktor to metoda uruchamiana automatycznie przy tworzeniu obiektu. Rozpoznasz go po dwóch cechach, których nie ma żadna inna metoda:

• nazywa się dokładnie tak jak klasa;
• nie ma typu wyniku — nawet void się nie pisze.

class Bilet
{
    public readonly string Wydarzenie;
    public readonly decimal Cena;
    public readonly int Miejsca;

    public Bilet(string wydarzenie, decimal cena, int miejsca)   // bez void!
    {
        Wydarzenie = wydarzenie;
        Cena = cena;
        Miejsca = miejsca;
    }

    public void Pokaz()
    {
        Console.WriteLine($"{Wydarzenie}: {Cena:F2} zl, miejsc {Miejsca}");
    }
}

Bilet b = new Bilet("Turniej retro", 20.50m, 2);
b.Pokaz();

// Bilet c = new Bilet();              // BLAD CS1729 - ta klasa wymaga argumentow
// b.Wydarzenie = "cos innego";        // BLAD CS0191 - pole jest readonly

Turniej retro: 20,50 zl, miejsc 2

Trzy wiersze przypisań zniknęły z Main. Co ważniejsze — nie da się już utworzyć biletu bez tych danych: zapis new Bilet() nie przechodzi kompilacji.

Pola są readonly (lekcja 38), więc po utworzeniu nikt ich nie podmieni. Konstruktor jest jedynym miejscem, w którym wolno im nadać wartość.

Słowo this przy polu o tej samej nazwie

Przyjęło się nazywać parametr tak samo jak pole, tylko małą literą. Gdy nazwy są identyczne, parametr zasłania pole i trzeba to rozróżnić:

class Paczka
{
    private int masa;

    public Paczka(int masa)
    {
        masa = masa;          // BEZ SKUTKU - przypisanie parametru do siebie
        this.masa = masa;     // DOBRZE - this.masa to pole tego obiektu
    }
}

Pierwszy wiersz kompiluje się i nic nie robi; kompilator wypisze tylko ostrzeżenie o przypisaniu zmiennej do niej samej. this znaczy „bieżący obiekt”, więc this.masa wskazuje jednoznacznie pole, a nie parametr.

Prezent, który przepada

Do lekcji 39 pisaliśmy new Bilet() i działało, choć żadnego konstruktora nie było. To nie przypadek: klasa bez ani jednego konstruktora dostaje od kompilatora konstruktor bezparametrowy, który nic nie robi.

Ale ten prezent przepada w chwili, gdy napiszesz własny konstruktor:

class Pusta
{
}
// new Pusta()  - dziala, bo kompilator dopisal konstruktor bezparametrowy

class Paczka
{
    public readonly int Masa;

    public Paczka(int masa)
    {
        Masa = masa;
    }
}
// new Paczka(3)  - dziala
// new Paczka()   - BLAD CS1729: nie ma konstruktora bez argumentow

Ten sam komunikat zobaczysz w lekcji 45, gdy klasa pochodna zapomni wywołać konstruktor bazowy — przyczyna jest dokładnie ta sama.

Przeciążanie i : this(…)

Klasa może mieć kilka konstruktorów, o ile różnią się listą parametrów. To przeciążanie, które znasz z lekcji 20 — tu działa identycznie:

class Bilet
{
    public readonly string Wydarzenie;
    public readonly decimal Cena;
    public readonly int Miejsca;

    public Bilet(string wydarzenie, decimal cena, int miejsca)
    {
        Wydarzenie = wydarzenie;
        Cena = cena;
        Miejsca = miejsca;
    }

    public Bilet(string wydarzenie)              // skrot: cena i miejsca domyslne
    {
        Wydarzenie = wydarzenie;
        Cena = 20m;
        Miejsca = 1;
    }
}

Działa, ale przypisania są przepisane dwa razy. Gdy dojdzie sprawdzanie nazwy, trzeba będzie dopisać je w obu miejscach — i w jednym się o tym zapomni. Dlatego konstruktor może przekazać pracę innemu konstruktorowi tej samej klasy:

    public Bilet(string wydarzenie, decimal cena, int miejsca)
    {
        Wydarzenie = wydarzenie;
        Cena = cena;
        Miejsca = miejsca;
    }

    public Bilet(string wydarzenie) : this(wydarzenie, 20m, 1)
    {
        // ciało może być puste — cała robota jest w konstruktorze głównym
    }

Teraz przypisania są zapisane raz. Kolejność wykonania jest ustalona i warto ją zobaczyć:

Bilet b = new Bilet("Noc robotow");

class Bilet
{
    public Bilet(string wydarzenie, decimal cena, int miejsca)
    {
        Console.WriteLine("1. konstruktor glowny");
    }

    public Bilet(string wydarzenie) : this(wydarzenie, 20m, 1)
    {
        Console.WriteLine("2. konstruktor skrocony");
    }
}

1. konstruktor glowny
2. konstruktor skrocony

Najpierw wykonuje się konstruktor wskazany po : this(...), dopiero potem ciało tego, który go wywołał. Tak samo jak przy : base(...) w lekcji 45 — tam wskazywana jest klasa bazowa, tu inny konstruktor tej samej klasy.

Reguła, której nie da się ominąć

Teraz to, co jest największym zyskiem z konstruktora. Skoro jest jedyną drogą do utworzenia obiektu, to jest też jedynym miejscem, w którym trzeba sprawdzić dane — a sprawdzenia nie da się ominąć.

class Bilet
{
    public readonly string Wydarzenie;
    public readonly decimal Cena;
    public readonly int Miejsca;

    public Bilet(string wydarzenie, decimal cena, int miejsca)
    {
        if (string.IsNullOrWhiteSpace(wydarzenie))
        {
            throw new ArgumentException("nazwa wydarzenia nie moze byc pusta",
                                        nameof(wydarzenie));
        }

        if (miejsca < 1)
        {
            throw new ArgumentOutOfRangeException(nameof(miejsca),
                                                 "musi byc co najmniej jedno miejsce");
        }

        if (cena < 0m)
        {
            throw new ArgumentOutOfRangeException(nameof(cena),
                                                 "cena nie moze byc ujemna");
        }

        Wydarzenie = wydarzenie.Trim();
        Cena = cena;
        Miejsca = miejsca;
    }
}

Sprawdzenia stoją przed przypisaniami — nie ma sensu wypełniać obiektu, który zaraz zostanie odrzucony. Wyjątki i słowo throw poznałeś w lekcji 35; nameof(wydarzenie) wstawia nazwę parametru jako napis, dzięki czemu komunikat wskazuje, co dokładnie było nie tak.

try
{
    Bilet zly = new Bilet("", 10m, 1);
}
catch (ArgumentException ex)
{
    Console.WriteLine(ex.Message);
}

nazwa wydarzenia nie moze byc pusta (Parameter 'wydarzenie')

Nawias z nazwą parametru dopisuje .NET sam — to właśnie zasługa nameof. Przy pięciu parametrach taka wskazówka oszczędza kwadrans szukania.

Czego do konstruktora nie wkładamy

Gdzie pole dostaje wartość i w jakiej kolejności

Pole może dostać wartość w trzech różnych miejscach, a kolejność między nimi jest ustalona. Dopóki jej nie znasz, część wyników wygląda na przypadkowe.

Zgloszenie z = new Zgloszenie("Kasia") { Uwagi = "pilne" };
Console.WriteLine(z.Uwagi);

class Zgloszenie
{
    public readonly string Imie;
    public string Uwagi = "brak";          // 1. INICJALIZATOR POLA

    public Zgloszenie(string imie)
    {
        Imie = imie;
        Console.WriteLine($"w konstruktorze Uwagi = {Uwagi}");   // 2. CIALO KONSTRUKTORA
    }
}

w konstruktorze Uwagi = brak
pilne

Wynik pokazuje całą kolejność. W chwili wykonywania konstruktora Uwagi ma już wartość "brak" z inicjalizatora pola, a tekst "pilne" trafia tam po zakończeniu konstruktora — bo klamry po new to inicjalizator obiektu, czyli skrót na przypisania wykonywane już na gotowym obiekcie.

Nowy obiekt z istniejącego — i co z destruktorem

Czasem nowy obiekt ma powstać na podstawie istniejącego: duplikat biletu dla opiekuna, kopia zgłoszenia do poprawy. W C# nie ma na to nic gotowego — konstruktor przyjmujący obiekt własnej klasy pisze się samemu:

class Bilet
{
    public readonly string Wydarzenie;
    public readonly decimal Cena;
    public readonly int Miejsca;
    public string Uwagi = "brak";

    public Bilet(string wydarzenie, decimal cena, int miejsca)
    {
        Wydarzenie = wydarzenie;
        Cena = cena;
        Miejsca = miejsca;
    }

    public Bilet(Bilet inny) : this(inny.Wydarzenie, inny.Cena, inny.Miejsca)
    {
        Uwagi = inny.Uwagi;
    }
}

Bilet a = new Bilet("Turniej retro", 20.50m, 2);
a.Uwagi = "rzad pierwszy";

Bilet b = new Bilet(a);         // kopia
b.Uwagi = "duplikat";           // zmiana kopii NIE dotyka oryginalu

Console.WriteLine(a.Uwagi);     // rzad pierwszy
Console.WriteLine(b.Uwagi);     // duplikat

Konstruktor kopiujący wywołuje główny przez : this(...), więc kopia przechodzi przez te same sprawdzenia co nowy obiekt. To nie drobiazg: kopia obiektu wczytanego z pliku nie stanie się nagle obiektem niepoprawnym.

A destruktor?

Podstawa programowa wymienia destruktor obok konstruktora. W C# odpowiada mu finalizator, zapisywany ~Bilet(), ale w praktyce prawie się go nie pisze: pamięć zwalnia automatycznie odśmiecacz, a momentu wykonania finalizatora nie da się przewidzieć.

class Bilet
{
    ~Bilet()                  // finalizator - odpowiednik destruktora
    {
        // wykona sie kiedys, gdy odsmiecacz uzna to za stosowne
    }
}

Gdy obiekt trzyma zasób, który trzeba zwolnić w konkretnej chwili — otwarty plik, połączenie — używa się metody Dispose() i bloku using z lekcji 36. Umowa IDisposable, która za tym stoi, to temat lekcji 48.

Kasa biletowa

Kasa biletowa: trzy konstruktory prowadzące do jednego, sprawdzanie danych, inicjalizator pola i inicjalizator obiektu. Wypisywanie w konstruktorach jest tu wyłącznie po to, żeby pokazać kolejność — w prawdziwej klasie by go nie było.

// Program.cs - pelny plik
Console.WriteLine("=== tworzenie ===");

Bilet a = new Bilet("Turniej retro", 20.50m, 2);
Bilet b = new Bilet("Noc robotow");
Bilet c = new Bilet(a);
c.Uwagi = "duplikat dla opiekuna";

Console.WriteLine();
Console.WriteLine("=== trzy bilety ===");
a.Pokaz();
b.Pokaz();
c.Pokaz();

Console.WriteLine();
Console.WriteLine("=== inicjalizator obiektu ===");
Bilet d = new Bilet("Pokaz laserow", 15m, 1) { Uwagi = "wejscie od tylu" };
d.Pokaz();

Console.WriteLine();
Console.WriteLine("=== dane, ktorych konstruktor nie przyjmie ===");

try
{
    Bilet zly = new Bilet("   ", 10m, 1);
}
catch (ArgumentException ex)
{
    Console.WriteLine($"odrzucono: {ex.Message}");
}

try
{
    Bilet zly = new Bilet("Koncert", 10m, 0);
}
catch (ArgumentOutOfRangeException ex)
{
    Console.WriteLine($"odrzucono parametr: {ex.ParamName}");
}

Console.WriteLine();
List<Bilet> sprzedane = new List<Bilet> { a, b, c, d };
Console.WriteLine($"Biletow na liscie: {sprzedane.Count}");


class Bilet
{
    public readonly string Wydarzenie;
    public readonly decimal Cena;
    public readonly int Miejsca;

    public string Uwagi = "brak";               // inicjalizator pola

    public Bilet(string wydarzenie, decimal cena, int miejsca)
    {
        if (string.IsNullOrWhiteSpace(wydarzenie))
        {
            throw new ArgumentException("nazwa wydarzenia nie moze byc pusta",
                                        nameof(wydarzenie));
        }

        if (miejsca < 1)
        {
            throw new ArgumentOutOfRangeException(nameof(miejsca),
                                                 "musi byc co najmniej jedno miejsce");
        }

        if (cena < 0m)
        {
            throw new ArgumentOutOfRangeException(nameof(cena),
                                                 "cena nie moze byc ujemna");
        }

        Wydarzenie = wydarzenie.Trim();
        Cena = cena;
        Miejsca = miejsca;

        Console.WriteLine($"  [glowny] {Wydarzenie}");
    }

    public Bilet(string wydarzenie) : this(wydarzenie, 20m, 1)
    {
        Console.WriteLine("  [skrocony]");
    }

    public Bilet(Bilet inny) : this(inny.Wydarzenie, inny.Cena, inny.Miejsca)
    {
        Uwagi = inny.Uwagi;
        Console.WriteLine("  [kopiujacy]");
    }

    public void Pokaz()
    {
        Console.WriteLine($"{Wydarzenie,-16} {Cena,7:F2} zl  miejsc {Miejsca}  uwagi: {Uwagi}");
    }
}

=== tworzenie ===
  [glowny] Turniej retro
  [glowny] Noc robotow
  [skrocony]
  [glowny] Turniej retro
  [kopiujacy]

=== trzy bilety ===
Turniej retro      20,50 zl  miejsc 2  uwagi: brak
Noc robotow        20,00 zl  miejsc 1  uwagi: brak
Turniej retro      20,50 zl  miejsc 2  uwagi: duplikat dla opiekuna

=== inicjalizator obiektu ===
  [glowny] Pokaz laserow
Pokaz laserow      15,00 zl  miejsc 1  uwagi: wejscie od tylu

=== dane, ktorych konstruktor nie przyjmie ===
odrzucono: nazwa wydarzenia nie moze byc pusta (Parameter 'wydarzenie')
odrzucono parametr: miejsca

Biletow na liscie: 4

Co dzieje się po kolei

• Pierwszy blok wypisuje pięć wierszy dla trzech obiektów — bo konstruktor skrócony i kopiujący najpierw przekazują pracę głównemu przez : this(...), a dopiero potem wykonują własne ciało.
• new Bilet("Noc robotow") trafia do konstruktora z jednym parametrem, ten woła główny z ceną 20 zł i jednym miejscem — stąd wiersz [glowny] przed [skrocony].
• Kopia c ma te same dane co a, bo konstruktor kopiujący przekazał je do głównego. Zmiana c.Uwagi nie dotknęła a — to dwa osobne obiekty.
• Uwagi ma wartość "brak" u biletów a i b, bo tak ustawia inicjalizator pola. Nikt tam tej wartości nie przypisywał.
• Bilet d dostaje uwagi przez inicjalizator obiektu — klamry po new. Zwróć uwagę, że wiersz [glowny] pojawia się przed wypisaniem uwag, bo klamry wykonują się po konstruktorze.
• Pusta nazwa to " " — trzy spacje. IsNullOrWhiteSpace je wyłapuje, a IsNullOrEmpty by przepuścił (lekcja 34).
• Komunikat kończy się dopiskiem (Parameter 'wydarzenie'), którego nie ma w naszym tekście — dopisał go .NET dzięki nameof.
• Lista ma cztery pozycje, choć prób utworzenia biletu było sześć. Dwa odrzucone obiekty nigdy nie powstały — wyjątek przerwał konstruktor, więc do Add nie doszło. Tak działa obiekt, którego nie da się utworzyć z błędnymi danymi.

Zestawienie elementów

Zanim utkniesz

Zadania

Co trzeba zapamiętać

• Konstruktor nazywa się dokładnie jak klasa i nie ma typu wyniku — nawet void.
• Obiekt tworzy new; konstruktor go tylko wypełnia, dlatego nie zwraca wartości.
• Klasa bez własnego konstruktora dostaje bezparametrowy od kompilatora — i traci go przy pierwszym własnym (CS1729).
• this.pole = pole; rozróżnia pole od parametru o tej samej nazwie; bez this przypisanie nic nie robi.
• : this(...) przekazuje inicjalizację innemu konstruktorowi tej samej klasy i wykonuje się przed ciałem wywołującego.
• Jeden konstruktor główny z całą robotą, pozostałe prowadzą do niego — inaczej reguły trzeba powtarzać.
• Konstruktor jest jedyną drogą do obiektu, więc sprawdzenia postawione w nim są nie do ominięcia.
• Sprawdzenia idą przed przypisaniami i przed licznikiem — inaczej odrzucony obiekt zostawi po sobie ślad.
• nameof(parametr) wstawia nazwę parametru do komunikatu wyjątku.
• Pole dostaje wartość w trzech miejscach, zawsze w tej kolejności: inicjalizator pola, ciało konstruktora, inicjalizator obiektu.
• Klamry po new wykonują się po konstruktorze, więc omijają jego walidację; pola z regułami rób readonly.
• Konstruktor kopiujący pisze się samemu i warto przeprowadzić go przez konstruktor główny, żeby kopia też przeszła sprawdzenia.
• Finalizator ~Klasa() to odpowiednik destruktora, ale momentu jego wykonania nie da się przewidzieć — do zasobów służy Dispose() i using.

Dokumentacja: Microsoft Learn — temat tej lekcji.