Dziedziczenie w C++: klasy bazowe i pochodne

Ponowne użycie klasy przez jej rozszerzenie

Umiesz już budować klasy z konstruktorami i sprzątać po nich destruktorami. Dziedziczenie to kolejny krok: zamiast kopiować składowe jednej klasy do drugiej, deklarujesz, że nowa klasa jest wyspecjalizowaną wersją istniejącej, i pozwalasz jej wszystko automatycznie odziedziczyć.

Istniejąca klasa to klasa bazowa (albo rodzic); nowa to klasa pochodna (albo dziecko). Klasa pochodna zaczyna ze wszystkimi danymi i zachowaniem bazy, a potem dodaje lub zmienia to, co ją wyróżnia. To główne narzędzie C++ do wyrażania relacji „jest”: Dog jest Animal, SavingsAccount jest BankAccount.

Podstawowa składnia: class Derived : public Base

Dziedziczysz, pisząc po nazwie klasy pochodnej dwukropek, specyfikator dostępu i nazwę klasy bazowej. Najczęstsza forma to dziedziczenie public.

#include <iostream>
#include <string>
using namespace std;

class Animal {
public:
    string name;
    void eat() {
        cout << name << " is eating." << endl;
    }
};

// Dog jest Animal: dostaje name i eat() za darmo
class Dog : public Animal {
public:
    void bark() {
        cout << name << " says woof!" << endl;
    }
};

int main() {
    Dog d;
    d.name = "Rex";   // odziedziczone pole
    d.eat();          // odziedziczona metoda
    d.bark();         // własna metoda Dog
    return 0;
}

Dog nigdzie nie deklaruje name ani eat(), a jednak oba działają na obiekcie Dog, bo zostały odziedziczone po Animal. Klasa pochodna może swobodnie dodawać składowe takie jak bark(), o których baza nic nie wie.

protected: składowe tylko dla dzieci

Składowa private klasy bazowej nie jest dostępna w klasie pochodnej: dziedziczenie nie łamie hermetyzacji. Gdy chcesz ukryć wnętrze bazy przed światem zewnętrznym, ale udostępnić je podklasom, użyj specyfikatora dostępu protected.

#include <iostream>
using namespace std;

class BankAccount {
protected:
    double balance = 0;   // widoczne dla klas pochodnych, nie dla obcych
public:
    void deposit(double amount) { balance += amount; }
    double getBalance() const { return balance; }
};

class SavingsAccount : public BankAccount {
public:
    void addInterest(double rate) {
        balance += balance * rate;   // OK: składowa protected jest tu dostępna
    }
};

int main() {
    SavingsAccount s;
    s.deposit(1000);
    s.addInterest(0.05);
    cout << s.getBalance() << endl; // 1050
    // s.balance = 0;   // BŁĄD: protected, niedostępne z main
    return 0;
}

Wyobraź sobie te trzy poziomy jako koncentryczne pierścienie: private to „tylko ta klasa”, protected to „ta klasa i jej potomkowie”, a public to „wszyscy”. Pełny obraz znajdziesz na stronie o specyfikatorach dostępu.

Kolejność konstruktorów i destruktorów

Obiekt pochodny zawiera podobiekt bazowy, a ta część bazowa musi istnieć, zanim zostanie zbudowana część pochodna. Dlatego konstrukcja zaczyna się od bazy, a destrukcja od klasy pochodnej (dokładnie odwrotnie). Jeśli baza potrzebuje argumentów konstruktora, przekazujesz je przez listę inicjalizacyjną.

#include <iostream>
#include <string>
using namespace std;

class Animal {
    string name;
public:
    Animal(string n) : name(n) {
        cout << "Animal ctor: " << name << endl;
    }
    ~Animal() { cout << "Animal dtor: " << name << endl; }
};

class Dog : public Animal {
public:
    // przekaż argument do konstruktora bazy
    Dog(string n) : Animal(n) {
        cout << "Dog ctor" << endl;
    }
    ~Dog() { cout << "Dog dtor" << endl; }
};

int main() {
    Dog d("Rex");
    return 0;
}

Wynik pokazuje kolejność w praktyce:

Animal ctor: Rex   // najpierw budowana jest baza
Dog ctor           // potem część pochodna
Dog dtor           // niszczenie w odwrotnej kolejności...
Animal dtor: Rex   // ...baza na końcu

Jeśli zapomnisz o : Animal(n), a baza nie ma konstruktora domyślnego, kod się nie skompiluje: C++ nie wie, jak zbudować część bazową. Klasa bazowa, po której zamierzasz dziedziczyć, powinna niemal zawsze deklarować destruktor (i, jak pokaże następna strona, często wirtualny).

Nadpisywanie: ponowna definicja metody bazy

Klasa pochodna może zastąpić odziedziczoną metodę, deklarując metodę o tej samej sygnaturze. Do oryginału nadal możesz dotrzeć przez Base::method().

#include <iostream>
using namespace std;

class Shape {
public:
    void describe() const { cout << "A generic shape" << endl; }
};

class Circle : public Shape {
public:
    void describe() const {
        Shape::describe();              // jawnie wywołaj wersję z bazy
        cout << "...specifically a circle" << endl;
    }
};

int main() {
    Circle c;
    c.describe();
    return 0;
}

To zwykłe ukrywanie nazw, a nie polimorfizm: to, które describe() się wykona, rozstrzyga się podczas kompilacji na podstawie statycznego typu zmiennej. To poważne ograniczenie: jeśli wywołasz metodę przez Shape& albo Shape*, które w rzeczywistości wskazuje na Circle, i tak dostaniesz Shape::describe(). Naprawa wymaga virtual, czemu poświęcona jest następna strona.

Uwaga na object slicing

Skoro referencja lub wskaźnik do bazy może odnosić się do obiektu pochodnego, kuszące jest skopiowanie obiektu pochodnego do zmiennej typu bazowego. Nie rób tego: część pochodna zostaje odcięta.

#include <iostream>
#include <string>
using namespace std;

class Animal {
public:
    string name = "?";
};

class Dog : public Animal {
public:
    string breed = "Labrador";
};

int main() {
    Dog d;
    d.name = "Rex";

    Animal a = d;   // SLICING: kopiowana jest tylko część Animal
    cout << a.name << endl;   // Rex
    // a.breed zniknęło: nigdy nie było częścią Animal
    return 0;
}

a to prawdziwy Animal, a nie Dog z etykietą bazy, więc breed po prostu w nim nie istnieje. Aby pracować z obiektami pochodnymi polimorficznie, musisz używać referencji do bazy (Animal&) albo wskaźnika (Animal*), nigdy wartości typu bazowego. Slicing jest cichy: kompiluje się bez problemu i po cichu gubi dane, przez co łatwo przepuścić ten błąd dziedziczenia do produkcji.

Częste błędy, których warto unikać

• Oczekiwanie, że składowe private bazy będą dostępne w dziecku. Nie są. Używaj protected dla danych, których klasa pochodna naprawdę potrzebuje, a naprawdę wewnętrzny stan trzymaj jako private.
• Zapominanie o przekazaniu argumentów do konstruktora bazy. Jeśli baza nie ma konstruktora domyślnego, musisz wywołać go jawnie na liście inicjalizacyjnej konstruktora pochodnego (: Base(args)).
• Slicing obiektu pochodnego do wartości bazowej. Skopiowanie Dog do Animal gubi wszystko, co specyficzne dla Dog. Zamiast tego przekazuj i przechowuj referencje albo wskaźniki do bazy.
• Nadużywanie dziedziczenia do ponownego użycia kodu. Dziedziczenie modeluje relację „jest”. Jeśli relacja to w rzeczywistości „ma” (Car ma Engine), wybierz kompozycję, czyli obiekt składowy, zamiast dziedziczenia.

Dalej: funkcje wirtualne

Nadpisanie, które właśnie widzisz, zostało rozstrzygnięte podczas kompilacji, więc wywołanie przez wskaźnik do bazy zignorowało wersję pochodną. Następna strona, virtual-functions, wprowadza słowo kluczowe virtual i override: mechanizm, dzięki któremu o wywoływanej metodzie decyduje typ w czasie wykonania. To otwiera drogę do prawdziwego polimorfizmu i wyjaśnia, dlaczego klasy bazowe potrzebują wirtualnych destruktorów.