Funkcje wirtualne w C++: polimorfizm w praktyce

Dlaczego samo dziedziczenie nie wystarcza

Na poprzedniej stronie powstaje hierarchia klas: klasa pochodna dziedziczy składowe po klasie bazowej. Jest jednak haczyk. Gdy wywołujesz metodę przez wskaźnik na klasę bazową, C++ decyduje, którą funkcję uruchomić, na podstawie typu wskaźnika, a nie rzeczywistego typu obiektu. Dlatego Animal*, który w rzeczywistości wskazuje na Dog, nadal wywołuje wersję metody z Animal.

Prawie nigdy nie o to chodzi. Najczęściej masz kolekcję wskaźników na klasę bazową, z których każdy wskazuje na inny obiekt pochodny, i chcesz, by każdy zachowywał się zgodnie ze swoim typem. Umożliwiają to funkcje wirtualne.

#include <iostream>
using namespace std;

struct Animal {
    void speak() { cout << "...\n"; }   // NIE jest wirtualna
};

struct Dog : Animal {
    void speak() { cout << "Woof\n"; }
};

int main() {
    Animal* a = new Dog();
    a->speak();   // wypisuje "...": wersję z Animal, a nie Woof!
    delete a;
    return 0;
}

Obiekt naprawdę jest typu Dog, a mimo to a->speak() uruchomiło Animal::speak(). Ponieważ speak nie jest wirtualna, kompilator wybrał funkcję w czasie kompilacji na podstawie typu statycznego Animal*. To właśnie ten błąd naprawiają funkcje wirtualne.

Jak uczynić funkcję wirtualną

Dodaj słowo kluczowe virtual do metody w klasie bazowej. Teraz wywołanie jest rozstrzygane w czasie działania programu na podstawie rzeczywistego typu obiektu: to dynamiczne wiązanie (dynamic dispatch).

#include <iostream>
using namespace std;

struct Animal {
    virtual void speak() { cout << "...\n"; }
};

struct Dog : Animal {
    void speak() override { cout << "Woof\n"; }
};

struct Cat : Animal {
    void speak() override { cout << "Meow\n"; }
};

int main() {
    Animal* pets[] = { new Dog(), new Cat(), new Animal() };

    for (Animal* p : pets) {
        p->speak();   // każdy uruchamia własną wersję
    }
    // Woof / Meow / ...

    for (Animal* p : pets) delete p;
    return 0;
}

Jedna pętla po Animal*, trzy różne zachowania. Bazowy wskaźnik "zna" rzeczywisty typ w czasie działania programu i odpowiednio kieruje wywołanie. Ten jeden mechanizm, czyli jeden interfejs i wiele implementacji, to właśnie polimorfizm w C++.

Zauważ, że virtual musi się pojawić tylko w deklaracji bazowej: gdy funkcja jest już wirtualna, automatycznie pozostaje wirtualna w każdej klasie pochodnej. Powtórzenie tego słowa w klasie pochodnej jest opcjonalne i zbędne.

Zawsze używaj słowa kluczowego override

W powyższym przykładzie każda metoda pochodna jest oznaczona jako override. Kod zadziała i bez tego, ale traktuj to oznaczenie jako obowiązkowe. override (C++11) prosi kompilator o sprawdzenie, czy naprawdę nadpisujesz wirtualną funkcję bazową o pasującej sygnaturze. Jeśli subtelnie pomylisz sygnaturę, dostaniesz wyraźny błąd zamiast cichego błędu w działaniu.

struct Animal {
    virtual void speak() const { }   // uwaga: const
};

struct Dog : Animal {
    void speak() { }            // NIE jest const: to NOWA funkcja, a nie nadpisanie!
    void speak() override { }   // błąd: 'speak' niczego nie nadpisuje, dowiadujesz się od razu
};

Bez override pierwsze speak() kompiluje się bez problemu, ale nigdy nie zostanie wywołane przez Animal*, bo jego sygnatura różni się od bazowej (brakuje const). Można by stracić całe popołudnie na zastanawianiu się, dlaczego nadpisana metoda nic nie robi. Z override kompilator wyłapuje niezgodność na miejscu. Dodawaj je do każdej nadpisującej funkcji.

Funkcje czysto wirtualne i klasy abstrakcyjne

Czasem klasa bazowa nie ma sensownego zachowania domyślnego: jaki dźwięk wydaje ogólne "zwierzę"? Wtedy zadeklaruj funkcję jako czysto wirtualną, przypisując = 0. Nie ma ona ciała, a klasa staje się klasą abstrakcyjną, której instancji nie da się utworzyć. Istnieje tylko po to, by zdefiniować interfejs, który klasy pochodne muszą zrealizować.

#include <iostream>
using namespace std;

struct Shape {
    virtual double area() const = 0;   // czysto wirtualna: bez ciała, musi zostać nadpisana
    virtual ~Shape() = default;        // wirtualny destruktor (patrz następna sekcja)
};

struct Circle : Shape {
    double r;
    Circle(double radius) : r(radius) {}
    double area() const override { return 3.14159 * r * r; }
};

struct Rectangle : Shape {
    double w, h;
    Rectangle(double width, double height) : w(width), h(height) {}
    double area() const override { return w * h; }
};

int main() {
    // Shape s;   // błąd: nie można utworzyć instancji klasy abstrakcyjnej
    Shape* shapes[] = { new Circle(2.0), new Rectangle(3.0, 4.0) };

    for (Shape* s : shapes) {
        cout << "area = " << s->area() << "\n";
    }
    // area = 12.5664 / area = 12

    for (Shape* s : shapes) delete s;
    return 0;
}

Każda konkretna podklasa musi zaimplementować area(), inaczej również pozostanie abstrakcyjna. Tak C++ wyraża "interfejsy": klasa abstrakcyjna zawierająca wyłącznie funkcje czysto wirtualne to odpowiednik interfejsu z języków takich jak Java.

Zasada wirtualnego destruktora

Na tej pułapce każdy potyka się przynajmniej raz. Gdy usuwasz obiekt przez delete za pomocą wskaźnika na klasę bazową, C++ wywołuje destruktor, który znajdzie, a jeśli ten destruktor nie jest wirtualny, uruchamia się tylko destruktor bazowy. Część pochodna nigdy nie zostaje zniszczona, a wszystko, co posiadała, wycieka. Standard nazywa to niezdefiniowanym zachowaniem.

#include <iostream>
using namespace std;

struct Base {
    ~Base() { cout << "~Base\n"; }   // NIE jest wirtualny: błąd!
};

struct Derived : Base {
    ~Derived() { cout << "~Derived\n"; }
};

int main() {
    Base* p = new Derived();
    delete p;   // wypisuje tylko "~Base": ~Derived nigdy się nie uruchamia!
    return 0;
}

Poprawka to jedno słowo: oznacz destruktor bazowy jako virtual. Wtedy delete p uruchamia najpierw ~Derived, a potem ~Base, dokładnie tak, jak powinno.

struct Base {
    virtual ~Base() { cout << "~Base\n"; }   // poprawnie
};
// teraz: najpierw ~Derived, potem ~Base

Praktyczna zasada: gdy tylko klasa ma jakąkolwiek funkcję wirtualną, daj jej też wirtualny destruktor. Jeśli klasa ma być klasą bazową używaną przez wskaźniki, jej destruktor musi być wirtualny.

Częste błędy i pułapki

Kilka kolejnych pułapek, na które warto uważać, gdy funkcje wirtualne nie są już dla ciebie nowością:

Przycinanie obiektów (object slicing). Jeśli przekazujesz lub zapisujesz obiekt pochodny przez wartość w zmiennej bazowej, część pochodna zostaje "odcięta" i zostaje zwykły obiekt bazowy: dynamiczne wiązanie nie dociera już do nadpisanej wersji. Do polimorfizmu zawsze używaj wskaźników albo referencji:

Dog d;
Animal a = d;   // PRZYCIĘTE: a jest teraz tylko Animal, część Dog zniknęła
a.speak();      // uruchamia Animal::speak, mimo że jest wirtualna

Animal& ref = d;   // OK: referencja zachowuje rzeczywisty typ
ref.speak();       // uruchamia Dog::speak

Nie wywołuj funkcji wirtualnych z konstruktorów ani destruktorów. Podczas konstrukcji część pochodna jeszcze nie istnieje, więc wywołanie wirtualne trafia do wersji z bieżącej klasy, a nie do nadpisania w klasie pochodnej. Rzadko o to chodzi.

Dynamiczne wiązanie ma niewielki koszt. Każde wywołanie wirtualne przechodzi przez ukrytą tablicę wskaźników do funkcji ("vtable"), czyli jedno dodatkowe pośrednie odwołanie na wywołanie. To tanie, ale nie darmowe, więc nie oznaczaj funkcji jako wirtualnej, jeśli naprawdę nie potrzebujesz nadpisywania.

Celowe wywołanie wersji bazowej. Wewnątrz nadpisanej metody nadal możesz jawnie wywołać implementację bazową przez Base::method(). Przydaje się to, gdy zachowanie pochodne rozszerza bazowe, zamiast je zastępować.

Dalej: przeciążanie operatorów

Funkcje wirtualne pozwalają obiektom dostosować swoje zachowanie za pomocą wspólnego interfejsu. Następna strona pokazuje, jak dostosować operatory działające na twoich obiektach: dzięki przeciążaniu operatorów możesz nauczyć własne typy reagować na +, ==, << i inne, tak by Vector + Vector albo cout << myObject czytały się równie naturalnie jak przy typach wbudowanych.