Odpowiedź.

Historia pytania:

Polimorfizm stał się jednym z kluczowych cech programowania obiektowego już na wczesnym etapie rozwoju C++. Celem jest możliwość odwoływania się do obiektów przez interfejs bazowy, nie troszcząc się o konkretny typ. Znacznie to rozszerza wyrazistość i elastyczność kodu.

Problem:

Bez polimorfizmu kod staje się nieelastyczny: trzeba wyraźnie rozpoznawać typy obiektów, używać switch/case, ręcznie przeprowadzać rzutowania typów. Utrudnia to wsparcie i rozszerzalność aplikacji — dodawanie nowych typów staje się kosztowne lub niemożliwe bez zmiany istniejącego kodu.

Rozwiązanie:

W C++ polimorfizm osiągany jest przez użycie funkcji wirtualnych. Klasy deklarują metody wirtualne, a dziedziczący je realizują. Klasa bazowa zapewnia wspólny interfejs, a rzeczywiste działania zależą od faktycznego typu obiektu, na który wskazuje wskaźnik lub referencja.

Przykład kodu:

#include <iostream>

class Animal {
public:
    virtual void speak() const { std::cout << "Niektóre odgłosy zwierząt
"; }
    virtual ~Animal() {}
};

class Dog : public Animal {
public:
    void speak() const override { std::cout << "Hau!
"; }
};

void makeSound(const Animal& a) {
    a.speak();
}

int main() {
    Dog dog;
    makeSound(dog); // Wyjście: Hau!
}

Kluczowe cechy:

• Funkcje wirtualne muszą być zadeklarowane z kluczowym słowem virtual w klasie bazowej.
• Dla bezpieczeństwa używaj wirtualnego destruktora w hierarchii polimorficznej.
• Aby wyraźnie nadpisać, używaj override — to zwiększa bezpieczeństwo kodu.

Pytania z podstępem.

Co się stanie, jeśli nie zadeklarujemy destruktora klasy bazowej jako wirtualnego?

Usunięcie obiektu przez wskaźnik do klasy bazowej wywoła tylko destruktor klasy bazowej, a destruktor klasy pochodnej nie zostanie wywołany, co doprowadzi do wycieku zasobów.

Przykład kodu:

class Base { public: ~Base() { /*...*/ } };
class Derived : public Base { public: ~Derived() { /*...*/ } };
Base* obj = new Derived();
delete obj; // UB: Derived::~Derived nie zostanie wywołany

Czy można zadeklarować tylko częściowo wirtualne metody, a destruktor pozostawić niewirtualnym?

Nie, jeśli klasa jest polimorficzna (ma co najmniej jedną funkcję wirtualną), destruktor musi być wirtualny, aby uniknąć wycieków pamięci lub zasobów.

Czy funkcje wirtualne działają dla członków zadeklarowanych jako static?

Nie, statyczne człony klasy nie mogą być wirtualne, ponieważ nie należą do konkretnego obiektu i nie istnieje dla nich mechanizm dynamicznego powiązania.

Typowe błędy i antywzorce.

• Brak wirtualnego destruktora w hierarchii z metodami wirtualnymi.
• Zapomniano oznaczyć metodę override w klasie pochodnej, co prowadzi do błędnego nadpisania metody.
• Wywołania funkcji wirtualnych w konstruktorach/destruktorach, gdy nie powinno być dynamicznego powiązania.

Przykład z życia.

Negatywny przypadek.

Bardzo duża hierarchia klas urządzeń, każda klasa pochodna zarządza swoim zasobem (np. otwartym plikiem), ale destruktor klasy bazowej nie jest wirtualny. Przy usuwaniu przez wskaźnik do bazy zasoby nie są zwalniane.

Zalety: Projekt buduje się szybko, minimum wywołań wirtualnych.

Wady: Wyciek pamięci, nieprawidłowe niszczenie. Ekstremalnie trudne w utrzymaniu i rozbudowie.

Pozytywny przypadek.

Przemyślana hierarchia polimorficzna, klasa bazowa ma funkcje wirtualne i wirtualny destruktor. Używane jest kluczowe słowo override i zasady RAII.

Zalety: Bezpieczna praca z zasobami, łatwe rozszerzenie, testowalność.

Wady: Nieco niższa wydajność z powodu vtable-lookup, szczepionka na "over-engineering" gdy dziedziczenie jest stosowane bez potrzeby.