Dziedziczenie w C#: base, virtual, override, sealed i polimorfizm

Dziedziczenie pozwala jednej klasie budować na drugiej. Klasa pochodna dostaje składowe klasy bazowej, dodaje własne i może zastąpić zachowanie, na którego zastąpienie pozwala klasa bazowa. W połączeniu z metodami virtual daje to polimorfizm: kod napisany dla klasy bazowej uruchamia właściwe zachowanie klasy pochodnej, nie wiedząc, z którą klasą pochodną ma do czynienia.

Tworzenie klasy pochodnej

Podaj klasę bazową po dwukropku. Klasa pochodna ma wszystko, co klasa bazowa, plus to, co sama deklaruje:

using System;

class Vehicle
{
    public string Plate { get; }
    public int Km { get; private set; }

    public Vehicle(string plate) { Plate = plate; }

    public void Drive(int km) { Km += km; }
}

class Taxi : Vehicle
{
    public int Fares { get; private set; }

    public Taxi(string plate) : base(plate) { }

    public void Pickup(int km)
    {
        Drive(km);      // inherited method
        Fares++;
    }
}

class Program
{
    static void Main()
    {
        var taxi = new Taxi("TX-19");
        taxi.Pickup(12);
        taxi.Pickup(5);
        taxi.Drive(3);   // callers can use inherited members too

        Console.WriteLine($"{taxi.Plate}: {taxi.Km} km, {taxi.Fares} fares");
        Console.WriteLine(taxi is Vehicle);
    }
}

Wynik:

TX-19: 20 km, 2 fares
True

Co klasa pochodna dostaje, a czego nie:

• Dziedziczone: pola, właściwości, metody, zdarzenia i typy zagnieżdżone. Wszystko fizycznie jest w obiekcie.
• Dostępne: tylko to, na co pozwala klasa bazowa: składowe public, protected i internal. Składowa private klasy Vehicle istnieje w każdym obiekcie Taxi, ale kod Taxi nie może się do niej odwołać. Dlatego Km ma private set: Taxi może ją odczytać, a zmienia ją tylko przez Drive.
• Niedziedziczone: konstruktory. Taxi musi zadeklarować własny i połączyć go z jednym z konstruktorów Vehicle przez : base(plate). Kolejność, w jakiej się wykonują, pokazuje strona o konstruktorach.

Każda klasa ostatecznie dziedziczy po object, dlatego każdy obiekt ma ToString(), Equals() i GetHashCode().

virtual i override

Klasa bazowa oznacza metodę jako virtual, aby powiedzieć "klasy pochodne mogą dostarczyć własną wersję". Klasa pochodna zastępuje ją przez override. Wewnątrz nadpisania base.Method() wywołuje wersję z klasy bazowej.

using System;
using System.Collections.Generic;

class Notification
{
    public string To { get; }
    public Notification(string to) { To = to; }

    public virtual string Channel => "generic";

    public virtual string Render(string message) => $"[{Channel}] to {To}: {message}";
}

class Email : Notification
{
    public Email(string to) : base(to) { }
    public override string Channel => "email";

    public override string Render(string message) =>
        base.Render(message) + "\n  (unsubscribe link appended)";
}

class Sms : Notification
{
    public Sms(string to) : base(to) { }
    public override string Channel => "sms";

    // SMS messages are cut to 20 characters here to keep the demo short.
    public override string Render(string message) =>
        base.Render(message.Length > 20 ? message.Substring(0, 20).TrimEnd() + "..." : message);
}

class Program
{
    static void Main()
    {
        var outbox = new List<Notification>
        {
            new Email("lea@example.com"),
            new Sms("+351 912 000 111"),
            new Notification("ops-team"),
        };

        foreach (Notification n in outbox)
            Console.WriteLine(n.Render("Your order 1042 has shipped today"));
    }
}

Wynik:

[email] to lea@example.com: Your order 1042 has shipped today
  (unsubscribe link appended)
[sms] to +351 912 000 111: Your order 1042 has...
[generic] to ops-team: Your order 1042 has shipped today

Zmienna pętli ma typ Notification, a mimo to każdy obiekt renderuje się po swojemu. To jest polimorfizm: wywołanie n.Render(...) jest rozstrzygane w trakcie działania na podstawie faktycznego typu obiektu. Zauważ też, że base.Render w Email używa Channel, która sama jest wirtualna, więc metoda bazowa wypisuje email, a nie generic. Wirtualne wywołanie wewnątrz klasy bazowej nadal trafia do nadpisania.

Właściwości też mogą być wirtualne, co pokazuje Channel. Pola nie mogą.

Kompilator pilnuje obu słów kluczowych. Napisanie override przy metodzie, która nie jest virtual, to błąd CS0506 ("cannot override inherited member ... because it is not marked virtual, abstract, or override"). Pominięcie override, gdy metoda bazowa jest wirtualna, to tylko ostrzeżenie, ale całkowicie zmienia znaczenie, co pokazuje następna sekcja.

new a override: ukrywanie zamiast nadpisywania

Jeśli klasa pochodna deklaruje metodę o tej samej sygnaturze co metoda bazowa, ale bez override, to ukrywa metodę bazową. Kompilator ostrzega (CS0114 dla wirtualnej metody bazowej, w pozostałych przypadkach CS0108) i sugeruje słowo kluczowe new, które wycisza ostrzeżenie, ale zachowuje ukrywanie:

using System;

class Report
{
    public virtual string Title() => "Report";
}

class SalesReport : Report
{
    public override string Title() => "Sales report";
}

class DraftReport : Report
{
    public new string Title() => "Draft report";
}

class Program
{
    static void Main()
    {
        Report a = new SalesReport();
        Report b = new DraftReport();
        DraftReport c = new DraftReport();

        Console.WriteLine(a.Title());
        Console.WriteLine(b.Title());
        Console.WriteLine(c.Title());
    }
}

Wynik:

Sales report
Report
Draft report

b i c to obiekty tego samego rodzaju, a jednak wypisują różne tytuły. Przy new wybór metody zależy od typu zmiennej i zapada w czasie kompilacji. Kod, który traktuje raporty jako Report (lista, parametr metody, callback frameworka), nigdy nie zobaczy DraftReport.Title. Prawie nigdy nie o to chodzi. Do polimorfizmu używaj override; new istnieje głównie na wypadek, gdy klasa bazowa, której nie kontrolujesz, doda składową o nazwie kolidującej z twoją.

sealed

sealed przy klasie zabrania dziedziczenia po niej:

sealed class Invoice { }
class CorrectedInvoice : Invoice { }
// error CS0509: 'CorrectedInvoice': cannot derive from sealed type 'Invoice'

string jest sealed, podobnie jak wiele typów frameworka. Przy nadpisaniu sealed zatrzymuje łańcuch na tym poziomie:

class Shape { public virtual string Name() => "shape"; }
class Square : Shape { public sealed override string Name() => "square"; }
class Tile : Square { public override string Name() => "tile"; }
// error CS0239: 'Tile.Name()': cannot override inherited member 'Square.Name()' because it is sealed

Zaprojektowanie klasy pod dziedziczenie wymaga pracy: trzeba zdecydować, co jest wirtualne, na czym klasy pochodne mogą polegać i w jakiej kolejności dzieją się rzeczy. Klasa, której tak nie projektowano, jest bezpieczniejsza jako sealed, a zapieczętowanie można później cofnąć bez psucia czyjegokolwiek kodu, natomiast odpieczętowania nie da się wycofać, gdy inni już dziedziczą po twojej klasie. Wywołania składowych klas sealed mogą też być nieco szybsze, bo środowisko uruchomieniowe wie, że nie istnieje żadne nadpisanie.

Jedna klasa bazowa, wiele interfejsów

Klasa w C# ma dokładnie jedną klasę bazową. class Admin : User, Employee to błąd CS1721 ("cannot have multiple base classes"). Klasa może jednak obok klasy bazowej implementować dowolną liczbę interfejsów:

class Admin : User, IAuditable, IComparable<Admin>
{
    // base class first, then interfaces, in any order
}

Używaj klasy bazowej dla relacji "jest rodzajem czegoś i współdzieli z tym implementację", a interfejsów dla "potrafi". Gdy klasa bazowa istnieje tylko po to, by zmusić klasy pochodne do uzupełnienia niektórych metod, właściwym narzędziem jest klasa abstrakcyjna.

Rzutowanie w górę i w dół hierarchii

Obiektu pochodnego zawsze można użyć tam, gdzie oczekiwany jest jego typ bazowy. Takie rzutowanie w górę jest niejawne i nie może się nie udać. Kierunek odwrotny, rzutowanie w dół, wymaga jawnego rzutowania i kończy się błędem w trakcie działania, jeśli obiekt nie jest tego typu:

using System;

class Animal { public string Name; }
class Dog : Animal { public void Fetch() => Console.WriteLine($"{Name} fetches the ball"); }
class Cat : Animal { }

class Program
{
    static void Main()
    {
        Animal pet = new Dog { Name = "Rex" };   // upcast: implicit
        Animal other = new Cat { Name = "Tom" };

        Dog d = (Dog)pet;                        // downcast: explicit, succeeds
        d.Fetch();

        try
        {
            Dog wrong = (Dog)other;              // the object is a Cat
        }
        catch (InvalidCastException)
        {
            Console.WriteLine("InvalidCastException: Tom is not a Dog");
        }

        Dog maybe = other as Dog;                // as: null instead of an exception
        Console.WriteLine(maybe == null);

        if (pet is Dog dog)                      // is: test and cast in one step
            dog.Fetch();
    }
}

Wynik:

Rex fetches the ball
InvalidCastException: Tom is not a Dog
True
Rex fetches the ball

Napisanie Dog d = pet; bez rzutowania to błąd kompilacji (CS0266: "An explicit conversion exists (are you missing a cast?)"), bo kompilator wie tylko, że pet to jakieś Animal. Wybieraj is ze zmienną, gdy obiekt może być innego typu, a zwykłe rzutowanie tylko wtedy, gdy każda inna możliwość byłaby błędem. Częste rzutowanie w dół to sygnał problemu w projekcie: zwykle oznacza, że zachowanie powinno być metodą wirtualną w klasie bazowej. Wszystkie formy is omawia strona o dopasowywaniu wzorców.

Dziedziczenie a kolekcje

Polimorfizm działa element po elemencie, ale generyczne kolekcje typu pochodnego nie są kolekcjami typu bazowego: List<Animal> animals = new List<Dog>(); się nie kompiluje, bo lista przyjmowałaby wtedy Cat. Widoki tylko do odczytu są kowariantne, więc IEnumerable<Animal> animals = new List<Dog>(); jest w porządku. Dlaczego, wyjaśnia strona o typach generycznych.

Typowe błędy

• Zapomniane override. Metoda kompiluje się z ostrzeżeniem i po cichu ukrywa zamiast nadpisywać. Traktuj CS0114 jak błąd.
• Robienie wszystkiego virtual. Każda wirtualna składowa to obietnica dla klas pochodnych, kiedy jest wywoływana i co może zakładać. Oznaczaj tylko te punkty rozszerzeń, które naprawdę planujesz.
• Głębokie hierarchie. Trzy lub cztery poziomy dziedziczenia utrudniają ustalenie, która wersja metody się wykona. Kompozycja, czyli klasa trzymająca inny obiekt i wywołująca go, jest często prostsza niż kolejny poziom.
• Wywoływanie metod wirtualnych z konstruktora. Nadpisanie wykonuje się przed ciałem konstruktora klasy pochodnej, więc każde pole przypisywane w tym ciele ma jeszcze wartość domyślną.
• Dziedziczenie tylko po to, by ponownie użyć kodu. Jeśli Stack dziedziczy po List, kod wywołujący może wykonać Insert w środek twojego stosu. Zamiast tego trzymaj List w prywatnym polu.