BAZA WIEDZY
KURSY
Bazy danych w PHP
Kurs AdvancedAJAX
Kurs ASP
Kurs ASP.NET
Kurs C++
Kurs CSS
Kurs HTML
Kurs HTML drugi
Kurs JavaScript
Kurs MySQL
Kurs PHP
Kurs RSS
Kurs XHTML
Obiekty DOM
MANUALE
CSS1 - W3C
DOM - w budowie
PHP 2005
PHP 2006
Wyrażenia regularne
SHOUTBOX
STAT
Online: 5 | UU: 208

Dziedziczenie

Drugim powodem, dla którego techniki obiektowe zyskały taką popularność 1 , jest znaczący postęp w kwestii ponownego wykorzystywania raz napisanego kodu oraz rozszerzania i dostosywania go do własnych potrzeb.

Cecha ta leży u samych podstaw OOPu: program konstruowany jako zbiór współdziałających obiektów nie jest już bowiem monolitem, ścisłym połączeniem danych i wykonywanych nań operacji. "Rozdrobniona" struktura zapewnia mu zatem modularność : nie jest trudno dodać do gotowej aplikacji nową funkcję czy też wyodrębnić z niej jeden podsystem i użyć go w kolejnej produkcji. Ułatwia to i przyspiesza realizację kolejnych projektów.

Wszystko zależy jednak od umiejętności i doświadczenia programisty. Nawet stosując techniki obiektowe można stworzyć program, którego elementy będą ze sobą tak ściśle zespolone, że próba ich użycia w następnej aplikacji będzie przypominała wciskanie słonia do szklanej butelki.

Istnieje jeszcze jedna przyczyna, dla której kod oparty na programowaniu obiektowym łatwiej poddaje się "recyklingowi", mającemu przygotować go do ponownego użycia. Jest nim właśnie tytułowy mechanizm dziedziczenia.

Korzyści płynące z jego stosowania nie ograniczają się jednakże tylko do wtórnego "przerobu" już istniejącego kodu. Przeciwnie, jest to fundamentalny aspekt OOPu niezmiernie ułatwiający i uprzyjemniający projektowanie każdej w zasadzie aplikacji. W połączeniu z technologią funkcji wirtualnych oraz polimorfizmu daje on niezwykle szerokie możliwości, o których szczegółowo traktuje praktycznie cały niniejszy rozdział.

Rozpoczniemy zatem od dokładnego opisu tego bardzo pożytecznego mechanizmu programistycznego.

O powstawaniu klas drogą doboru naturalnego

Człowiek jest taką dziwną istotą, która bardzo lubi posiadać uporządkowany i usystematyzowany obraz świata. Wprowadzanie porządku i pewnej hierarchii co do postrzeganych zjawisk i przedmiotów jest dla nas niemal naturalną potrzebą.

Chyba najlepiej przejawia się to w klasyfikacji biologicznej. Widząc na przykład psa wiemy przecież, że nie tylko należy on do gatunku zwanego psem domowym, lecz także do gromady znanej jako ssaki (wraz z końmi, słoniami, lwami, małpami, ludźmi i całą resztą tej menażerii). Te z kolei, razem z gadami, ptakami czy rybami należą do kolejnej, znacznie większej grupy organizmów zwanych po prostu zwierzętami.

Nasz pies jest zatem jednocześnie psem domowym, ssakiem i zwierzęciem:


Schemat 22. Klasyfikacja zwierząt jako przykład hierarchii typów obiektów

Gdyby był obiektem w programie, wtedy musiałby należeć aż do trzech klas naraz 2 ! Byłoby to oczywiście niemożliwe, jeżeli wszystkie miałyby być wobec siebie równorzędne. Tutaj jednak tak nie jest: występuje między nimi hierarchia, jedna klasa pochodzi od drugiej. Zjawisko to nazywamy właśnie dziedziczeniem .

Dziedziczenie (ang. inheritance ) to tworzenie nowej klasy na podstawie jednej lub kilku istniejących wcześniej klas bazowych.

Wszystkie klasy, które powstają w ten sposób (nazywamy je pochodnymi ), posiadają pewne elementy wspólne. Części te są dziedziczone z klas bazowych, gdyż tam właśnie zostały zdefiniowane.

Ich zbiór może jednak zostać poszerzony o pola i metody specyficzne dla klas pochodnych. Będą one wtedy współistnieć z "dorobkiem" pochodzącym od klas bazowych, ale mogą oferować dodatkową funkcjonalność.

Tak w teorii wygląda system dziedziczenia w programowaniu obiektowym. Najlepiej będzie, jeżeli teraz przyjrzymy się, jak w praktyce może wyglądać jego zastosowanie.

Od prostoty do komplikacji, czyli ewolucja

Powróćmy więc do naszego przykładu ze zwierzętami. Chcąc stworzyć programowy odpowiednik zaproponowanej hierarchii, musielibyśmy zdefiniować najpierw odpowiednie klasy bazowe . Następnie odziedziczylibyśmy ich pola i metody w klasach pochodnych i dodali nowe, właściwe tylko im. Powstałe klasy same mogłyby być potem bazami dla kolejnych, jeszcze bardziej wyspecjalizowanych typów.

Idąc dalej tą drogą dotarlibyśmy wreszcie do takich klas, z których sensowne byłoby już tworzenie normalnych obiektów.

Pojęcie klas bazowych i klas pochodnych jest zatem względne : dana klasa może wprawdzie pochodzić od innych, ale jednocześnie być bazą dla kolejnych klas. W ten sposób ustala się wielopoziomowa hierarchia, podobna zwykle do drzewka.

Ilustracją tego procesu może być poniższy diagram:

Schemat 23. Hierarchia klas zwierząt

Wszystkie przedstawione na nim klasy wywodzą się z jednej, nadrzędnej wobec wszystkich: jest nią naturalnie klasa Zwierzę . Dziedziczy z niej każda z pozostałych klas - bezpośrednio , jak Ryba , Ssak oraz Ptak , lub pośrednio - jak Pies domowy .

Tak oto tworzy się kilkupoziomowa klasyfikacja oparta na mechanizmie dziedziczenia.

Z klasy bazowej do pochodnej, czyli dziedzictwo przodków

O podstawowej konsekwencji takiego rozwiązania zdążyłem już wcześniej wspomnieć. Jest nią mianowicie przekazywanie pól oraz metod pochodzących z klasy bazowej do wszystkich klas pochodnych, które się z niej wywodzą. Zatem:

Klasa pochodna zawiera pola i metody odziedziczone po klasach bazowych. Może także posiadać dodatkowe, unikalne dla siebie składowe - nie jest to jednak obowiązkiem.

Prześledźmy teraz sposób, w jaki odbywa się odziedziczanie składowych na przykładzie naszej prostej hierarchii klas zwierząt.

U jej podstawy leży "najbardziej bazowa" klasa Zwierzę . Zawiera ona dwa pola, określające masę i wiek zwierzęcia, oraz metody odpowiadające za takie czynności jak widzenie i oddychanie. Składowe te mogły zostać umieszczone tutaj, gdyż dotyczą one wszystkich interesujących nas zwierząt i będą miały sens w każdej z klas pochodnych.

Tymi klasami, bezpośrednio dziedziczącymi od klasy Zwierzę , są Ryba , Ssak oraz Ptak . Każda z nich niejako "z miejsca" otrzymuje zestaw pól i metod, którymi legitymowało się bazowe Zwierzę . Klasy te wprowadzają jednak także dodatkowe, własne metody: i tak Ryba może pływać, Ssak biegać 3 , zaś Ptak latać. Nie ma w tym nic dziwnego, nieprawdaż? :)

Wreszcie, z klasy Ssak dziedziczy najbardziej interesująca nas klasa, czyli Pies domowy . Przejmuje ona wszystkie pola i metody z klasy Ssak , a więc pośrednio także z klasy Zwierzę . Uzupełnia je przy tym o kolejne składowe, właściwe tylko sobie.

Ostatecznie więc klasa Pies domowy zawiera znacznie więcej pól i metod niż mogłoby się z początku wydawać:

Schemat 24. Składowe klasy Pies domowy

Wykazuje poza tym pewną budowę wewnętrzną: niektóre jej pola i metody możemy bowiem określić jako własne i unikalne, zaś inne są odziedziczone po klasie bazowej i mogą być wspólne dla wielu klas. Nie sprawia to jednak żadnej różnicy w korzystaniu z nich: funkcjonują one identycznie, jakby były zawarte bezpośrednio wewnątrz klasy.


1 Pierwszym jest wspominana nie raz "naturalność" programowania, bez konieczności podziału na dane i kod.

2 A raczej do siedmiu lub ośmiu, gdyż dla prostoty pominąłem tu większość poziomów systematyki.

3 Delfiny muszą mi wybaczyć nieuwzględnienie ich w tym przykładzie :D

Obiekt o kilku klasach, czyli zmienność gatunkowa

Oczywiście klas nie definiuje się dla samej przyjemności ich definiowania, lecz dla tworzenia z nich obiektów. Jeżeli więc posiadalibyśmy przedstawioną wyżej hierarchię w jakimś prawdziwym programie, to z pewnością pojawiłyby się w nim także instancje zaprezentowanych klas, czyli odpowiednie obiekty.

W ten sposób wracamy do problemu postawionego na samym początku: jak obiekt może należeć do kilku klas naraz? Różnica polega wszak na tym, że mamy już jego gotowe rozwiązanie :) Otóż nasz obiekt psa należałby przede wszystkim do klasy Pies domowy ; to właśnie tej nazwy użylibyśmy, by zadeklarować reprezentującą go zmienną czy też pokazujący nań wskaźnik. Jednocześnie jednak byłby on typu Ssak oraz typu Zwierzę , i mógłby występować w tych miejscach programu, w których byłby wymagany jeden z owych typów.

Fakt ten jest przyczyną istnienia w programowaniu obiektowym zjawiska zwanego polimorfizmem. Poznamy je dokładnie jeszcze w tym rozdziale.

Dziedziczenie w C++

Pozyskawszy ogólne informacje o dziedziczeniu jako takim, możemy zobaczyć, jak idea ta została przełożona na nasz nieoceniony język C++ :) Dowiemy się więc, w jaki sposób definiujemy nowe klasy w oparciu o już istniejące oraz jakie dodatkowe efekty są z tym związane.

Podstawy

Mechanizm dziedziczenia jest w C++ bardzo rozbudowany, o wiele bardziej niż w większości pozostalych języków zorientowanych obiektowo 1 . Udostępnia on kilka szczególnych możliwości, które być może nie są zawsze niezbędne, ale pozwalają na dużą swobodę w definiowaniu hierarchii klas. Poznanie ich wszystkich nie jest konieczne, aby sprawnie korzystać z dobrodziejstw programowania obiektowego, jednak wiemy doskonale, że wiedza jeszcze nikomu nie zaszkodziła :D

Zaczniemy oczywiście od najbardziej elementarnych zasad dziedziczenia klas oraz przyjrzymy się przykładom ilustrującym ich wykorzystanie.

Definicja klasy bazowej i specyfikator protected

Jak pamiętamy, definicja klasy składa się przede wszystkim z listy deklaracji jej pól oraz metod, podzielonych na kilka części wedle specyfikatorów praw dostępu. Najczęściej każdy z tych specyfikatorów występuje co najwyżej w jednym egzemplarzu, przez co składnia definicji klasy wygląda następująco:

class nazwa_klasy
{
[ private : ]
[ deklaracje_prywatne ]
[ protected : ]
[ deklaracje_chronione ]
[ public : ]
[ deklaracje_publiczne ]
};

Nieprzypadkowo pojawił się tu nowy specyfikator, protected . Jego wprowadzenie związane jest ściśle z pojęciem dziedziczenia. Pojęcie to wpływa zresztą na dwa pozostałe rodzaje praw dostępu do składowych klasy.

Zbierzmy więc je wszystkie w jednym miejscu, wyjaśniając definitywnie znaczenie każdej z etykiet:

  • private : poprzedza deklaracje składowych, które mają być dostępne jedynie dla metod definiowanej klasy. Oznacza to, iż nie można się do nich dostać, używając obiektu lub wskaźnika na niego oraz operatorów wyłuskania . lub -> .
    Ta wyłączność znaczy również, że prywatne składowe nie są dziedziczone i nie ma do nich dostępu w klasach pochodnych, gdyż nie wchodzą w ich skład.

  • specyfikator protected ("chronione") także nie pozwala, by użytkownicy obiektów naszej klasy "grzebali" w opatrzonych nimi polach i metodach. Jak sama nazwa wskazuje, są one chronione przed takim dostępem z zewnątrz.
    Jednak w przeciwieństwie do deklaracji private , składowe zaznaczone przez protected są dziedziczone i występują w klasach pochodnych, będąc dostępnymi dla ich własnych metod.

Pamiętajmy zatem, że zarówno private , jak i protected nie pozwala , aby oznaczone nimi składowe klasy były dostępne na zewnątrz . Ten drugi specyfikator zezwala jednak na dziedziczenie pól i metod.

 

  • public jest najbardziej liberalnym specyfikatorem. Nie tylko pozwala na odziedziczanie swych składowych, ale także na udostępnianie ich szerokiej rzeszy obiektów poprzez operatory wyłuskania.

Powyższe opisy brzmią może nieco sucho i niestrawnie, dlatego przyjrzymy się jakiemuś przykładowi, który będzie bardziej przemawiał do wyobraźni. Mamy więc taką oto klasę prostokąta:

class CRectangle
{
private :
// wymiary prostokąta
float m_fSzerokosc, m_fWysokosc;
protected :
// pozycja na ekranie
float m_fX, m_fY;
public :
// konstruktor
CRectangle() { m_fX = m_fY = 0.0 ;
m_fSzerokosc = m_fWysokosc = 10.0 ; }
//
// metody

float Pole() const { return m_fSzerokosc * m_fWysokosc; }
float Obwod() const { return 2 * (m_fSzerokosc+m_fWysokosc); }
};

Opisują go cztery liczby, wyznaczające jego pozycję oraz wymiary. Współrzędne X oraz Y uczyniłem tutaj polami chronionymi, zaś szerokość oraz wysokość - prywatnymi. Dlaczego właśnie tak?.

Otóż powyższa klasa będzie również bazą dla następnej. Pamiętamy z geometrii, że szczególnym rodzajem prostokąta jest kwadrat. Ma on wszystkie boki o tej samej długości, zatem nielogiczne jest stosowań do nich pojęcia szerokości i wysokości. Wielkość kwadratu określa bowiem tylko jedna liczba, więc defincja odpowiadającej mu klasy może wyglądać następująco:

class CSquare : public CRectangle // dziedziczenie z CRectangle
{
private :
// zamiast szerokości i wysokości mamy tylko długość boku
float m_fDlugoscBoku;
// pola m_fX i m_fY są dziedziczone z klasy bazowej, więc nie ma
// potrzeby ich powtórnego deklarowania
public :
// konstruktor
CSquare { m_fDlugoscBoku = 10.0 ; }
//
// nowe metody

float Pole() const { return m_fDlugoscBoku * m_fDlugoscBoku; }
float Obwod() const { return 4 * m_fDlugoscBoku; }
};

Dziedziczy ona z CRectangle , co zostało zaznaczone w pierwszej linijce, ale postać tej frazy chwilowo nas nie interesuje :) Skoncentrujmy się raczej na konsekwencjach owego dziedziczenia.

Porozmawiajmy najpierw o nieobecnych. Pola m_fSzerokosc oraz m_fWysokosc były w klasie bazowej oznaczone jako prywatne, zatem ich zasięg ogranicza się jedynie do tej klasy. W pochodnej CSquare nie ma już po nich śladu; zamiast tego pojawia się bardziej naturalne pole m_fDlugoscBoku z sensowną dla kwadratu wielkością.

Związane są z nią także dwie nowe-stare metody, zastępujące te z CRectangle . Do obliczania pola i obwodu wykorzystujemy bowiem samą długość boku kwadratu, nie zaś "jego" szerokośc i wysokość, których w klasie w ogóle nie ma.

W definicji CSquare nie ma także deklaracji m_fX oraz m_f Y. Nie znaczy to jednak, że klasa tych pól nie posiada, gdyż zostały one po prostu odziedziczone z bazowej CRectangle . Stało się tak oczywiście za sprawą specyfikatora protected .

Co więc powinniśmy o nim pamiętać? Otóż:

Należy używać specyfikatora protected , kiedy chcemy uchronić składowe przed dostępem z zewnątrz, ale jednocześnie mieć je do dyspozycji w klasach pochodnych.

Definicja klasy pochodnej

Dopiero posiadając zdefiniowaną klasę bazową możemy przystąpić do określania dziedziczącej z niej klasy pochodnej. Jest to konieczne, bo w przeciwnym wypadku kazalibyśmy kompilatorowi korzystać z czegoś, o czym nie miałby wystarczających informacji.

Składnię definicji klasy pochodnej możemy poglądowo przedstawić w ten sposób:

class nazwa_klasy [ : [ specyfikatory ] [ nazwa_klasy_bazowej ] [ , ... ]]
{
deklaracje_składowych
};

Ponieważ z sekwencją deklaracji_składowych spotkaliśmy się już nie raz i nie dwa razy, skupimy się jedynie na pierwszej linijce podanego schematu.

To w niej właśnie podajemy klasy bazowe, z których chcemy dziedziczyć. Czynimy to, wpisując dwukropek po nazwie definiowanej właśnie klasy i podając dalej listę jej klas bazowych, oddzielonych przecinkami. Zwykle nie będzie ona zbyt długa, gdyż w większości przypadków wystarczające jest pojedyncze dziedziczenie, zakładające tylko jedną klasę bazową.

Istotne są natomiast kolejne specyfikatory , które opcjonalnie możemy umieścić przed każdą nazwą_klasy_bazowej . Wpływają one na proces dziedziczenia, a dokładniej na prawa dostępu , na jakich klasa pochodna otrzymuje składowe klasy bazowej.

Kiedy zaś mowa o tychże prawach, natychmiast przypominamy sobie o słówkach private , protected i public , nieprawdaż? ;) Rzeczywiście, specyfikatory dziedziczenia występują zasadniczo w liczbie trzech sztuk i są identyczne z tymi występującymi wewnątrz bloku klasy. O ile jednak tamte pojawiają się w prawie każdej sytuacji i klasie, o tyle tutaj specyfikator public ma niemal całkowity monopol, a użycie pozostałych dwóch należy do niezmiernie rzadkich wyjątków.

Dlaczego tak jest? Otóż w 99.9% przypadków nie ma najmniejszej potrzeby zmiany praw dostępu do składowych odziedziczonych po klasie bazowej. Jeżeli więc któreś z nich zostały tam zadeklarowane jako protected , a inne jako public , to prawie zawsze życzymy sobie, aby w klasie pochodnej zachowały te same prawa. Zastosowanie dziedziczenia public czyni zadość tym żądaniom, dlatego właśnie jest ono tak często stosowane.

O pozostałych dwóch specyfikatorach możesz przeczytać w MSDN . Generalnie ich działanie nie jest specjalnie skomplikowane, gdyż nadają składowym klasy bazowej prawa dostępu właściwe swoim "etykietowym" odpowiednikom. Tak więc dziedziczenie protected czyni wszystkie składowe klasy bazowej chronionymi w klasie pochodnej, zaś private sprowadza je do dostępu prywatnego.

Formalnie rzecz ujmując, stosowanie specyfikatorów dziedziczenia jest nieobowiązkowe. W praktyce jednak trudno korzystać z tego faktu, ponieważ pominięcie ich jest równoznacznie z zastosowaniem specyfikatora private 2 - nie zaś naturalnego public ! Niestety, ale tak właśnie jest i trzeba się z tym pogodzić.

Nie zapominaj więc o specyfikatorze public , gdyż jego brak przed nazwą klasy bazowej jest niemal na pewno błędem.

1 Dorównują mu chyba tylko rozwiązania znane z Javy.

2 Zakładając, że mówimy o klasach deklaroanych poprzez słowo class . W przypadku struktur (słowo struct ), które są w C++ niemal tożsame z klasami, to public jest domyślnym specyfikatorem - zarówno dziedziczenia, jak i dostępu do składowych.

Dziedziczenie pojedyncze

Najprostszą i jednocześnie najczęściej występującą w dziedziczeniu sytuacją jest ta, w której mamy do czynienia tylko z jedną klasa bazową . Wszystkie dotychczas pokazane przykłady reprezentowały to zagadnienie; nazywamy je dziedziczeniem pojedynczym lub jednokrotnym (ang. single inheritance ).

Proste przypadki

Najprostsze sytuacje, w których mamy do czynienia z tym rodzajem dziedziczenia, są często spotykane w programach. Polegają one na tym, iż jedna klasa jest tworzona na podstawie drugiej poprzez zwyczajne rozszerzenie zbioru pól i metod.

Ilustracją będzie tu kolejny przykład geometryczny :)

class CEllipse // elipsa, klasa bazowa
{
private :
// większy i mniejszy promień elipsy
float m_fWiekszyPromien;
float m_fMniejszyPromien;
protected :
// współrzędne na ekranie
float m_fX, m_fY;
public :
// konstruktor
CEllipse() { m_fX = m_fY = 0.0 ;
m_fWiekszyPromien = m_fMniejszyPromien = 10.0 ; }
//
// metody

float Pole() const
{ return PI * m_fWiekszyPromien * m_fMniejszyPromien; }
};
class CCircle : public CEllipse // koło, klasa pochodna
{
private :
// promień koła
float m_fPromien;
public :
// konstruktor
CCircle() ( m_fPromien = 10.0 ; }
//
// metody

float Pole() const { return PI * m_fPromien * m_fPromien; }
float Obwod() const { return 2 * PI * m_fPromien; }
};

Jest on podobny do wariantu z prostokątem i kwadratem. Tutaj klasa CCircle jest pochodną od CEllipse , zatem dziedziczy wszystkie jej składowe, które nie są prywatne. Uzupełnia ponadto ich zbiór o dodatkową metodę Obwod() , obliczającą długość okręgu okalającego nasze koło.

Sztafeta pokoleń

Hierarchia klas nierzadko nie kończy się na jednej klasie pochodnej, lecz sięga nawet bardziej wgłąb. Nowo stworzona klasa może być bowiem bazową dla kolejnych, te zaś - dla następnych, itd.

Na samym początku spotkaliśmy się zresztą z takim przypadkiem, gdzie klasami były rodzaje zwierząt. Spróbujemy teraz przełożyć tamten układ na język C++.

Zaczynamy oczywiście od klasy, z której wszystkie inne biorą swój początek - CAnimal :

class CAnimal // Zwierzę
{
protected :
// pola klasy
float m_fMasa;
unsigned m_uWiek;
public :
// konstruktor
CAnimal() { m_uWiek = 0 ; }
//
// metody

void Patrz();
void Oddychaj();
// metody dostępowe do pól
float Masa() const { return m_fMasa; }
void Masa( float fMasa) { m_fMasa = fMasa; }
unsigned Wiek() const { return m_uWiek; }
};

Jej postać nie jest chyba niespodzianką: mamy tutaj wszystkie ustalone wcześniej, publiczne metody oraz pola, które oznaczyliśmy jako protected . Zrobiliśmy tak, bo chcemy, by były one przekazywane do klas pochodnych od CAnimal .

A skoro już wspomnialiśmy o klasach pochodnych, pomyślmy o ich definicjach. Zważywszy, że każda z nich wprowadza tylko jedną nową metodę, powinny one być raczej proste - i istotnie takie są:

class CFish : public CAnimal // Ryba
{
public :
void Plyn();
};
class CMammal : public CAnimal // Ssak
{
public :
void Biegnij();
};
class CBird : public CAnimal // Ptak
{
public :
void Lec();
};

Nie zapominamy rzecz jasna, że oprócz widocznych powyżej deklaracji zawierają one także wszystkie składowe wzięte od klasy CAnimal . Powtarzam to tak często, że chyba nie masz już co do tego żadnych wątpliwości :D

Ostatnią klasą z naszego drzewa gatunkowego był, jak pamiętamy, Pies domowy . Definicja jego klasy także jest dosyć prosta:

class CHomeDog : public CMammal // Pies domowy
{
protected :
// nowe pola
RACE m_Rasa;
COLOR m_KolorSiersci;
public :
// metody
void Aportuj();
void Szczekaj();
// metody dostępowe do pól
RACE Rasa() const { return m_Rasa; }
COLOR KolorSiersci() const { return m_KolorSiersci; }
};

 

Jak zwykle typy RACE i COLOR są mocno umowne. Ten pierwszy byłby zapewne odpowiednim enum 'em.

Wiemy jednakże, iż kryje się za nią całe bogactwo pól i metod odziedziczonych po klasach bazowych. Dotyczy to zarówno bezpośredniego przodka klasy CHomeDog , czyli CMammal , jak i jej pośredniej bazy - CAnimal . Jedyną znacząca tutaj różnicą pomiędzy tymi dwoma klasami jest fakt, że pierwsza występuje w definicji CHomeDog , zaś druga nie.

Płaskie hierarchie

Oprócz rozbudowanych, wielopoziomowych relacji typu baza-pochodna w powszechnym zastosowaniu są też takie modele, w których z jednej klasy bazowej dziedziczy wiele klas pochodnych. Jest to tzw. płaska hierarchia i wygląda np. w ten sposób:


Schemat 25. Płaska hierarchia klas figur szachowych
(ilustracje pochodzą z serwisu David Howell Chess )

Po przełożeniu jej na język C++ otrzymalibyśmy coś w tym rodzaju:

// klasa bazowa
class CChessPiece { /* definicja */ }; // Figura szachowa
// klasy pochodne
class CPawn : public CChessPiece { /* ... */ }; // Pionek
class CKnight : public CChessPiece { /* ... */ }; // Skoczek 1
class CBishop : public CChessPiece { /* ... */ }; // Goniec
class CRook : public CChessPiece { /* ... */ }; // Wieża
class CQueen : public CChessPiece { /* ... */ }; // Hetman
class CKing : public CChessPiece { /* ... */ }; // Król

Oprócz logicznego uporządkowania rozwiązanie to ma też inne zalety. Jeśli bowiem zadeklarowalibyśmy wskaźnik na obiekt klasy CChessPiece , to poprzez niego moglibyśmy odwoływać się do obiektów krórejkolwiek z klas pochodnych. Jest to jedna z licznych pozytywnych konsekwencji polimorfizmu, które zresztą poznamy wkrótce. W tym przypadku oznaczałaby ona, że za obsługę każdej z sześciu figur szachowych odpowiadałby najprawdopodobniej jeden i ten sam kod.

Można zauważyć, ze bazowa klasa CChessPiece nie będzie tutaj służyć do tworzenia obiektów, lecz tylko do wyprowadzania z niej kolejnych klas. Sprawia to, że byłaby ona dobrym kandydatem na tzw. klasę abstrakcyjną. O tym zagadnieniu będziemy mówić przy okazji metod wirtualnych.

Podsumowanie

Myślę, że po takiej ilości przykładów oraz opisów koncepcja tworzenia klas pochodnych poprzez dziedziczenie powinna być ci już doskonale znana :) Nie należy ona wszakże do trudnych; ważne jest jednak, by poznać związane z nią niuanse w języku C++.

O dziedziczeniu pojedynczym można także poczytać nieco w MSDN .

1 Nazwy klas nie są tłumaczeniami z języka polskiego, lecz po prostu angielskimi nazwami figur szachowych.

Dziedziczenie wielokrotne

Skoro możliwe jest dziedziczenie z wykorzystaniem jednej klasy bazowej, to raczej naturalne jest rozszerzenie tego zjawiska także na przypadki, w której z kilku klas bazowych tworzymy jedną klasę pochodną. Mówimy wtedy o dziedziczeniu wielokrotnym (ang. multiple inheritance ).

C++ jest jednym z niewielu języków, które udostępniają taką możliwość. Nie świadczy to jednak o jego niebotycznej wyższości nad nimi. Tak naprawdę technika dziedziczenia wielokrotnego nie daje żadnych nadzwyczajnych korzyści, a jej użycie jest przy tym dość skomplikowane. Decydując się na jej wykorzystanie należy więc posiadać całkiem spore doświadczenie w programowaniu.

Jakkolwiek zatem dziedziczenie wielokrotne bywa czasem przydatnym narzędziem, stosowanie go (przynajmniej powszechne) w tworzonych aplikacjach nie jest zalecane . Jeżeli pojawia się taka konieczność, należy wtedy najprawdopodobniej zweryfikować swój projekt; w większości sytuacji te same, a nawet lepsze efekty można osiągnąć nie korzystając z tego wielce wątpliwego rozwiązania.

Dla szczególnie zainteresowanych i odważnych istnieje oczywiście opis w MSDN .

Pułapki dziedziczenia

Chociaż idea dziedziczenia jest teoretycznie całkiem prosta do zrozumienia, jej praktyczne zastosowanie może niekiedy nastręczać pewnych problemów. Są one zazwyczaj specyficzne dla konkretnego języka programowania, jako że występują w tym względzie pewne różnice między nimi.

W tym paragrafie zajmiemy się takimi właśnie drobnymi niuansami, które są związane z dziedziczeniem klas w języku C++. Sekcja ta ma raczej charakter formalnego uzupełnienia, dlatego początkujący programiści mogą ją ze spokojem pominąć - szczególnie podczas pierwszego kontaktu z tekstem.

Co nie jest dziedziczone?

Wydawałoby się, że klasa pochodna powinna przejmować wszystkie składowe pochodzące z klasy bazowej - oczywiście z wyjątkiem tych oznaczonych jako private . Tak jednak nie jest, gdyż w trzech przypadkach nie miałoby to sensu. Owe trzy "nieprzechodnie" składniki klas to:

  • konstruktory . Zadaniem konstruktora jest zazwyczaj inicjalizacja pól klasy na ich początkowe wartości, stworzenie wewnętrznych obiektów czy też alokacja dodatkowej pamięci. Czynności te prawie zawsze wymagają zatem dostępu do prywatnych pól klasy. Jeżeli więc konstruktor z klasy bazowej zostałby "wrzucony" do klasy pochodnej, to utraciłby z nimi niezbędne połączenie - wszak "zostałyby" one w klasie bazowej! Z tego też powodu konstruktory nie są dziedziczone.

  • destruktory . Sprawa wygląda tu podobnie jak punkt wyżej. Działanie destruktorów najczęściej także opiera się na polach prywatnych, a skoro one nie są dziedziczone, zatem destruktor też nie powinien przechodzić do klas pochodnych.

Dość ciekawym uzasadnieniem niedziedziczenia konstruktorów i destruktorów są także same ich nazwy, odpowiadające klasie, w której zostały zadeklarowane. Gdyby zatem przekazać je klasom pochodnych, wtedy zasada ich nazewnictwa zostałaby złamana.
Chociaż trudno odmówić temu podejściu pomysłowości, nie ma żadnego powodu, by uważać je za błędne.

  • przeciążony operator przypisania ( = ) . Zagadnienie przeciążania operatorów omówimy dokładnie w jednym z przyszłych rozdziałów. Na razie zapamiętaj, że składowa ta odpowiada za sposób, w jaki obiekt jest kopiowany z jednej zmiennej do drugiej. Taki transfer zazwyczaj również wymaga dostępu do pól prywatnych klasy, co od razu wyklucza dziedziczenie.

Ze względu na specjalne znaczenie konstruktorów i destruktorów, ich funkcjonowanie w warunkach dziedziczenia jest dość specyficzne. Nieco dalej zostało ono bliżej opisane.

Obiekty kompozytowe

Sposób, w jaki C++ realizuje pomysł dziedziczenia, jest sam w sobie dosyć interesujący. Większość koderów uczących się tego języka z początku całkiem logicznie przypusza, że kompilator zwyczajnie pobiera deklaracje z klasy bazowej i wstawia je do pochodnej, ewentualne powtórzenia rozwiązując na korzyść tej drugiej.
Swego czasu też tak myślałem i, niestety, myliłem się: faktyczna prawda jest bowiem nieco bardziej zakręcona :)

Otóż wewnętrznie używana przez kompilator definicja klasy pochodnej jest identyczna z tą, którą wpisujemy do kodu; nie zawiera żadnych pól i metod pochodzących z klas bazowych! Jakim więc cudem są one dostępne?

Odpowiedź jest raczej zaskakująca: podczas tworzenia obiektu klasy pochodnej dokonywana jest także kreacja obiektu klasy bazowej, który staje się jego częścią . Zatem nasz obiekt pochodny to tak naprawdę obiekt bazowy plus dodatkowe pola, zdefiniowane w jego własnej klasie. Przy bardziej rozbudowanej hierarchii klas zaczyna on przypominać cebulę:


Schemat 26. Obiekt klasy pochodnej zawiera w sobie obiekty klas bazowych

Praktyczne konsekwencje tego stanu rzeczy są związane chociażby z konstruowaniem i niszczeniem tych wewnętrznych obiektów.

W C++ obowiązuje zasada, iż najpierw wywoływany jest konstruktor "najbardziej bazowej" klasy danego obiektu, a potem te stojące kolejno niżej w hierarchii. Ponieważ klasa może posiadać więcej niż jeden konstruktor, kompilator musiałby podjąć decyzję, który z nich powinien zostać użyty. Nie robi tego jednak, lecz oczekuje, że zawsze 1 będzie obecny domyślny konstruktor bezparametrowy.

Dlatego też każda klasa, z której będą dziedziczyły inne, powinna posiadać taki właśnie bezparametrowy (domyślny) konstruktor.

Podobny problem nie istnieje dla destruktorów, gdyż one nigdy nie posiadają parametrów. Podczas niszczenia obiektu są one wywoływane w kolejności od tego z klasy pochodnej do tych z klas bazowych.

***

Kończący się podrozdział opisywał mechanizm dziedziczenia - jedną z podstaw techniki programowania zorientowanego obiektowego. Mogłeś więc dowiedzieć się, w jaki sposób tworzyć nowe klasy na podstawie już istniejących i projektować ich hierarchie, obrazujące naturalne związki typu "ogół-szczegół".

W następnej kolejności poznamy zalety metod wirtualnych oraz porozmawiamy sobie o największym osiągnięciu OOPu, czyli polimorfizmie. Będzie więc bardzo ciekawie :D

1 Konieczność tę można obejść stosując tzw. listy inicjalizacyjne, o których dowiesz się za jakiś czas.

| | | |
Copyright © 2006-2013 egrafik.pl | Kontakt | Reklama | Projekty domów
jocker