Od zera do gier kodera7

Programowanie obiektowe

201

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 bezporedniego przodka klasy CHomeDog, czyli
CMammal, jak i jej poredniej bazy - CAnimal. Jedyn znaczca tutaj ró*nic pomidzy
tymi dwoma klasami jest fakt, *e pierwsza wystpuje 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 wyglda 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 jzyk C++ otrzymalibymy co w tym rodzaju:

// klasa bazowa

class

CChessPiece {

/* definicja */

};

// Figura szachowa

// klasy pochodne

class

CPawn :

public

CChessPiece {

/* ... */

};

// Pionek

class

CKnight :

public

CChessPiece {

/* ... */

};

// Skoczek

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 uporzdkowania rozwizanie to ma te* inne zalety. Jeli bowiem
zadeklarowalibymy wska(nik na obiekt klasy CChessPiece, to poprzez niego
moglibymy 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 szeciu figur szachowych
odpowiadaáby najprawdopodobniej jeden i ten sam kod.

Nazwy klas nie s táumaczeniami z jzyka polskiego, lecz po prostu angielskimi nazwami figur szachowych.

Podstawy programowania

202

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Mo*na zauwa*yü, ze bazowa klasa CChessPiece nie bdzie 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 bdziemy mówiü

przy okazji metod wirtualnych.

Podsumowanie

Myl, *e po takiej iloci 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ü zwizane z ni niuanse w jzyku C++.

O dziedziczeniu pojedynczym mo*na tak*e poczytaü nieco w

MSDN

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 jzyków, które udostpniaj tak mo*liwoü. Nie wiadczy to
jednak o jego niebotycznej wy*szoci nad nimi. Tak naprawd technika dziedziczenia
wielokrotnego nie daje *adnych nadzwyczajnych korzyci, a jej u*ycie jest przy tym doü
skomplikowane. Decydujc si na jej wykorzystanie nale*y wic posiadaü caákiem spore
dowiadczenie w programowaniu.
Jakkolwiek zatem dziedziczenie wielokrotne bywa czasem przydatnym narzdziem,
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 wikszoci sytuacji te same, a nawet lepsze efekty mo*na osignü nie
korzystajc z tego wielce wtpliwego rozwizania.

Dla szczególnie zainteresowanych i odwa*nych istnieje oczywicie opis w

MSDN

Puáapki dziedziczenia

Chocia* idea dziedziczenia jest teoretycznie caákiem prosta do zrozumienia, jej
praktyczne zastosowanie mo*e niekiedy nastrczaü pewnych problemów. S one
zazwyczaj specyficzne dla konkretnego jzyka programowania, jako *e wystpuj w tym
wzgldzie pewne ró*nice midzy nimi.

W tym paragrafie zajmiemy si takimi wáanie drobnymi niuansami, które s zwizane z
dziedziczeniem klas w jzyku C++. Sekcja ta ma raczej charakter formalnego
uzupeánienia, dlatego pocztkujcy programici 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 pochodzce
z klasy bazowej - oczywicie z wyjtkiem 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
pocztkowe wartoci, stworzenie wewntrznych obiektów czy te* alokacja
dodatkowej pamici. Czynnoci te prawie zawsze wymagaj zatem dostpu do
prywatnych pól klasy. Je*eli wic konstruktor z klasy bazowej zostaáby „wrzucony”
do klasy pochodnej, to utraciáby z nimi niezbdne poáczenie - wszak „zostaáyby”
one w klasie bazowej! Z tego te* powodu konstruktory nie s dziedziczone.

Programowanie obiektowe

203

destruktory. Sprawa wyglda tu podobnie jak punkt wy*ej. Dziaáanie
destruktorów najczciej 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, odpowiadajce 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 podejciu pomysáowoci, 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 zapamitaj, *e
skáadowa ta odpowiada za sposób, w jaki obiekt jest kopiowany z jednej zmiennej
do drugiej. Taki transfer zazwyczaj równie* wymaga dostpu do pól prywatnych
klasy, co od razu wyklucza dziedziczenie.

Ze wzgldu 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ü interesujcy.
Wikszoü koderów uczcych si tego jzyka z pocztku caákiem logicznie przypusza, *e
kompilator zwyczajnie pobiera deklaracje z klasy bazowej i wstawia je do pochodnej,
ewentualne powtórzenia rozwizujc na korzyü tej drugiej.
Swego czasu te* tak mylaáem i, niestety, myliáem si: faktyczna prawda jest bowiem
nieco bardziej zakrcona :)

Otó* wewntrznie u*ywana przez kompilator definicja klasy pochodnej jest identyczna z
t, któr wpisujemy do kodu; nie zawiera *adnych pól i metod pochodzcych z klas
bazowych! Jakim wic cudem s one dostpne?
Odpowied( jest raczej zaskakujca: podczas tworzenia obiektu klasy pochodnej
dokonywana jest tak*e kreacja obiektu klasy bazowej, który staje si jego czci.
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 zwizane chocia*by z konstruowaniem i
niszczeniem tych wewntrznych obiektów.

Podstawy programowania

204

W C++ obowizuje zasada, i* najpierw wywoáywany jest konstruktor „najbardziej
bazowej” klasy danego obiektu, a potem te stojce kolejno ni*ej w hierarchii. Poniewa*
klasa mo*e posiadaü wicej ni* jeden konstruktor, kompilator musiaáby podjü decyzj,
który z nich powinien zostaü u*yty. Nie robi tego jednak, lecz oczekuje, *e zawsze

bdzie obecny domylny konstruktor bezparametrowy.

Dlatego te* ka*da klasa, z której bd dziedziczyáy inne, powinna posiadaü taki wáanie
bezparametrowy (domylny) konstruktor.

Podobny problem nie istnieje dla destruktorów, gdy* one nigdy nie posiadaj
parametrów. Podczas niszczenia obiektu s one wywoáywane w kolejnoci od tego z klasy
pochodnej do tych z klas bazowych.

***

Koczcy si podrozdziaá opisywaá mechanizm dziedziczenia - jedn z podstaw techniki
programowania zorientowanego obiektowego. Mogáe wic dowiedzieü si, w jaki sposób
tworzyü nowe klasy na podstawie ju* istniejcych i projektowaü ich hierarchie, obrazujce
naturalne zwizki typu „ogóá-szczegóá”.

W nastpnej kolejnoci poznamy zalety metod wirtualnych oraz porozmawiamy sobie o
najwikszym osigniciu OOPu, czyli polimorfizmie. Bdzie wic bardzo ciekawie :D

Metody wirtualne i polimorfizm

Dziedziczenie jest oczywicie niezwykle wa*nym, a wrcz niezbdnym skadnikiem
programowania obiektowego. Stanowi jednak tylko podstaw dla dwóch kolejnych
technik, majcych du*o wiksze znaczenie i pozwalajcych na o wiele efektywniejsze
pisanie kodu. Mam tu na myli tytuáowe metody wirtualne oraz czciowo bazujcy na
nich polimorfizm. Wszystkie te dziwne terminy zostan wkrótce wyjanione, zatem nie
wpadajmy zbyt pochopnie w panik ;)

Wirtualne funkcje skáadowe

Idea dziedziczenia w znanej nam dotd postaci jest nastawiona przede wszystkim na
uzupeánianie definicji klas bazowych o kolejne skáadowe w klasach pochodnych. Tylko
czasami zastpowalimy ju* istniejce metody ich nowymi wersjami, wáaciwymi dla
tworzonych klas.
Takie sytuacje s jednak w praktyce dosyü czste - albo raczej korzystne jest
prowokowanie takich sytuacji, gdy* niejednokrotnie daj one wietne rezultaty i
niespotykane wczeniej mo*liwoci przy niewielkim nakáadzie pracy. Oczywicie dzieje si
tak tylko wtedy, gdy mamy odpowiednie podejcie do sprawy…

To samo, ale inaczej

Raz jeszcze zajmijmy si nasz hierarchi klas zwierzt. Tym razem skierujemy uwag
na metod Oddychaj z klasy Zwierz.

Jej obecnoü u szczytu diagramu, w klasie, z której pocztek bior wszystkie inne, jest z
pewnoci uzasadniona. Ka*de zwierz, niezale*nie od gatunku, musi przecie* pobieraü z
otoczenia tlen niezbdny do *ycia, a proces ten nazywamy potocznie wáanie
oddychaniem. Jest to bezdyskusyjne.

Koniecznoü t mo*na obejü stosujc tzw. listy inicjalizacyjne, o których dowiesz si za jaki czas.

Programowanie obiektowe

205

Mniej oczywisty jest natomiast fakt, *e „techniczny” przebieg tej czynnoci mo*e si
zasadniczo ró*niü u poszczególnych zwierzt. Te *yjce na ldzie u*ywaj do tego
narzdów zwanych páucami, za zwierzta wodne - chocia*by ryby - maj w tym celu
wyksztaácone skrzela, funkcjonujce na zupeánie innej zasadzie.

Spostrze*enia te nietrudno przeáo*yü na bli*szy nam sposób mylenia, zwizany
bezporednio z programowaniem. Oto wic klasy wywodzce si do Zwierzcia powinny
w inny sposób implementowaü metod Oddychaj; jej treü musi byü odmienna
przynajmniej dla Ryby, a i Ssak oraz Gad maj przecie* wáasne patenty na proces
oddychania.
Rzeczona metoda podpada zatem pod redefinicj w ka*dej z klas dziedziczcych od
klasy Zwierz:

Schemat 27. Przedefiniowanie metody z klasy bazowej w klasach pochodnych

Deklaracja metody wirtualnej

Teoretycznie klasa Zwierz mogáaby byü caákowicie „niewiadoma” tego, *e jedna z jej
metod jest definiowana w inny sposób w klasie pochodnej. Lepiej jednak, abymy
przewidzieli tak koniecznoü i poczynili odpowiedni krok. Jest nim uczynienie funkcji
Oddychaj metod wirtualn w klasie Zwierz.

Metoda wirtualna jest przygotowana na zastpienie siebie przez now wersj,
zdefiniowan w klasie pochodnej.

Aby dan funkcj skáadow zadeklarowaü jako wirtualn, nale*y poprzedziü jej prototyp
sáowem kluczowym

virtual

#include

class

CAnimal

{

// (pomijamy pozostaáe skáadowe klasy)

public

virtual

void

Oddychaj()

{ std::cout <<

"Oddycham..."

<< std::endl; }

};

W ten sposób przygotowujemy j na ewentualne ustpienie miejsca bardziej
wyspecjalizowanym wersjom, podanym w klasach pochodnych. Skorzystanie z
mechanizmu metod wirtualnych jest tutaj lepszym rozwizaniem ni* zignorowanie go,
gdy* uaktywnia to mo*liwoci polimorfizmu zwizane z obiektami. Zapoznamy si z nimi
w dalszej czci tekstu.

Podstawy programowania

206

Przedefiniowanie metody wirtualnej

Celem wprowadzenia funkcji wirtualnej Oddychaj() do klasy CAnimal byáo, jak to
zaznaczylimy na pocztku, jej pó(niejsze przedefiniowanie (ang. override) w klasach
pochodnych. Operacji tej dokonujemy prost drog, bowiem zwyczajnie definiujemy
now wersj metody w owych klasach:

class

CFish :

public

CAnimal

{

public

void

Oddychaj()

// redefinicja metody wirtualnej

{ std::cout <<

"Oddycham skrzelami..."

<< std::endl; }

void

Plyn();

};

class

CMammal :

public

CAnimal

{

public

void

Oddychaj()

// jak wy*ej

{ std::cout <<

"Oddycham páucami..."

<< std::endl; }

void

Biegnij();

};

class

CBird :

public

CAnimal

{

public

void

Oddychaj()

// i znowu jak wy*ej :)

{ std::cout <<

"Oddycham páucami..."

<< std::endl; }

void

Lec();

};

Kompilator sam „domyla si”, *e nasza metody jest tak naprawd redefinicj metody
wirtualnej z klasy bazowej. Mo*emy jednak wyra(nie to zaznaczyü poprzez ponowne
zastosowanie sáowa

virtual

Wedáug mnie jest to maáo szczliwe rozwizanie skáadniowe, poniewa* mo*e czsto
powodowaü pomyáki. Nie sposób bowiem odró*niü deklaracji przedefiniowanej metody
wirtualnej od jej pierwotnej wersji (je*eli jeszcze raz u*ylimy

virtual

) lub od zwykáej

funkcji skáadowej (gdy nie skorzystalimy ze wspomnianego sáówka).
Bardziej przejrzycie rozwizano to na przykáad w Delphi, gdzie now wersj metody
wirtualnej trzeba opatrzyü fraz override;.

Nowa wersja metody caákowicie zastpuje star, która jest jednak dostpna i w razie
potrzeby mo*emy j wywoáaü. Sáu*y do tego konstrukcja:

nazwa_klasy_bazowej::nazwa_metody([parametry]);

W powy*szym przypadku byáoby to wywoáanie CAnimal::Oddychaj().

W Visual C++ zamiast nazwy_klasy_bazowej mo*liwe jest u*ycie specjalnego sáowa

kluczowego

__super

, opisanego

tutaj

Pojedynek: metody wirtualne przeciwko zwykáym

Czytajc powy*sze objanienie metod wirtualnych, zadawaáe sobie zapewne proste
pytanie o gábokiej treci, a mianowicie: „Po co mi to?” ;-) Najlepsz odpowiedzi na nie
bdzie wyjanienie ró*nicy pomidzy zwykáymi oraz wirtualnymi metodami.

Programowanie obiektowe

207

Posáu*y nam do tego nastpujcy kod, tworzcy obiekt jednej z klasy pochodnych i
wywoáujcy jego metod Oddychaj():

CAnimal* pZwierzak =

new

CMammal;

pZwierzak->Oddychaj();

delete

pZwierzak;

Zauwa*my, *e wska(nik pZwierzak, poprzez który odwoáujemy si do naszego obiektu,
jest zasadniczo wska(nikiem na klas CAnimal. Stwarzany przez nas (poprzez instrukcj

new

) obiekt nale*y natomiast do klasy CMammal. Wszystko jest jednak w porzdku. Klasa

CMammal dziedziczy od klasy CAnimal, zatem ka*dy obiekt nale*cy do tej pierwszej
jednoczenie jest tak*e obiektem tej drugiej. Wyjanilimy to sobie caákiem niedawno,
prezentujc dziedziczenie.
Zajmijmy si raczej drug linijk powy*szego kodu, zawierajc wywoáanie interesujcej
nas metody Oddychaj(). Ró*nica midzy zwykáymi a wirtualnymi funkcjami skáadowymi
bdzie miaáa okazj uwidoczniü si wáanie tutaj. Wszystko bowiem zale*y od tego, jak
metod jest rzeczona funkcja Oddychaj(), za rezultatem rozwa*anej instrukcji mo*e
byü zarówno wywoáanie CAnimal::Oddychaj(), jak i CMammal::Oddychaj()! Dowiedzmy
si wic, kiedy zajdzie ka*da z tych sytuacji.

à

atwiejszym przypadkiem jest chyba „niewirtualnoü” rozpatrywanej metody. Kiedy jest

ona zwyczajn funkcj skáadow, wtedy kompilator nie traktuje jej w *aden specjalny
sposób. Co to jednak w praktyce oznacza?…
To dosyü proste. W takich bowiem wypadkach decyzja, która metoda jest rzeczywicie
wywoáywana, zostaje podjta ju* na etapie kompilacji programu. Nazywamy j wtedy
wczesnym wizaniem (ang. early binding) funkcji. Do jej podjcia s zatem
wykorzystane jedynie te informacje, które s znane w momencie kompilacji programu;
u nas jest to typ wska(nika pZwierzak, czyli CAnimal. Nie jest przecie* mo*liwe
ustalenie, na jaki obiekt bdzie on faktycznie wskazywaá - owszem, mo*e on nale*eü do
klasy CAnimal, jednak równie dobrze do jej pochodnej, na przykáad CMammal. Wiedza ta
nie jest jednak dostpna podczas kompilacji

, dlatego te* tutaj zostaje asekuracyjnie

wykorzystany jedynie znany typ CAnimal. Faktycznie wywoáywan metod bdzie wic
CAnimal::Oddychaj()!

Huh, to raczej nie jest to, o co nam chodziáo. Skoro ju* tworzymy obiekt klasy CMammal,
to w zasadzie logiczne jest, *e zale*y nam na wywoáaniu funkcji pochodzcej z tej wáanie
klasy, a nie z jej bazy! Spotyka nas jednak przykra niespodzienka…
Czy uchroni od niej zastosowanie metod wirtualnych? Domylasz si zapewne, i* tak
wáanie bdzie, i na dodatek masz tutaj absolutn racj :) Kiedy u*yjemy magicznego
sáówka

virtual

, kompilator wstrzyma si z decyzj co do faktycznie przywoáywanej

metody. Jej podjcie nastpi dopiero w stosowanej chwili podczas dziaáania gotowej
aplikacji; nazywamy to pó(nym wizaniem (ang. late binding) funkcji. W tym
momencie bdzie oczywicie wiadome, jaki obiekt naprawd kryje si za naszym
wska(nikiem pZwierzak i to jego wersja metody zostanie wywoáana. Uzyskamy zatem
skutek, o jaki nam chodziáo, czyli wywoáanie funkcji CMammal::Oddychaj().

Prezentowany tu problem wyra(nie podpada ju* pod idee polimorfizmu, które
wyczerpujco poznamy niebawem.

Wirtualny destruktor

Atrybut

virtual

mo*emy przyáczyü do ka*dej zwyczajnej metody, a nawet takiej

niezupeánie zwyczajnej :) Czasami zreszt zastosowanie go jest niemal powinnoci…

Tak naprawd kompilator mo*e w ogóle nie wiedzieü, *e CAnimal posiada jakie klasy pochodne!

Podstawy programowania

208

Je*eli chodzi o konstruktory, to stosowanie tego modyfikatora w stosunku do nich nie ma
zbyt wielkiego sensu. S one przecie* domylnie „jakby wirtualne”: wywoáanie
konstruktora z klasy pochodnej powoduje przecie* uruchomienie tak*e konstruktorów z
klas bazowych. Ich przedefiniowanie nie jest przy tym niczym nadzwyczajnym, tak wic
u*ycie sáowa

virtual

w tym przypadku mija si z celem.

Zupeánie inaczej sprawa ma si z destruktorami. Tutaj u*ycie omawianego modyfikatora
jest nie tylko mo*liwe, ale te* prawie zawsze konieczne i zalecane. Nieobecnoü
wirtualnego destruktora w klasie bazowej mo*e bowiem prowadziü do tzw. wycieków
pamici, czyli bezpowrotnej utraty zaalokowanej pamici operacyjnej.
Dlaczego tak si dzieje? Do wyjanienia posáu*ymy si po raz kolejny naszymi
wysáu*onymi klasami zwierzt :D Przypuümy, *e czujemy potrzeb, aby dokáadniej
odpowiadaáy one rzeczywistoci; by nie byáy tylko zbiorami danych, ale te* zawieraáy
obiektowe odpowiedniki narzdów wewntrznych, na przykáad serca czy páuc. Poczynimy
wic najpierw pewne zmiany w bazowej klasie CAnimal:

// klasa serca

class

CHeart {

/* ... */

};

// bazowa klasa zwierzt

class

CAnimal

{

// (pomijamy nieistotne, pozostaáe skáadowe)

protected

CHeart*

m_pSerce;

public

// konstruktor i destruktor

CAnimal()

{ m_pSerce =

new

CHeart; }

~CAnimal()

{

delete

m_pSerce;

}

};

Serce jest oczywicie organem, który posiada ka*de zwierz, zatem obecnoü wska(nika
na obiekt klasy CHeart jest tu uzasadniona. Odwoáuje si on do obiektu tworzonego w
konstruktorze, a niszczonego w destruktorze klasy CAnimal.
Naturalnie, nie samym sercem zwierz *yje :) Ssaki na przykáad potrzebuj jeszcze páuc:

// klasa páuc

class

CLungs {

/* ... */

};

// klasa ssaków

class

CMammal :

public

CAnimal

{

protected

CLungs*

m_pPluca;

public

// konstruktor i destruktor

CMammal()

{ m_pPluca =

new

CLungs; }

~CMammal()

{

delete

m_pPluca;

}

};

Podobnie jak wczeniej, obiekt specjalnej klasy jest tworzony w konstruktorze i zwalniany
w destruktorze CMammal. W ten sposób nasze ssaki s zaopatrzone zarówno w serce
(otrzymane od CAnimal), jak i niezbdne páuca, tak wic po*yj sobie jeszcze troch i
bd mogáy nadal sáu*yü nam jako przykáad ;)

OK, gdzie zatem tkwi problem?… Powróümy teraz do trzech linijek kodu, za pomoc
których rozstrzygnlimy pojedynek midzy wirtualnymi a niewirtualnymi metodami:

Programowanie obiektowe

209

CAnimal* pZwierzak =

new

CMammal;

pZwierzak->Oddychaj();

delete

pZwierzak;

Przypomnijmy, *e pZwierzak jest tu zasadniczo zmienn typu „wska(nik na obiekt klasy
CAnimal”, ale tak naprawd wskazuje na obiekt nale*cy do pochodnej CMammal. Ów
obiekt musi oczywicie zostaü usunity, za co powinna odpowiadaü ostatnia linijka…

No wáanie - powinna. Szkoda tylko, *e tego nie robi. To zreszt nie jest jej wina,
przyczyn jest wáanie brak wirtualnego destruktora.
Jak bowiem wiemy, zniszczenie obiektu oznacza w pierwszej kolejnoci wywoáanie tej
kluczowej metody. Podlega ono identycznym reguáom, jakie stosuj si do wszystkich
innych metod, a wic tak*e efektom zwizanym z wirtualnoci oraz wczesnym i pó(nym
wizaniem. Je*eli wic nasz destruktor nie bdzie oznaczony jako

virtual

, to kompilator

potraktuje go jako zwyczajn metod i zastosuje wobec niej technik wczesnego
wizania. Zasugeruje si po prostu typem zmiennej pZwierzak (którym jest CAnimal*, a
wic wska(nik na obiekt klasy CAnimal) i wywoáa wyácznie destruktor klasy bazowej
CAnimal! Destruktor ten wprawdzie usunie serce naszego ssaka, ale nie zrobi tego z
páucami, bo i nie ma przecie* o nich zielonego pojcia.
Nie doü zatem, *e tracimy przez to pamiü przeznaczon na ten*e narzd, to jeszcze
pozwalamy, by wokóá fruwaáy nam organy pozbawione wáacicieli ;D

To oczywicie tylko obrazowy dowcip, jednak konsekwencje niepeánego zniszczenia
obiektów mog byü du*o powa*niejsze, szczególnie jeli ich skáadniki odwoáywaáy si do
siebie nawzajem. We(my choüby wspomniane páuca - powinny one przecie* dostarczaü
tlen do serca, a je*eli samo serce ju* nie istnieje, no to zaczynaj si nieliche problemy…

Rozwizanie problemu jest rzecz jasna nadzwyczaj proste - wystarczy uczyniü destruktor
klasy bazowej CAnimal metod wirtualn:

class

CAnimal

{

(oszczdnoü jest cnot, wic znowu pomijamy reszt skáadowych :D)

public

virtual

~CAnimal()

{

delete

m_pSerce; }

};

Wtedy te* operator

delete

bdzie usuwaá obiekt, na który faktycznie wskazuje podany

mu wska(nik. My za uchronimy si od perfidnych bádów.

Pamitaj zatem, aby zawsze umieszczaü wirtualny destruktor w klasie bazowej.

Zaczynamy od zera… dosáownie

Deklarujc metody opatrzone modyfikatorem

virtual

, tworzymy grunt pod ich przyszá,

ponown implementacj w klasach dziedziczcych. Mo*na te* powiedzieü, i* w pewnym
sensie zmieniamy charakter zawierajcej je klasy: jej rol nie jest ju* przede wszystkim
tworzenie obiektów, gdy* równie wa*ne staje si sáu*enie jako baza dla klas pochodnych.

Niekiedy sáuszne jest pójcie jeszcze dalej, to znaczy caákowite pozbawienie klasy
mo*liwoci tworzenia z niej obiektów. Ma to nierzadko rozsdne uzasadnienie i takimi
wáanie przypadkami zajmiemy si w tym paragrafie.

Podstawy programowania

210

Czysto wirtualne metody

Wirtualna funkcja skáadowa umieszczona w klasie bazowej jest przygotowana na to, aby
ustpiü miejsca swej bardziej wyspecjalizowanej wersji, zdefiniowanej w klasie
pochodnej. Nie zmienia to jednak faktu, i* musiaáaby ona jako implementowaü
czynnoü, której przebiegu czsto nie sposób ustaliü na tym etapie.

Posiadamy dobry przykáad, ilustrujcy tak wáanie sytuacj. Chodzi mianowicie o
metod CAnimal::Oddychaj(). Wewntrz klasy bazowej, z której maj dopiero
dziedziczyü konkretne grupy zwierzt, niemo*liwe jest przecie* ustalenie uniwersalnego
sposobu oddychania. Sensowna implementacja tej metody jest wic w zasadzie
niemo*liwa.
Sprawia to, i* jest ona wywienitym kandydatem na czysto wirtualn funkcj
skáadow.

Metody nazywane czysto wirtualnymi (ang. pure virtual) nie posiadaj *adnej
implementacji i s przeznaczone wyácznie do przedefiniowania w klasach
pochodnych.

Deklaracja takiej metody ma doü osobliw postaü. Oczywicie z racji nie posiadania
*

adnego kodu zbdne staj si nawiasy klamrowe wyznaczajce jej blok, zatem caáoü

przypomina zwykáy prototyp funkcji. Samo oznaczenie, czynice dan metod czysto
wirtualn, jest jednak raczej niecodzienne:

class

CAnimal

{

// (definicja klasy jest skromna z przyczyn oszczdnociowych :))

public

virtual

void

Oddychaj() =

;

};

Jest nim wystpujca na kocu fraza =

;. Kojarzy si ona troch z domyln wartoci

funkcji, ale interpretacja taka upada w obliczu niezwracania przez metod Oddychaj()
*

adnego rezultatu. Faktycznie funkcj czysto wirtualn mo*emy w ten sposób uczyniü

ka*d wirtualn metod, niezale*nie od tego, czy zwraca jak wartoü i jakiego jest ona
typu. Sekwencja =

; jest wic po prostu takim dziwnym oznaczeniem, stosowanym dla

tego rodzaju metod. Trzeba si z nim zwyczajnie pogodziü :)

Twórcy C++ wyra(nie nie chcieli wprowadzaü tutaj dodatkowego sáowa kluczowego, ale w

tym przypadku trudno si z nimi zgodziü. Osobicie uwa*am, *e deklaracja w formie na

przykáad

pure

virtual

void

Oddychaj(); byáaby znacznie bardziej przejrzysta.

Po dokonaniu powy*szej operacji metoda CAnimal::Oddychaj() staje si zatem czysto
wirtualn funkcj skáadow. W tej postaci okrela ju* tylko sam czynnoü, bez
podawania *adnego algorytmu jej wykonania. Zostanie on ustalony dopiero w klasach
dziedziczcych od CAnimal.

Mo*na aczkolwiek podaü implementacj metody czysto wirtualnej, jednak bdzie ona

mogáa byü wykorzystywana tylko w kodzie metod klas pochodnych, które j

przedefiniowuj, w formie klasa_bazowa::nazwa_metody([parametry]).

Abstrakcyjne klasy bazowe

Nie widaü tego na pierwszy, drugi, ani nawet na dziesity rzut oka, ale zadeklarowanie
jakiej metody jako czysto wirtualnej powoduje jeszcze jeden, dodatkowy efekt. Otó*
klasa, w której tak funkcj stworzymy, staje si klas abstrakcyjn.

Programowanie obiektowe

211

Klasa abstrakcyjna zawiera przynajmniej jedn czysto wirtualn metod i z jej powodu
nie jest przeznaczona do instancjowania (tworzenia z niej obiektów), a jedynie do
wyprowadzania ze klas pochodnych.

Ze wzgldu na wy*ej wymienion definicj czysto wirtualne funkcje skáadowe okrela si

niekiedy mianem metod abstrakcyjnych. Nazwa ta jest szczególnie popularna wród

programistów jzyka Object Pascal.

Takie klasy buduj zawsze najwy*sze pitra w hierarchiach i s podstawami dla bardziej
wyspecjalizowanych typów. W naszym przypadku mamy tylko jedn tak klas, z której
dziedzicz wszystkie inne. Nazywa si CAnimal, jednak dobry zwyczaj programistyczny
nakazuje, aby klasy abstrakcyjne miaáy nazwy zaczynajce si od litery I. Ró*ni si one
bowiem znacznie od pozostaáych klas. Zatem baza w naszej hierarchii bdzie od tej pory
zwaü si IAnimal.

C++ bardzo dosáownie traktuje reguá, i* klasy abstrakcyjne nie s przeznaczone do
instancjowania. Próba utworzenia z nich obiektu zakoczy si bowiem bádem;
kompilator nie pozwoli na obecnoü czysto wirtualnej metody w klasie tworzonego
obiektu.
Mo*liwe jest natomiast zadeklarowanie wska(nika na obiekt takiej klasy i przypisanie mu
obiektu klasy potomnej, tak wic poni*szy kod bdzie jak najbardziej poprawny:

IAnimal* pZwierze =

new

CBird;

pZwierze->Oddychaj();

delete

pZwierze;

Wywoáanie metody Oddychaj() jest tu tak*e dozwolone. Wprawdzie w bazowej klasie
IAnimal jest ona czysto wirtualna, jednak w CBird, do obiektu której odwoáuje si nasz
wska(nik, posiada ona odpowiedni implementacj.

Wydawaáoby si, *e C++ reaguje nieco zbyt alergicznie na prób utworzenia obiektu

klasy abstrakcyjnej - w kocu sama kreacja nie jest niczym niepoprawnym. W ten sposób

jednak mamy pewnoü, *e podczas dziaáania programu wszystko bdzie dziaáaü

poprawnie i *e omyákowo nie zostanie wywoáana metoda z nieokrelon implementacj.

Polimorfizm

Gdyby programowanie obiektowe porównaü do wysokiego budynku, to u jego
fundamentów le*aáyby pojcia „klasy” i „obiekty”, rodkowe pitra budowaáoby
„dziedziczenie” oraz „metody wirtualne”, za u samego szczytu sytuowaáby si
„polimorfizm”. Jest to bowiem najwiksze osignicie tej metody programowania.

Z terminem tym spotykalimy si przelotnie ju* par razy, ale teraz wreszcie wyjanimy
sobie wszystko od pocztku do koca. Zacznijmy choüby od samego sáowa: ‘polimorfizm’
pochodzi od greckiego wyrazu polýmorphos, oznaczajcego ‘wieloksztaátny’ lub
‘wielopostaciowy’. W programowaniu bdzie si wic odnosiü do takich tworów, które
mo*na interpretowaü na ró*ne sposoby - a wic nale*cych jednoczenie do kilku ró*nych
typów (klas).

Polimorfizm w programowaniu obiektowym oznacza wykorzystanie tego samego kodu
do operowania na obiektach przynale*nych ró*nym klasom, dziedziczcym od siebie.

Zjawisko to jest zatem cile zwizane z klasami i dziedziczeniem, aczkolwiek w C++ nie
dotyczy ono ka*dej klasy, a jedynie okrelonych typów polimorficznych.

Podstawy programowania

212

Typ polimorficzny to w C++ klasa zawierajca przynajmniej jedn metod wirtualn.

W praktyce wikszoü klas, do których chcielibymy stosowaü techniki polimorfizmu,
speánia ten warunek. W szczególnoci t wymagan metod wirtualn mo*e byü
chocia*by destruktor.

Wszystko to brzmi bardzo áadnie, ale trudno nie zadaü sobie pytania o praktyczne
korzyci zwizane z wykorzystaniem polimorfizmu. Dlatego te* moim celem bdzie teraz
drobiazgowa odpowied( na to pytanie - innymi sáowy, wreszcie doczekaáe si
konkretów ;D

Ogólny kod do szczególnych zastosowa

Zjawisko polimorfizmu pozwala na znaczne uproszczenie wikszoci algorytmów, w
których du* rol odgrywa zarzdzanie wieloma ró*nymi obiektami. Nie chodzi tu wcale o
jakie skomplikowane operacje sortowania, wyszukiwania, kompresji itp., tylko o czsto
spotykane operacje wykonywania tej samej czynnoci dla wielu obiektów ró*nych
rodzajów.

Opis ten jest w zaáo*eniu doü ogólny, bowiem sposób, w jaki u*ywa si obiektowych
technik polimorfizmu jest cile zwizany z konkretnymi programami. Postaram si
jednak przytoczyü w miar klarowne przykáady takich rozwiza, aby miaá chocia*
ogólne pojcie o tej metodzie programowania i mógá j stosowaü we wáasnych
aplikacjach.

Sprowadzanie do bazy

Prosty przypadek wykorzystania polimorfizmu opiera si na elementarnej i rozsdnej
zasadzie, któr nie raz ju* sprawdzilimy w praktyce. Mianowicie:

Wska(nik na obiekt klasy bazowej mo*e wskazywaü tak*e na obiekt którejkolwiek z jego
klas pochodnych.

Bezporednie przeáo*enie tej reguáy na konkretne zastosowanie programistyczne jest
doü proste. Przypuümy wic, *e mamy tak oto hierarchi klas:

#include

#include

<ctime>

// klasa dowolnego dokumentu

class

CDocument

{

protected

// podstawowe dane dokumentu

std::string

m_strAutor;

// autor dokumentu

std::string

m_strTytul;

// tytuá dokumentu

tm m_Data;

// data stworzenia

public

// konstruktory

CDocument()

{

m_strAutor = m_strTytul =

"???"

;

time_t Czas = time(NULL); m_Data = *localtime(&Czas); }

CDocument(std::string

strTytul)

{

CDocument(); m_strTytul = strTytul; }

CDocument(std::string strAutor, std::string strTytul)

{

CDocument();

m_strAutor = strAutor;

m_strTytul = strTytul; }

Programowanie obiektowe

213

// -------------------------------------------------------------

// metody dostpowe do pól

std::string

Autor()

const

{

return

m_strAutor; }

std::string

Tytul()

const

{

return

m_strTytul; }

tm Data()

const

{

return

m_Data;

}

};

// ----------------------------------------------------------------------

// dokument internetowy

class

COnlineDocument :

public

CDocument

{

protected

std::string

m_strURL;

// adres internetowy dokumentu

public

konstruktory

COnlineDocument(std::string strAutor, std::string strTytul)

{ m_strAutor = strAutor; m_strTytul = strTytul; }

COnlineDocument

(std::string

strAutor,

std::string strTytul,

std::string strURL)

{ m_strAutor = strAutor;

m_strTytul = strTytul;

m_strURL = strURL; }

// -------------------------------------------------------------

// metody dostpowe do pól

std::string

URL()

const

{

return

m_strURL; }

};

// ksi*ka

class

CBook :

public

CDocument

{

protected

std::string

m_strISBN;

// numer ISBN ksi*ki

public

// konstruktory

CBook(std::string strAutor, std::string strTytul)

{ m_strAutor = strAutor; m_strTytul = strTytul; }

CBook (std::string strAutor,

std::string strTytul,

std::string strISBN)

{ m_strAutor = strAutor;

m_strTytul = strTytul;

m_strISBN = strISBN; }

// -------------------------------------------------------------

// metody dostpowe do pól

std::string

ISBN()

const

{

return

m_strISBN; }

};

Z klasy CDocument, reprezentujcej dowolny dokument, dziedzicz dwie nastpne:
COnlineDocument, odpowiadajca tekstom dostpnym przez Internet, oraz CBook,
opisujca ksi*ki.
Napiszmy równie* odpowiedni funkcj, wywietlajc podstawowe informacje o
podanym dokumencie:

Podstawy programowania

214

#include

void

PokazDaneDokumentu(CDocument* pDokument)

{

wywietlenie autora

std::cout

"AUTOR: "

;

std::cout << pDokument->Autor() << std::endl;

// pokazanie tytuáu dokumentu

// (sekwencja \" wstawia cudzysáów do napisu)

std::cout

"TYTUL: "

;

std::cout

"\""

<< pDokument->Tytul() <<

"\""

<< std::endl;

// data utworzenia dokumentu

// (pDokument->Data() zwraca struktur typu tm, do której pól

// mo*na dostaü si tak samo, jak do wszystkich innych - za

// pomoc operatora wyáuskania . (kropki))

std::cout

"DATA : "

;

std::cout << pDokument->Data().tm_mday <<

"."

<< (pDokument->Data().tm_mon +

) <<

"."

<< (pDokument->Data().tm_year +

1900

) << std::endl;

}

Bierze ona jeden parametr, bdcy zasadniczo wska(nikiem na obiekt typu CDocument. W
jego charakterze mo*e jednak wystpowaü tak*e wskazanie na który z obiektów
potomnych, zatem poni*szy kod bdzie absolutnie prawidáowy:

COnlineDocument* pTutorial =

new

COnlineDocument(

"Xion"

// autor

"Od zera do gier kodera"

// tytuá

"http://avocado.risp.pl"

);

// URL

PokazDaneDokumentu (pTutorial);

delete

pTutorial;

W pierwszej linijce mo*naby równie dobrze u*yü typu wskazujcego na obiekt
CDocument, gdy* wska(nik pTutorial i tak zostanie potraktowany w ten sposób przy
przekazywaniu go do funkcji PokazDaneDokumentu().

Efektem jego dziaáania powy*szego listingu bdzie na przykáad taki oto widok:

Screen 32. Informacje o dokumencie uzyskane z u*yciem prostego polimorfizmu

Brak tu informacji o adresie internetowym dokumentu, poniewa* nale*y on do
skáadowych specyficznych dla klasy COnlineDocument. Funkcja PokazDaneDokumentu()
zostaáa natomiast stworzona do pracy z obiektami CDocument, zatem wykorzystuje
jedynie informacje zawarte w klasie bazowej. Nie przeszkadza to jednak w przekazaniu
jej obiektu klasy pochodnej - w takim przypadku dodatkowe dane zostan po prostu
zignorowane.

To raczej maáo satysfakcjonujce rozwizanie, ale lepsze skutki wymagaj ju* u*ycia
metod wirtualnych. Uczynimy to w kolejnym przykáadzie.

Naturalnie, podobny rezultat otrzymalibymy podajc naszej funkcji obiekt klasy CBook
czy te* jakiejkolwiek innej dziedziczcej od CDocument. Kod procedury jest wic
uniwersalny i mo*e byü stosowany do wielu ró*nych rodzajów obiektów.

Programowanie obiektowe

215

Eureka! Na tym przecie* polega polimorfizm :)

Mo*liwe *e zauwa*yáe, i* *adna z tych przykáadowych klas nie jest tutaj typem

polimorficznym, a jednak podany wy*ej kod dziaáa bez zarzutu. Powodem tego jest jego

wzgldna prostota. Dokáadniej mówic, nie jest konieczne sprawdzanie poprawnoci

typów podczas dziaáania programu, bo wystarczajca jest zwykáa kontrola, dokonywana

zwyczajowo podczas kompilacji kodu.

Klasy wiedz same, co nale*y robiü

Z poprzednim przykáadem zwizany jest pewien mankament, nietrudno zreszt
zauwa*alny. Niezale*nie od tego, jakie dodatkowe dane o dokumencie zadeklarujemy w
klasach pochodnych, nasza funkcja wywietli tylko i wyácznie te przewidziane w klasie
CDocument. Nie uzyskamy wic nic ponad autora, tytuá oraz dat stworzenia dokumentu.

Trzeba jednak przyznaü, *e sami niejako jestemy sobie winni. Wyodrbniajc czynnoü
prezentacji obiektu poza sam obiekt postpilimy niezgodnie z ide OOPu, która nakazuje
á

czyü dane i operujcy na nich kod.

Zatem przykáad z poprzedniego paragrafu to zdecydowanie záy przykáad :D

O wiele lepszym rozwizaniem jest dodanie do klasy CDocument odpowiedniej metody,
odpowiedzialnej za czynnoü wypisywania. A ju* caákowitym ideaáem bdzie uczynienie
jej funkcj wirtualn - wtedy klasy dziedziczce od CDocument bd mogáy ustaliü wáasny
sposób prezentacji swoich danych.
Wszystkie te doskonaáe pomysáy praktycznie realizuje poni*szy program przykáadowy:

// Polymorphism - wykorzystanie techniki polimorfizmu

// *** documents.h ***

class

CDocument

{

(wikszoü skáadowych wycito z powodu zbyt du*ej objtoci)

public

virtual

void

PokazDane();

};

// (reszty klas nieuwzgldniono z powodu dziury bud*etowej ;D)
// (za ich implementacje s w pliku documents.cpp)

// *** main.cpp ***

#include

#include

<conio.h>

#include

"documents.h"

void

main()

{

// wska(nik na obiekty dokumentów

CDocument*

pDokument;

// pierwszy dokument - internetowy

std::cout << std::endl <<

"--- 1. pozycja ---"

<< std::endl;

pDokument

new

COnlineDocument(

"Regedit"

"Cyfrowe przetwarzanie tekstu"

Podstawy programowania

216

"http://programex.risp.pl/?"

"strona=cyfrowe_przetwarzanie_tekstu"

);
pDokument->PokazDane();

delete

pDokument;

// drugi dokument - ksi*ka

std::cout << std::endl <<

"--- 2. pozycja ---"

<< std::endl;

pDokument

new

CBook(

"Sam Williams"

"W obronie wolnosci"

"83-7361-247-5"

);

pDokument->PokazDane();

delete

pDokument;

getch();
}

Wynikiem jego dziaáania bdzie poni*sze zestawienie:

Screen 33. Aplikacja prezentujca polimorfizm z wykorzystaniem metod wirtualnych

Zauwa*my, *e za wywietlenie obu widniejcych na nim pozycji odpowiada wywoáanie
pozornie tej samej funkcji:

pDokument->PokazDane();

Polimorficzny mechanizm metod wirtualnych sprawia jednak, *e zawsze wywoáywana jest
odpowiednia wersja procedury PokazDane() - odpowiednia dla kolejnych obiektów, na
które wskazuje pDokument.

Tutaj mamy wprawdzie tylko dwa takie obiekty, ale nietrudno wyobraziü sobie
analogiczne dziaáanie dla wikszej ich liczby, np.:

CDocument* apDokumenty[

100

];

for

(

unsigned

i =

; i <

100

; ++i)

apDokumenty[i]->PokazDane();

Poszczególne elementy tablicy apDokumenty mog wskazywaü na obiekty dowolnych
klas, dziedziczcych od CDocument, a i tak kod wywietlajcy ich dane bdzie ograniczaá
si do wywoáania zaledwie jednej metody! I to wáanie jest pikne :D

Mo*liwe zastosowania takiej techniki mo*na mno*yü w nieskoczonoü, za w grach jest
po prostu nieoceniona. Pomylmy tylko, *e za pomoc podobnej tablicy i prostej ptli
mo*emy wykonaü dowoln czynnoü na zestawie przeró*nych obiektów. Rysowanie,
wywietlanie, kontrola animacji - wszystko to mo*emy wykonaü poprzez jedn instrukcj!

Programowanie obiektowe

217

Niezale*nie od tego, jak bardzo byáaby rozbudowana hierarchia naszych klas (np.
jednostek w grze strategicznej, wrogów w grze RPG, i tak dalej), zastosowanie
polimorfizmu z metodami wirtualnymi upraszcza kod wikszoci operacji do podobnie
trywialnych konstrukcji jak powy*sza.
Od tej pory do nas nale*y wic tylko zdefiniowanie odpowiedniego modelu klas i ich
metod, gdy* zarzdzanie poszczególnymi obiektami staje si, jak widaü, banalne. Co
wa*niejsze, zastosowanie technik obiektowych nie tylko upraszcza kod, ale te* pozwala
na znacznie wiksz elastycznoü.

Pamitaj, *e praktyka czyni mistrza! Poznanie teoretycznych aspektów programowania
obiektowego jest wprawdzie niezbdne, ale najwicej wartociowych umiejtnoci
zdobdziesz podczas samodzielnego projektowania i kodowania programów. Wtedy
szybko przekonasz si, *e stosowanie technik polimorfizmu jest prawie *e intuicyjne -
nawet jeli teraz nie jeste zbytnio tego pewien.

Typy pod kontrol

Uniwersalny kod dla wszystkich klas w hierarchii jest bardzo wygodnym rozwizaniem.
Okazjonalnie jednak zdarza si, *e trzeba w nim uwzgldniü tak*e bardziej szczegóáowe
przypadki, co oznacza koniecznoc sprawdzania faktycznego typu obiektów, na które
wskazuj nasze wska(niki.
Na szczcie C++ oferuje proste mechanizmy, umo*liwiajce realizacj tego zadania.

Operator

dynamic_cast

Konwersja wska(nika do klasy pochodnej na wska(nik do klasy bazowej jest czynnoci
doü naturaln, wic przebiega caákowicie automatycznie. Niepotrzebne jest nawet
zastosowanie jakiej formy rzutowania. Nie powinno to wcale dziwiü - w kocu na tym
polega sama idea dziedziczenia, *e obiekt klasy potomnej jest tak*e obiektem
przynale*nym klasie bazowej.
Inaczej jest z konwersj w odwrotn stron - ta nie zawsze musi si przecie* powieü.
C++ powinien wic udostpniaü jaki sposób na sprawdzenie, czy taka zamiana jest
mo*liwa, no i na samo jej przeprowadzanie. Do tych celów sáu*y operator rzutowania

dynamic_cast

Jest to drugi z operatorów rzutowania, jakie mamy okazj poznaü. Zostaá on
wprowadzony do jzyka C++ po to, by umo*liwiü kompleksow obsáug typów
polimorficznych w zakresie konwersji „w dóá” hierarchii klas. Jego przeznaczenie jest
zatem nastpujce:

Operator

dynamic_cast

sáu*y do rzutowania wska(nika do obiektu klasy bazowej na

wska(nik do obiektu klasy pochodnej.

Powiedzielimy sobie równie*, *e taka konwersja niekoniecznie musi byü mo*liwa. Rol
omawianego operatora jest wic tak*e sprawdzanie, czy rzeczywicie mamy do czynienia
z wska(nikiem do obiektu potomnego, przechowywanym przez zmienn bdc
wska(nikiem do typu bazowego.

Uff, wszystko to wydaje si bardzo zakrcone, zatem najlepiej bdzie, je*eli przyjrzymy
si odpowiednim przykáadom. Po raz kolejny posáu*ymy si przy tym nasz ulubion
systematyk klas zwierzt i napiszemy tak oto funkcj:

#include

<stdlib.h>

// *eby u*yü rand() i srand()

#include

<ctime>

// *eby u*yü time()

IAnimal* StworzLosoweZwierze()
{

Podstawy programowania

218

// zainicjowanie generatora liczb losowych

srand

(

static_cast

unsigned

>(time(NULL)));

// wylosowanie liczby i stworzenie obiektu zwierza

switch

(rand() %

)

{

case

return

new

CFish;

case

return

new

CMammal;

case

return

new

CBird;

case

return

new

CHomeDog;

default

return

NULL;

}
}

Losuje ona liczb i na jej podstawie tworzy obiekt jednej z czterech, zdefiniowanych jaki
czas temu, klas zwierzt. Nastpnie zwraca wska(nik do niego jako wynik swego
dziaáania. Rezultat ten jest rzecz jasna typu IAnimal*, aby mógá „pomieciü” odwoáania
do jakiegokolwiek zwierzcia, dziedziczcego z klasy bazowej IAnimal.

Powy*sza funkcja jest bardzo prostym wariantem tzw. fabryki obiektów (ang. object

factory). Takie fabryki to najczciej osobne obiekty, które tworz zale*ne do siebie byty

np. na podstawie staáych wyliczeniowych, przekazywanych swoim metodom. Metody

takie mog wic zwróciü wiele ró*nych rodzajów obiektów, dlatego deklaruje si je z

u*yciem wska(ników na klasy bazowe - u nas jest to IAnimal*.

Wywoáanie tej funkcji zwraca nam wic dowolne zwierz i zdawaáoby si, *e nijak nie
potrafimy sprawdziü, do jakiej klasy ono faktycznie nale*y. Z pomoc przychodzi nam
jednak operator

dynamic_cast

, dziki któremu mo*mue spróbowaü rzutowania

otrzymanego wska(nika na przykáad do typu CMammal*:

IAnimal* pZwierze = StworzLosoweZwierze();
CMammal* pSsak =

dynamic_cast

<CMammal*>(pZwierze);

Taka próba powiedzie si jednak tylko w rednio poáowie przypadków (dlaczego?

). Co

zatem bdzie, je*eli pZwierze odnosi si do innego rodzaju zwierzt?…
Otó* w takim przypadku otrzymamy prost informacj o bádzie, mianowicie:

dynamic_cast

zwróci wska(nik pusty (o wartoci NULL), je*eli niemo*liwe bdzie

dokonanie podanego rzutowania.

Aby j wychwyciü potrzebujemy oczywicie dodatkowego warunku, porównujcego
zmienn pSsak z t specjaln wartoci NULL (bdc zreszt de facto zerem):

(pSsak != NULL)

// sprawdzenie, czy rzutowanie powiodáo si

{

// OK - rzeczywicie mamy do czynienia z obiektem klasy CMammal.

// pSsak mo*e byü tu u*yty tak samo, jak ka*dy inny wska(nik

// na obiekt klasy CMammal, na przykáad:

pSsak->Biegnij();
}

Obiekt klasy CMammal jest tworzony zarówno poprzez

new

CMammal, jak i

new

CHomeDog. Klasa CHomeDog

dziedziczy przecie* po klasie CMammal.

Programowanie obiektowe

219

Warunek

(pSsak != NULL) mo*e byü zastpiony przez

(pSsak). Wówczas

kompilator dokona automatycznej zamiany wartoci pSsak na logiczn, co da faász, je*eli
jest ona równa zeru (czyli NULL) oraz prawd w ka*dej innej sytuacji.

Mo*liwe jest nawet wiksze skondensowanie kodu. Wystarczy wstawiü linijk z

rzutowaniem bezsporednio do warunku

, tzn. zastosowaü instrukcj:

(CMammal* pSsak =

dynamic_cast

<CMammal*>(pZwierzak))

Pojedynczy znak = jest tutaj umieszczony celowo, gdy* w ten sposób caáe przypisanie

reprezentuje wynik rzutowania, który zostaje potem niejawnie przyrównany do zera.

Kontrola otrzymanego wyniku rzutowania jest konieczna; je*eli bowiem spróbowalimy
zastosowaü operator wyáuskania -> do pustego wska(nika, spowodowalibymy bád
ochrony pamici (access violation).

Nale*y wic zawsze sprawdzaü, czy rzutowanie

dynamic_cast

powiodáo si, poprzez

porównanie otrzymanego wska(nika z wartoci NULL.

I to jest w zasadzie wszystko, co nale*y wiedzieü o operatorze

dynamic_cast

Incydentalnie trafiaj si sytuacje, w których zastosowanie omawianego operatora

wymaga wáczenia specjalnej opcji kompilatora, uaktywniajcej informacje o typie

podczas dziaáania programu. S to rzadkie przypadki i prawie zawsze dotycz

wielodziedziczenia, niemniej warto wiedzieü, *e takie niespodzianki mog si czasem

przytrafiü.

Sposób wáczenia informacji o typie w czasie dziaáania programu jest opisany w

nastpnym paragrafie.

Bli*szych szczegóáow na temat rzutowania

dynamic_cast

mo*na doszukaü si w

MSDN

typeid

i informacje o typie podczas dziaáania programu

Oprócz

dynamic_cast

- operatora, który pozwala sprawdziü, czy dany wska(nik do klasy

bazowej wskazuje te* na obiekt klasy pochodnej - C++ dysponuje nieco bardziej
zaawansowanymi konstrukcjami, dostarczajcymi wiadomoci o typach obiektów i
wyra*e w programie. S to tak zwane informacje o typie czasu wykonania
(ang. Run-Time Type Information), oznaczane angielskim skrótowcem RTTI.

Znajomoü opisywanej tu czci RTTI, czyli operatora

typeid

, generalnie nie jest tak

potrzebna, jak umiejtnoü posáugiwania si operatorami rzutowania, ale daje kilka
bardzo ciekawych mo*liwoci, najczciej nieosigalnych inn drog. Mo*esz aczkolwiek
tymczasowo pominü ten paragraf, by wróciü do niego pó(niej.

Skorzystanie z RTTI wymaga podjcia dwóch wstpnych kroków:

wáczenia odpowiedniej opcji kompilatora:

Podstawy programowania

220

Screen 34, 35 i 36. Trzy kroki do wáczenia RTTI w Visual Studio .NET

W Visual Studio. NET nale*y w tym celu rozwinü zakáadk Solution Explorer,
kliknü prawym przyciskiem myszy na nazw swojego projektu i z menu
podrcznego wybraü Properties. W pojawiajcym si oknie dialogowym trzeba
teraz przejü do strony C/C++|Language i przy opcji Enable Run-Time Type Info
ustawiü wariant Yes (/GR).

doáczenia do kodu standardowego nagáówka typeinfo, czyli dodania dyrektywy:

#include

W zamian za te wysiáki otrzymamy mo*liwoü korzystania z operatora

typeid

pobierajcego informacj o typie podanego mu wyra*enia. Skáadnia jego u*ycia jest
nastpujca:

typeid

(wyra*enie).informacja

Faktycznie instrukcja

typeid

(wyra*enie) zwraca struktur, nale*c do wbudowanego

typu std::type_info. Struktura ta opisuje typ wyra*enia i zawiera takie oto skáadowe:

informacja

opis

name()

Jest to nazwa typu w czytelnej i przyjaznej dla czáowieka formie. Mo*emy

j przechowywaü i operowaü ni tak, jak ka*dym innym napisem. Przykáad:

#include

#include

#include

<ctime>

int

nX =

;

float

fY =

3.14

;

time_t Czas = time(NULL); tm Data = *localtime(&Czas);

std::cout <<

typeid

(nX).name();

// wynik: "int"

std::cout <<

typeid

(fY).name();

// wynik: "float"

std::cout <<

typeid

(Data).name();

// wynik: "struct tm"

raw_name()

Zwraca nazw typu wewntrznie u*ywan przez kompilator. Taka nazwa

musi byü unikalna, dlatego zawiera ró*ne „dekoracyjne” znaki, jak ? czy @.

Nie jest czytelna dla czáowieka, ale mo*e ewentualnie sáu*yü w celach

porównawczych.

Tabela 11. Informacje dostpne poprzez operator

typeid

Oprócz pobierania nazwy typu w postaci cigu znaków mo*emy u*ywaü operatorów ==
oraz != do porównywania typów dwóch wyra*e, na przykáad:

unsigned

uX;

if (

typeid

(uX) ==

typeid

(

unsigned

))

std::cout

"wietnie, nasz kompilator dziaáa ;D"

;

if (

typeid

(uX) !=

typeid

(uX /

0.618

))

std::cout

"No prosz, tutaj te* jest dobrze :)"

;

typeid

mógáby wic sáu*yü nam do sprawdzania klasy, do której nale*y polimorficzny

obiekt wskazywany przez wska(nik. Sprawd(my zatem, jak by to mogáo wygldaü:

IAnimal* pZwierze =

new

CBird;

std::cout <<

typeid

(pZwierze).name();

Po wykonaniu tego kodu spotka nas raczej przykra niespodzienka - zamiast
oczekiwanego rezultatu

"class CBird *"

otrzymamy

"class IAnimal *"

! Wyglda na

Programowanie obiektowe

221

to, *e faktyczny typ obiektu, do którego odwoáuje si pZwierze, nie zostaá w ogóle wzity
pod uwag.
Przypuszczenia te s sáuszne. Otó*

typeid

jest „leniwym” operatorem i zawsze idzie po

najmniejszej linii oporu. Typ wyra*enia pZwierze mógá za okreliü nie sigajc nawet do
mechanizmów polimorficznych, poniewa* wyra(nie zadeklarowalimy go jako IAnimal*.
Aby zmusiü krnbrny operator do wikszego wysiáku, musimy mu podaü sam obiekt, a
nie wska(nik na niego, co czynimy w ten sposób:

std::cout <<

typeid

(*pZwierze).name();

O wystpujcym tu operatorze dereferencji - gwiazdce (*) powiemy sobie bli*ej, gdy
przejdziemy do dokáadnego omawiania wska(ników jako takich. Na razie zapamitaj, *e
przy jego pomocy „wyáawiamy” obiekt poprzez wska(nik do niego.
Naturalnie, teraz powy*szy kod zwróci prawidáowy wynik

"class CBird"

Peány opis operatora

typeid

znajduje si oczywicie w

MSDN

Alternatywne rozwizania

RTTI jest czsto zbyt ci*k armat, wytoczon przeciw problemowi pobierania informacji
o klasie obiektu podczas dziaáania aplikacji. Przy niewielkim nakáadzie pracy mo*na
samemu wykonaü znacznie mniejszy, acz nierzadko wystarczajcy system.

Po co? Decydujcym argumentem mo*e byü szybkoü. Wbudowane mechanizmy RTTI,
jak

dynamic_cast

typeid

, s dosyü wolne (szczególnie dotyczy to tego pierwszego).

Wáasne, bardziej porczne rozwizanie mo*e mieü spory wpáyw na wydajnoü.

Do tego celu mog posáu*yü metody wirtualne oraz odpowiedni typ wyliczeniowy,
posiadajcy list wartoci odpowiadajcych poszczególnym klasom. W przypadku naszych
zwierzt mógáby on wygldaü na przykáad tak:

enum

ANIMAL { A_BASE,

// bazowa klasa IAnimal

A_FISH,

// klasa CFish

A_MAMMAL,

// klasa CMammal

A_BIRD,

// klasa CBird

A_HOMEDOG

};

// klasa CHomeDog

Teraz wystarczy tylko zdefiniowaü proste metody wirtualne, które bd zwracaáy staáe
wáaciwe swoim klasom:

// (pomináem pozostaáe skáadowe klas)

class

IAnimal

{

public

virtual

ANIMAL Typ()

const

{

return

A_BASE; }

};

// ----------------------bezporednie pochodne --------------------------

class

CFish :

public

IAnimal

{

public

ANIMAL

Typ()

const

{

return

A_FISH: }

};

class

CMammal :

public

IAnimal

{

Podstawy programowania

222

public

ANIMAL

Typ()

const

{

return

A_MAMMAL; }

};

class

CBird :

public

IAnimal

{

public

ANIMAL

Typ()

const

{

return

A_BIRD; }

};

// ----------------------- porednie pochodne ----------------------------

class

CHomeDog :

public

CMammal

{

public

ANIMAL

Typ()

const

{

return

A_HOMEDOG; }

};

Po zastosowaniu tego rozwizania mo*emy chocia*by u*yü instrukcji

switch

, by wykonaü

kod zale*ny od typu obiektu:

IAnimal* pZwierzak = StworzLosoweZwierze();

switch

(pZwierzak->Typ())

{

case

A_FISH:

static_cast

<CFish*>(pZwierzak)->Plyn();

break

;

case

A_BIRD:

static_cast

<CBird*>(pZwierzak)->Lec();

break

;

case

A_MAMMAL:

static_cast

<CMammal*>(pZwierzak)->Biegnij();

break

;

case

A_HOMEDOG:

static_cast

<CHomeDog*>(pZwierzak)->Szczekaj();

break

;

}

Podobne sprawdzenie, dokonywane przy u*yciu

dynamic_cast

lub

typeid

, wymagaáoby

wielopitrowej instrukcji

. Tutaj wystarczy bardziej naturalny

switch

, za do

formalnego rzutowania mo*emy u*yü prostego

static_cast

, które dziaáa szybciej ni*

mechanizmy RTTI.

Trzeba jednak pamitaü, *e aby bezpiecznie stosowaü

static_cast

do rzutowania w dóá

hierarchii klas, musimy mieü pewnoü, *e taka operacja jest faktycznie wykonalna. Tutaj
sprawdzamy rzeczywisty typ obiektu

, zatem wszystko jest w porzdku, lecz w innych

przypadkach nale*y skorzystaü z

dynamic_cast

Systemy identyfikacji i zarzdzania typami, podobne do powy*szego, s w praktyce
u*ywane bardzo czsto, szczególnie w wielkich projektach. Najbardziej zaawansowane
warianty umo*liwiaj nawet tworzenie obiektów na podstawie nazwy klasy
przechowywanej jako napis lub te* dynamiczne odtworzenie hierarchii klas podczas
dziaáania programu. Trzeba jednak przyznaü, i* jest to nierzadko sztuka dla samej sztuki,
bez wielkiego praktycznego znaczenia.

„Równowaga przede wszystkim” - pamitajmy t sentencj :D

***

Gratulacje! Wáanie poznaáe wszystkie teoretyczne zaáo*enia programowania
obiektowego i ich praktyczn realizacj w C++. Wykorzystujc zdobyt wiedz, bdziesz
mógá efektywnie programowaü aplikacje z u*yciem filozofii OOP.

Sprawdzenie przy u*yciu

typeid

tak*e upowa*niaáoby nas do stosowania

static_cast

podczas rzutowania.

Programowanie obiektowe

223

Sáucham? Mówisz, *e to wcale nie jest takie proste? Zgadza si, na pocztku mylenie w
kategoriach obiektowych mo*e rzeczywicie sprawiaü ci trudnoci. Pomylaáem wic, *e
dobrze bdzie powiciü nieco czasu tak*e na zagadnienia zwizane z samym
projektowaniem aplikacji z u*yciem poznanych technik. Zajmiemy si tym w
nadchodzcym podrozdziale.

Projektowanie zorientowane obiektowo

A miaáo byü tak piknie… Programowanie obiektowe miaáo byü przecie* wyjtkowo
naturalnym sposobem kodowania, a poprzednie paragrafy raczej nie bardzo o tym
przekonywaáy, prawda? Je*eli rzeczywicie odnosisz takie wra*enie, to byü mo*e
zwyczajnie utonáe w powodzi szczegóáów, dodajmy - niezbdnych szczegóáów,
koniecznych do stosowania OOPu w praktyce. Czas jednak wypáynü na powierzchni i
ponownie spojrzeü na zagadnienie bardziej caáociowo. Temu celowi bdzie sáu*yü
niniejszy podrozdziaá.

Wiele podrczników opisujcych programowanie obiektowe (czy nawet programowanie
jako takie) wspomina skpo, je*eli w ogóle, o praktycznym stosowaniu prezentowanych
mechanizmów, czyli po prostu o projektowaniu aplikacji z u*yciem omawianych technik.
Mo*naby to wybaczyü tym publikacjom, których gáównym celem jest „jedynie” kompletny
opis danego jzyka. Je*eli jednak mówimy o materiaáach dla caákiem pocztkujcych,
bdcych w zaáo*eniu wprowadzeniem w wiat programowania, wtedy zdecydowanie
niewskazane jest pomijanie praktycznych stron projektowania i kodowania aplikacji. Na
co bowiem przyda si znajomoü budowy máotka, jeli nie uáatwi to zadania, jakim jest
wbicie gwo(dzia? :)

Staram si wic uniknü tego bádu i przedstawiam programowanie obiektowe tak*e od
strony programisty-praktyka. Mam jednoczenie nadziej, *e w ten sposób przynajmniej
czciowo uchroni ci przed wywa*aniem otwartych drzwi w poszukiwaniu informacji w
gruncie rzeczy oczywistych - które jednak wcale takie nie s, gdy si ich nie posiada.
Naturalnie, nic nie zastpi dowiadczenia zdobytego samodzielnie podczas prawdziwego
kodowania. Prezentowana tutaj wiedza teoretyczno-praktyczna mo*e byü jednak bardzo
pomocnym punktem startowym, uáatwiajcym koderskie *ycie przynajmniej na jego
pocztku.
Có* wic znajdziemy w aktualnym podrozdziale? )aáuj, ale nie bdzie to przegld
kolejnych kroków, jakie nale*y czyniü programujc konkretn aplikacj. Zamiast na mniej
lub bardziej trywialnym programiku skoncentrujemy si raczej na ogólnym procesie
budowania wewntrznej, obiektowej struktury programu - czyli na tak zwanym
modelowaniu klas i ich zwizków. Najpierw poznamy zatem trzy podstawowe rodzaje
obiektów albo, jak kto woli, ról, w których one wystpuj. Dalej zajmiemy si kwesti
definiowania odpowiednich klas - ich interfejsu i implementacji, a wreszcie zwizkami
pomidzy nimi, dziki którym programy stworzone wedáug zasad OOPu mog poprawnie
funkcjonowaü.

Znajomoü powy*szego zestawu zagadnie powinna znacznie poprawiü twoje szanse w
starciu z problemami projektowymi, zwizanymi z programowaniem obiektowym. Byü
mo*e ich rozwizywanie nie bdzie ju* wówczas wiedz tajemn, ale normaln i, co
wa*niejsze, satysfakcjonujc czci pracy kodera.
Nie przedáu*ajc ju* wicej zacznijmy zatem wáaciw treü tego podrozdziaáu.

Rodzaje obiektów

Ka*dy program zawiera w mniejszej lub wikszej czci nowatorskie rozwizania,
stanowice gáówne wyzwanie stojce przed jego twórc. Niemniej jednak pewne cechy

Podstawy programowania

224

prawie zawsze pozostaj staáe - a do nich nale*y tak*e podziaá obiektów skáadowych
aplikacji na trzy fundamentalne grupy.

Podziaá ten jest bardzo ogólny i niezbyt sztywny, ale przez to stosuje si w zasadzie do
ka*dego projektu. Bdzie on zreszt punktem wyjcia dla nieco bardziej szczegóáowych
kwestii, opisanych pó(niej.
Pomówmy wic kolejno o ka*dym rodzaju z owej podstawowej trójki.

Singletony

Wikszoü obiektów jest przeznaczonych do istnienia w wielu egzemplarzach, ró*nicych
si przechowywanymi danymi, lecz wykonujcych te same dziaáania poprzez metody.
Istniej jednak*e wyjtki od tej reguáy, a nale* do nich wáanie singletony.

Singleton (‘jedynak’) to klasa, której jedyna instancja (obiekt) speánia kluczow rol w
caáym programie.

W danym momencie dziaáania aplikacji istnieje wic co najwy*ej jeden egzemplarz
klasy, bdcej singletonem.

Obiekty takie s dosáownie jedyne w swoim rodzaju i dlatego zwykle przechowuj one
najwa*niejsze dane programu oraz wykonaj wikszoü newralgicznych czynnoci.
Najczciej s te* „rodzicami” i wáacicielami pozostaáych obiektów.
W jakich sytuacjach przydaj si takie twory? Otó* je*eli podzielilibymy nasz projekt na
jakie skáadowe (sposób podziaáu jest zwykle spraw mocno subiektywn), to dobrymi
kandydatami na singletony byáyby przede wszystkim te skáadniki, które obejmowaáyby
najszerszy zakres funkcji. Mo*e to byü obiekt aplikacji jako takiej albo te*
reprezentacje poszczególnych podsystemów - w grach byáyby to: grafika, d(wik, sieü,
AI, itd., w edytorach: moduáy obsáugi plików, dokumentów, formatowania itp.

Niekiedy zastosowanie singletonów wymuszaj warunki zewntrzne, np. jakie

dodatkowe biblioteki, u*ywane przez program. Tak jest chocia*by w przypadku funkcji

Windows API odpowiedzialnych za zarzdzanie oknami.

Siá rzeczy singletony stanowi te* „punkty zaczepienia” dla caáego modelu klas, gdy* ich
pola s w wikszoci odwoáaniami do innych obiektów: niekiedy do wielu drobnych, ale
czciej do kilku kolejnych zarzdców, czyli nastpnego, ni*szego poziomu hierarchii
zawierania si obiektów.

O relacji zawierania si (agregacji) bdziemy jeszcze szerzej mówiü.

Przykáady wykorzystania

Najbardziej oczywistym przykáadem singletonu mo*e byü caáociowy obiekt programu,
a wic klasa w rodzaju CApplication czy CGame. Bdzie ona nadrzdnym obiektem
wobec wszystkich innych, a tak*e przechowywaáa bdzie globalne dane dotyczce
aplikacji jako caáoci. To mo*e byü chocia*by cie*ka do jej katalogu, ale tak*e kluczowe
informacje otrzymane od bibliotek Windows API, DirectX czy jakichkolwiek innych.

Je*eli chodzi o inne mo*liwe singletony, to z pewnoci bd to zarzdcy poszczególnych
moduáów; w grach s to obiekty klas o tak wiele mówicych nazwach jak
CGraphicsSystem, CSoundSystem, CNetworkSystem itp., podobne twory mo*na te*
wyró*niü w programach u*ytkowych.
Wszystkie te klasy wystpuj w pojedynczych instancjach, gdy* unikatowa jest ich rola.
Kwesti otwart jest natomiast ich ewentualna podlegáoü najbardziej nadrzdnemu
obiektowi aplikacji - na przykáad w ten sposób:

Programowanie obiektowe

225

class

CGame

{

private

CGraphicsSystem*

m_pGFX;

CSoundSystem*

m_pSFX;

CNetworkSystem*

m_pNet;

itd.

(reszt skáadowych pominiemy)

};

// jedna jedyna instancja powy*szej klasy

extern

CGame* g_pGra;

Równie dobrze mog byü bowiem samodzielnymi obiektami, dostpnymi poprzez swoje
wáasne zmienne globalne - bez porednictwa obiektu gáównego. Obydwa podejcia s w
zasadzie równie dobre (mo*e z lekkim wskazaniem na pierwsze, jako *e nie zapewnia
takiej swobody w dostpie do podsystemów z zewntrz).

Dlaczego jednak w ogóle stosowaü singletony, je*eli i tak bd one tylko pojedynczymi
kopiami swoich pól? Przecie* podobne efekty mo*na uzyskaü stosujc zmienne globalne
oraz zwyczajne funkcje w miejsce pól i metod takiego obiektu-jedynaka.
To jednak tylko czü prawdy. Namno*enie zmiennych i funkcji poza zasadnicz,
obiektow struktur programu narusza zasady OOPu, i to a* podwójnie. Po pierwsze, nie
unikniemy w ten sposób wyra(nego oddzielenia danych od kodu, a po drugie nie
zapewnimy im ochrony przed niepowoáanym dostpem, co zwiksza ryzyko bádów.
Wreszcie, mieszamy wtedy dwa style programowania, a to nieuchronnie prowadzi do
baáaganu w kodzie, jego niespójnoci, trudnoci w rozbudowie i konserwacji oraz caáej
rzeszy innych plag, przy których te egipskie mog zdawaü si dziecinn igraszk ;D

U*ywanie singletonów jest zatem nieodzowne. Przydaáoby si wic znale(ü jaki dobry
sposób ich implementacji, bo chyba domylasz si, *e zwykáe zmienne globalne nie s
tutaj szczytem marze. No, a jeli nawet nie zastanowiáe si nad tym, to wáanie masz
precedens porównawczy - przedstawi bowiem nieco lepsz drog na realizacj pomysáu
pojedynczych obiektów w C++.

Praktyczna implementacja z u*yciem skáadowych statycznych

Nawet najlepszy pomysá nie jest zbyt wiele wart, je*eli nie mo*na jego skutków zobaczyü
w dziaáaniu. Singletony mo*na na szczcie zaimplementowaü a* na kilka sposobów,
ró*nicych si wygod i bezpieczestwem.

Najprostszy, z wykorzystaniem globalnego wska(nika na obiekt lub globalnej zmiennej
obiektowej, posiada kilka wad, zwizanych przede wszystkim z kontrol nad tworzeniem
oraz niszczeniem obiektu. Dlatego lepiej zastosowaü tutaj inne rozwizanie, oparte na
skáadowych statycznych klas.

Statyczne skáadowe s przypisane do klasy jako caáoci, a nie do jej poszczególnych
instancji (obiektów).

Deklarujemy je przy pomocy sáowa kluczowego

static

. Wówczas peáni wic ono inn

funkcj ni* ta, któr znalimy dotychczas.

Pamitajmy, *e zmienne zadeklarowane w pliku nagáówkowym z u*yciem

extern

wymagaj jeszcze

przydzielenia do odpowiedniego moduáu kodu poprzez deklaracj bez wspomnianego sáówka. Powy*szy sposób
nie jest zreszt najlepsz metod na zaimplementowanie singletonu - bardziej odpowiedni poznamy za chwil.

Podstawy programowania

226

Podstawow cech skáadowych statycznych jest to, *e do skorzystania z nich nie jest
potrzebny *aden obiekt macierzystej klasy. Odwoáujemy si do nich, podajc po prostu
nazw klasy oraz oznaczenie skáadowej, w ten oto sposób:

nazwa_klasy::skáadowa_statyczna

Mo*liwe jest tak*e tradycyjne u*ycie obiektu danej klasy lub wska(nika na niego oraz
operatorów wyáuskania . lub ->. We wszystkich przypadkach efekt bdzie ten sam.
Musimy jakkolwiek pamitaü, *e nadal obowizuj tutaj specyfikatory praw dostpu, wic
jeli powy*szy kod umiecimy poza metodami klasy, to bdzie on poprawny tylko dla
skáadowych zadeklarowanych jako

public

Bli*sze poznanie statycznych elementów klas wymaga rozró*nienia sporód nich pól i
metod. Dziaáanie modyfikatora

static

jest bowiem nieco inne dla danych oraz dla kodu.

I tak statyczne pola s czym w rodzaju zmiennych globalnych dla klasy. Mo*na si do
nich odwoáywaü z ka*dej metody, a tak*e z klas pochodnych i/lub z zewntrz - zgodnie ze
specyfikatorami praw dostpu. Ka*de odniesienie do statycznego pola bdzie jednak
dostpem do tej samej zmiennej, rezydujcej w tym samym miejscu pamici. W
szczególnoci poszczególne obiekty danej klasy nie bd posiadaáy wáasnej kopii takiego
pola, bo bdzie ono istniaáo tylko w jednym egzemplarzu.
Podobiestwo do zmiennych globalnych przejawia si w jeszcze jednym aspekcie:
mianowicie statyczne pola musz zostaü w podobny sposób przydzielone do którego z
moduáów kodu w programie. Ich deklaracja w klasie jest bowiem odpowiednikiem
deklaracji

extern

dla zwykáych zmiennych. Odpowiednia definicja w module wyglda za

nastpujco:

typ nazwa_klasy::nazwa_pola [= wartoü_pocztkowa];

Kwalifikatora nazwa_klasy:: mo*emy tutaj wyjtkowo u*yü nawet wtedy, kiedy nasze
pole nie jest publiczne. Spostrze*my te*, i* nie korzystamy ju* ze sáowa

static

, jako *e

poza definicj klasy ma ono odmienne znaczenie.

Statycznoü metod polega natomiast na ich niezale*noci od jakiegokolwiek obiektu
danej klasy. Metody opatrzone kwalifikatorem

static

mo*emy bowiem wywoáywaü bez

koniecznoci posiadania instancji klasy. W zamian za to musimy jednak
zaakceptowaü fakt, i* nie posiadamy dostpu do wszelkich niestatycznych skáadników
(zarówno pól, jak i metod) naszej klasy. To aczkolwiek doü naturalne: jeli wywoáanie
funkcji statycznej mo*e obejü si bez obiektu, to skd moglibymy go wziü, aby
skorzystaü z niestatycznej skáadowej, która przecie* takiego obiektu wymaga? Otó*
wáanie nie mamy skd, gdy* w metodach statycznych nie jest dostpny wska(nik

this

, reprezentujcy aktualny obiekt klasy.

No dobrze, ale w jaki sposób statyczne skáadowe klas mog nam pomóc w implementacji
singletonów?… Có*, to dosyü proste. Zauwa*, *e takie skáadowe s unikalne w skali caáej
klasy - tak samo, jak unikalny jest pojedynczy obiekt singletonu. Mo*emy zatem u*yü
ich, by sprawowaü kontrol nad naszym jedynym i wyjtkowym obiektem.
Najpierw zadeklarujemy wic statyczne pole, którego zadaniem bdzie przechowywanie
wska(nika na ów kluczowy obiekt:

// *** plik nagáówkowy ***

// klasa singletonu

class

CSingleton

{

private

Programowanie obiektowe

227

// statyczne pole, przechowujce wska(nik na nasz jedyny obiekt

static

CSingleton* ms_pObiekt;

// (tutaj bd dalsze skáadowe klasy)

};

// *** moduá kodu ***
// trzeba rzecz jasna doáczyü tutaj nagáówek z definicj klasy

// inicjujemy pole wartoci zerow (NULL)

CSingleton* CSingleton::ms_pObiekt = NULL;

Deklaracj pola umiecilimy w sekcji

private

, aby chroniü je przed niepowoáan

zmian. W takiej sytuacji potrzebujemy jednak metody dostpowej do niego, która
zreszt tak*e bdzie statyczna:

// *** wewntrz klasy CSingleton ***

public

static

CSingleton* Obiekt()

{

// tworzymy obiekt, je*eli jeszcze nie istnieje

// (tzn. jeli wska(nik ms_pObiekt ma pocztkow wartoü NULL)

(ms_pObiekt == NULL) CSingleton();

// zwracamy wska(nik na nasz obiekt

return

ms_pObiekt;

}

Oprócz samego zwracania wska(nika metoda ta sprawdza, czy *dany przez nasz obiekt
faktycznie istnieje; je*eli nie, jest tworzony. Jego kreacja nastpuje wic przy pierwszym
u*yciu.
Odbywa si ona poprzez bezporednie wywoáanie konstruktora… którego na razie nie
mamy (jest domylny)! Czym prdzej naprawmy zatem to niedopatrzenie, przy okazji
definiujc tak*e destruktor:

// *** wewntrz klasy CSingleton ***

private

CSingleton()

{ ms_pObiekt =

this

; }

public

~CSingleton()

{ ms_pObiekt = NULL; }

Spore zdziwienie mo*e budziü niepublicznoü konstruktora. W ten sposób jednak
zabezpieczamy si przed utworzeniem wicej ni* jednej kopii naszego singletonu.
Uprawniona do wywoáania prywatnego konstruktora jest bowiem tylko skáadowa klasy,
czyli metoda CSingleton::Obiekt(). Wszelkie zewntrzne próby stworzenia obiektu
klasy CSingleton zakocz si wic bádem kompilacji, za jedyny jego egzemplarz
bdzie dostpny wyácznie poprzez wspomnian metod.

Powy*szy sposób jest zatem odpowiedni dla obiektu stojcego na samym szczycie

hierarchii w aplikacji, a wic dla klas w rodzaju CApplication, CApp czy CGame. Je*eli za

chcemy mieü wygodny dostp do obiektów le*cych ni*ej, zawartych wewntrz innych,

wtedy nie mo*emy oczywicie uczyniü konstruktora prywatnym. Wówczas warto wic

skorzystaü z innych rozwiza, których jednak nie chciaáem tutaj przedstawiaü ze

Przedrostek s_ wskazuje, *e dana zmienna jest statyczna. Tutaj zostaá on poáczony ze zwyczajowym m_,

dodawanym do nazw prywatnych pól.

Podstawy programowania

228

wzgldu koniecznoü znacznie wikszej znajomoci jzyka C++ do ich poprawnego

zastosowania

Musimy jeszcze pamitaü, aby usunü obiekt, gdy ju* nie bdzie nam potrzebny - robimy
to w zwyczajny sposób, poprzez operator

delete

CSingleton::Obiekt();

To konieczne - skoro chcemy zachowaü kontrol nad tworzeniem obiektu, to musimy
tak*e wziü na siebie odpowiedzialnoü za jego zniszczenie.

Na koniec wypadaáoby zastanowiü si, czy stosowanie powy*szego rozwizania (albo
podobnych, gdy* istnieje ich wicej) jest na pewno konieczne. Byü mo*e sdzisz, *e
mo*na si spokojnie bez nich obyü - i chwilowo masz rzeczywicie racj! Kiedy nasze
programy s zdeterminowane od pocztku do koca, zawarte w caáoci w funkcji main(),
á

atwo jest zapanowaü nad *yciem singletonu. Gdy jednak rozpoczniemy programowaü

aplikacje okienkowe dla Windows, sterowane zewntrznymi zdarzeniami, wtedy przebieg
programu nie bdzie ju* taki oczywisty. Powy*szy sposób na implementacj singletonu
bdzie wówczas znacznie u*yteczniejszy.

Obiekty zasadnicze

Drugi rodzaj obiektów skupia te, które stanowi najwikszy oraz najwa*niejszy fragment
modelu w ka*dym programie. Obiekty zasadnicze s jego *ywotn tkank, wykonujc
wszelkie zadania przewidziane w aplikacji.

Obiekty zasadnicze to gáówny budulec programu stworzonego wedáug zasad OOP.
Wchodzc w zale*noci midzy sob oraz przekazujc dane, realizuj one wszystkie
funkcje aplikacji.

Budowanie sieci takich obiektów jest wic lwi czci procesu tworzenia obiektowej
struktury programu. Definiowanie odpowiednich klas, zwizków midzy nimi, korzystanie
z dziedziczenia, metod wirtualnych i polimorfizmu - wszystko to dotyczy wáanie obiektów
zasadniczych. Zagadnienie ich wáaciwego stosowania jest zatem niezwykle szerokie -
zajmiemy si nim dokáadniej w kolejnych paragrafach tego podrozdziaáu.

Obiekty narzdziowe

Ostatnia grupa obiektów jest oczkiem w gáowie programistów, zajmujcych si jedynie
„klepaniem kodu” wedle projektu ustalonego przez kogo innego. Z kolei owi projektanci
w ogóle nie zajmuj si nimi, koncentrujc si wyácznie na obiektach zasadniczych.
W swojej karierze jako twórcy oprogramowania bdziesz jednak czsto wcielaá si w obie
role, dlatego znajomoü wszystkich rodzajów obiektów z pewnoci oka*e si pomocna.

Czym wic s obiekty nale*ce do opisywanego rodzaju? Naturalnie, najlepiej wyjani to
odpowiednia definicja :D

Obiekty narzdziowe, zwane te* pomocniczymi lub konkretnymi

, reprezentuj

pewien nieskomplikowany typ danych. Zawieraj pola sáu*ce przechowywaniu jego
danych oraz metody do wykonywania na prostych operacji.

Jeden z najlepszych sposobów zostaá opisany w rozdziale 1.3, Automatyczne singletony, ksi*ki Pereáki

programowania gier, tom 1.

Autorem tej ostatniej, dziwnej nazwy jest Bjarne Stroustrup i tylko dlatego j tutaj podaj :)

Programowanie obiektowe

229

Nazwa tej grupy obiektów dobrze oddaje ich rol: s one tylko pomocniczym
konstrukcjami, uáatwiajcymi realizacj niektórych algorytmów. Czsto zreszt traktuje
si je podobnie jak typy podstawowe - zwáaszcza w C++.

Obiekty narzdziowe posiadaj wszak*e kilka znaczacych cech:

istniej same dla siebie i nie wchodz w interakcje z innymi, równolegle
istniejcymi obiektami. Mog je wprawdzie zawieraü w sobie, ale nie komunikuj
si samodzielnie z otoczeniem

ich czas *ycia jest ograniczony do zakresu, w którym zostaáy zadeklarowane.
Zazwyczaj tworzy si je poprzez zmienne obiektowe, w takiej te* postaci (a nie
poprzez wska(niki) zwracaj je funkcje

nierzadko zawieraj publiczne pola, je*eli mo*liwe jest ich bezpieczne ustawianie
na dowolne wartoci. W takim wypadku typy narzdziowe definiuje si zwykle
przy u*yciu sáowa

struct

, gdy* uwalnia to od stosowania specyfikatora

public

który w typach strukturalnych jest domylnym (w klasach, definiowanych poprzez

class

, domylne prawa to

private

; poza tym oba sáowa kluczowe niczym si od

siebie nie ró*ni)

posiadaj najczciej kilka konstruktorów, ale ich przeznaczenie ogranicza si
zazwyczaj do wstpnego ustawienia pól na wartoci podane w parametrach.
Destruktory s natomiast rzadko u*ywane - zwykle wtedy, gdy obiekt sam alokuje
dodatkow pamiü i musi j zwolniü

metody obiektów narzedziowych s zwykle proste obliczeniowo i krótkie w zapisie.
Ich implementacja jest wic umieszczana bezporednio w definicji klasy.
Bezwzgldnie stosuje si te* metody staáe, je*eli jest to mo*liwe

obiekty nale*ce do opisywanego rodzaju prawie nigdy nie wymagaj u*ycia
dziedziczenia, a wic tak*e metod wirtualnych i polimorfizmu

je*eli ma to sens, na rzecz tego rodzaju obiektów dokonywane jest
przeáadowywanie operatorów, aby mogáy byü u*yte w stosunku do nich. O tej
technice programistycznej bdziemy mówiü w jednym z dalszych rozdziaáów

nazewnictwo klas narzdziowych jest zwykle takie samo, jak normalnych typów
sklarnych. Nie stosuje si wic zwyczajowego przedrostka C, a caá nazw
zapisuje t sam wielkoci liter - maáymi (jak w Bibliotece Standardowej C++)
lub wielkimi (wedáug konwencji Microsoftu)

Bardzo wiele typów danych mo*e byü reprezentowanych przy pomocy odpowiednich
obiektów narzdziowych. Z jednym z takich obiektów masz zreszt stale do czynienia:
jest nim typ std::string, bdcy niczym innym jak wáanie klas, której rol jest
odpowiednie „opakowanie” áacucha znaków w przyjazny dla programisty interfejs.

Takie obudowywanie nazywamy enkapsulacj.

Klasa ta jest tak*e czci Standardowej Biblioteki Typów C++, któr poznamy
szczegóáowo po zakoczeniu nauki samego jzyka. Nale* do niej tak*e inne typy, które
z pewnoci mo*emy uznaü za narzdziowe, jak na przykáad std::complex,
reprezentujcy liczb zespolon czy std::bitset, bdcy cigiem bitów.
Matematyka dostarcza zreszt najwikszej liczby kandydatów na potencjalne obiekty
narzdziowe. Wystarczy pomyleü o wektorach, macierzach, punktach, prostoktach,
prostych, powierzchniach i jeszcze wielu innych pojciach. Nie s one przy tym jedynie
obrazowym przykáadem, lecz niedzownym elementem programowania - gier w
szczególnoci. Wikszoü bibliotek zawiera je wic gotowe do u*ycia; sporo programistów
definiuje dla jednak wáasne klasy.

Zobaczmy zatem, jak mo*e wygldaü taki typ w przypadku trójwymiarowego wektora:

#include

<cmath>

struct

VECTOR3

Podstawy programowania

230

{

wspóárzdne wektora

float

x, y, z;

// -------------------------------------------------------------------

konstruktory

VECTOR3()

{ x = y = z =

0.0

; }

VECTOR3(

float

fX,

float

fY,

float

fZ)

{ x = fX; y = fY; z = fZ; }

// -------------------------------------------------------------------

metody

float

Dlugosc()

const

{

return

sqrt(x * x + y * y + z * z); }

void

Normalizuj()

{

float

fDlugosc = Dlugosc();

// dzielimy ka*d wspóárzdn przez dáugoü

x /= fDlugosc; y /= fDlugosc; z /= fDlugosc;

}

// -------------------------------------------------------------------

// tutaj mo*na by si pokusiü o przeáadowanie operatorów +, -, *, /,

// =, +=, -=, *=, /=, == i != tak, *eby przy ich pomocy wykonywaü

dziaáania na wektorach. Poniewa* na razie tego nie umiemy, wic

// musimy z tym poczekaü :)

};

Najwicej kontrowersji wzbudza pewnie to, *e pola x, y, z s publicznie dostpne. Ma to
jednak solidne uzasadnienie: ich zmiana jest rzecz naturaln dla wektora, za zakres
dopuszczalnych wartoci nie jest niczym ograniczony (mog nimi byü dowolne liczby
rzeczywiste). Ochrona, któr zwykle zapewniamy przy pomocy metod dostpowych,
byáaby zatem niepotrzebnym porednikiem.
U*ycie powy*szej klasy/struktury (jak kto woli…) wymaga oczywicie utworzenia jej
instancji. Przy prostym zestawie danych, jaki ona reprezentuje, nie potrzeba jednak
powicaü pieczoáowitej uwagi na tworzenie i niszczenie obiektów, zatem wystarcz nam
zwykáe zmienne obiektowe zamiast wska(ników. Nawet wicej - mo*emy potraktowaü
VECTOR3 identycznie jak typy wbudowane i napisaü na przykáad funkcj obliczajc oba
rodzaje iloczynów wektorów:

float

IloczynSkalarny(VECTOR3 vWektor1, VECTOR3 vWektor2)

{

// iloczyn skalarany jest sum iloczynów odpowiednich wspóárzdnych

// obu wektorów

return

(vWektor1.x * vWektor2.x

+ vWektor1.y * vWektor2.y

+ vWektor1.z * vWektor2.z);

}

VECTOR3 IloczynWektorowy(VECTOR3 vWektor1, VECTOR3 vWektor2)
{
VECTOR3

vWynik;

// iloczyn wektorowy ma za to bardziej skomplikowan formuák :)

vWynik.x = vWektor1.y * vWektor2.z - vWektor2.y * vWektor1.z;

vWynik.y = vWektor2.x * vWektor1.z - vWektor1.x * vWektor1.z;

vWynik.z = vWektor1.x * vWektor2.y - vWektor2.x * vWektor1.y;

Programowanie obiektowe

231

return

vWynik;

}

Te operacje maj zreszt niezliczone zastosowania w programowaniu trójwymiarowych
gier, zatem ich implementacja ma gáboki sens :)

Spokojnie mo*emy w tych funkcjach pobieraü i zwracaü obiekty typu VECTOR3. Koszt
obliczeniowy tych dziaáa bdzie bowiem niemal taki sam, jak dla pojedynczych liczb.

W przypadku parametrów funkcji stosujemy jednak referencje, które optymalizuj kod,

uwalniajc od przekazania nawet tych skromnych kilkunastu bajtów. Zapoznamy si z

nimi w nastpnym rozdziale.

à

acuchy znaków czy wymysáy matematyków to nie s naturalnie wszystkie koncepcje,

które mo*na i trzeba realizowaü jako obiekty narzdziowe. Do innych nale* chocia*by
wszelkie reprezentacje daty i czasu, kolorów, numerów o okrelonym formacie oraz
wszystkie pozostaáe, nieelementarne typy danych.

Szczególnym przypadkiem obiektów pomocniczych s tak zwane inteligentne wska(niki

(ang. smart pointers). Ich zadaniem jest zapewnienie dodatkowej funkcjonalnoci

zwykáym wska(nikom - obejmuje to na przykáad zwolnienie wskazywanej przez nie

pamici w sytuacjach wyjtkowych czy te* zliczanie odwoáa do „opakowanych” nimi

obiektów.

Definiowanie odpowiednich klas

Tworzenie obiektowego modelu programu przebiega zwykle dwuetapowo. Jednym z
zada jest identyfikacja klas, które bd si na skáadaáy, oraz pól i metod, które zostan
zawarte w ich definicjach. Drugim jest okrelenie zwizków pomidzy tymi klasami,
dziki którym aplikacja mogáaby realizowaü zaplanowane czynnoci.
Przestrzeganie powy*szej kolejnoci nie jest cile konieczne. Oczywicie, majc ju* kilka
zdefiniowanych klas, mo*na pewnie prociej poáczyü je wáaciwymi relacjami. Równie
dobre jest jednak wyjcie od tych*e relacji i korzystanie z nich przy definiowaniu klas.
Obydwa wspomniane procesy czsto wic odbywaj si jednoczenie.
Poniewa* jednak lepiej jest opisaü ka*dy z nich osobno, zatem od którego nale*y
zaczü :) Zdecydowaáem tedy, *e najpierw poszukamy wáaciwych klas oraz ich
skáadowych, a dopiero potem zajmiemy si áczeniem ich w odpowiedni model.

Zaprojektowanie kompletnego zbioru klas oznacza koniecznoü dopracowywania dwóch
aspektów ka*dej z nich:

abstrakcji, czyli opisu tego, co dana klasa ma robiü

implementacji, to znaczy okrelenia, jak ma to robiü

Teraz naturalnie zajmiemy si kolejno obydowami kwestiami.

Abstrakcja

Je*eli masz pomysá na gr, aplikacj u*ytkow czy te* jakikolwiek inny produkt
programisty, to chyba najgorsz rzecz, jak mo*esz zrobiü, jest natychmiastowe
rozpoczcie jego kodowania. Sáusznie mówi si, *e co nagle, to po diable; niezbdne jest
wic stworzenie model abstrakcyjnego zanim przystpi si do wáaciwego
programowania.

Model abstrakcyjny powinien opisywaü zaáo*one dziaáanie programu bez precyzowania
szczegóáów implementacyjnych.

Podstawy programowania

232

Sama nazwa wskazuje zreszt, *e taki model powinien abstrahowaü od kodu. Jego
zadaniem jest bowiem odpowied( na pytanie „Co program ma robiü?”, a w przypadku
technik obiektowych, „Jakich klas bdzie do tego potrzebowaá i jakie czynnoci bd
przez nie wykonywane?”.
Tym kluczowym sprawom powicimy rzecz jasna nieco miejsca.

Identyfikacja klas

Klasy i obiekty stanowi skáadniki, z których budujemy program. Aby wic rozpoczü t
budow, nale*aáoby mieü przynajmniej kilka takich cegieáek. Trzeba zatem
zidentyfikowaü mo*liwe klasy w projekcie.

Musz ci niestety zmartwiü, gdy* w zasadzie nie ma uniwersalnego i zawsze
skutecznego przepisu, który pozwaáby na wykrycie wszelkich klas, potrzebnych do
realizacji programu. Nie powinno to zreszt dziwiü: dzisiejsze programy dotykaj przecie*
prawie wszystkich nauk i dziedzin *ycia, wic podanie niezawodnego sposobu na
skonstruowanie ka*dej aplikacji jest zadaniem porównywalnym z opracowaniem metody
pisania ksi*ek, które zawsze bd bestsellerami, lub te* krcenia filmów, które na
pewno otrzymaj Oscara. To oczywicie nie jest mo*liwe, niemniej dziedzina informatyka
powicona projektowaniu aplikacji (zwana in*ynieri oprogramowania) poczyniáa w
ostatnich latach du*e postpy.

Chocia* nadal najlepsz gwarancj sukcesu jest posiadane dowiadczenie, intuicja oraz
odrobina szczcia, to jednak pocztkujcy adept sztuki tworzenia programów (taki jak
ty :)) nie pozostanie bez pomocy. Programowanie obiektowe zostaáo przecie* wymylone
wáanie po to, aby uáatwiü nie tylko kodowanie programów, ale tak*e ich projektowanie -
a na to skáada si równie* wynajdywanie klas odpowiednich dla realizowanej aplikacji.
Otó* sama idea OOPu jest tutaj sporym usprawnieniem. Postp, który ona przynosi, jest
bowiem zwizany z oparciem budowy programu o rzeczowniki, zamiast czasowników,
wáaciwym programowaniu strukturalnemu. Mylenie kategoriami tworów, bytów,
przedmiotów, urzdze - ogólnie obiektów, jest naturalne dla ludzkiego umysáu. Na
rzeczownikach opiera si tak*e jzyk naturalny, i to w ka*dej czci wiata.
Równie* w programowaniu bardziej intuicyjne jest podejcie skoncentrowane na
wykonawcach czynnoci, a nie na czynnociach jako takich. Przykáadowo, porównaj
dwa poni*sze, abstrakcyjne kody:

// 1. kod strukturalny

hPrinter = GetPrinter();
PrintText (hPrinter,

"Hello world!"

);

// 2. kod obiektowy

pPrinter = GetPrinter();
pPrinter->PrintText (

"Hello world!"

);

Mimo *e oba wygldaj podobnie, to wyra(nie widaü, *e w kodzie strukturalnym
wa*niejsza jest sama czynnoü drukowania, za jej wykonawca (drukarka) jest kwesti
drugorzedn. Natomiast kod obiektowy wyra(nie j wyró*nia, a wywoáanie metody
PrintText() mo*na przyrównaü do wcinicia przycisku zamiast wykonywania jakiej
maáo trafiajcej do wyobra(ni operacji.
Je*eli masz wtpliwoü, które podejcie jest wáaciwsze, to pomyl, co zobaczysz, patrzc
na to urzdzenie obok monitora - czynnoü (drukowanie) czy przedmiot (drukark)

?…

No, ale dosyü ju* tych lu(nych dygresji. Mielimy przecie* zajü si poszukiwaniem
wáaciwych klas dla naszych programów obiektowych. Odejcie od tematu w poprzednim

Oczywicie nie dotyczy to tych, którzy drukarki nie maj, bo oni nic nie zobacz :D

Programowanie obiektowe

233

akapicie byáo jednak tylko pozorne, gdy* „niechccy” znale(limy caákiem prosty i
logiczny sposób, wspomagajcy identyfikacj klas.
Mianowicie, powiedzielimy sobie, *e OOP przesuwa rodek ci*koci programowania z
czasowników na rzeczowniki. Te z kolei s tak*e podstaw jzyka naturalnego,
u*ywanego przez ludzi. Prowadzi to do prostego wniosku i jednoczenie drogi do caákiem
dobrego rozwizania drczacego nas problemu:

Skuteczn pomoc w poszukiwaniu klas odpowiednich dla tworzonego programu mo*e
byü opis jego funkcjonowania w jzyku naturalnym.

Taki opis stosunkowo áatwo jest sporzdziü, pomaga on te* w uporzdkowaniu pomysáu
na program, czyli klarowanym wyra*eniu, o co nam wáaciwie chodzi :) Przykáad takiego
raportu mo*e wygldaü choüby w ten sposób:

Program Graph jest aplikacj przeznaczon do rysowania wszelkiego rodzaju schematów i diagramów
graficznych. Powinien on udostpniaü szerok palet przykáadowych ksztaátów, u*ywanych w takich
rysunkach: bloków, strzaáek, drzew, etykiet tekstowych, figur geometrycznych itp. Edytowany przez
u*ytkownika dokument powinien byü ponadto zapisywalny do pliku oraz eksportowalny do kilku
formatów plików graficznych.

Nie jest to z pewnoci zbyt szczegóáowa dokumentacja, ale na jej podstawie mo*emy
á

atwo wyró*niü spor iloü klas. Nale* do nich przede wszystkim:

dokument

schemat

ró*ne rodzaje obiektów umieszczanych na schematach

Warto te* zauwa*yü, *e powy*szy opis ukrywa te* nieco informacji o zwizkach midzy
klasami, np. to, *e schemat zawiera w sobie umieszczone przez u*ytkownika ksztaáty.

Zbiór ten z pewnoci nie jest kompletny, ale stanowi caákiem dobre osignicie na
pocztek. Daje te* pewne dalsze wskazówki co do mo*liwych kolejnych klas, jakimi mog
byü poszczególne typy ksztaátów skáadajcych si na schemat.

Tak wic analiza opisu w jzyku naturalnym jest dosyü efektywnym sposobem na
wyszukiwanie potencjalnych klas, skáadajcych si na program. Skutecznoü tej metody
zale*y rzecz jasna w pewnym stopniu od umiejtnoci twórcy aplikacji, lecz jej
stosowanie szybko przyczynia si tak*e do podniesienia poziomu biegáoci w
projektowaniu programów.

Analizowanie opisu funkcjonalnego programu nie jest oczywicie jedynym sposobem

poszukiwania klas. Do pozostaáych nale*y chocia*by sprawdzanie klasycznej „listy

kontrolnej”, zawierajcej czsto wystpujce klasy lub te* próba okrelenia dziaáania

jakiej konkretnej funkcji i wykrycia zwizanych z ni klas.

Abstrakcja klasy

Kiedy ju* w przybli*eniu znamy kilka klas z naszej aplikacji, mo*emy spróbowaü okreliü
je bli*ej. Pamitajmy przy tym, *e definicja klasy skáada si z dwóch koncepcyjnych
czci:

publicznego interfejsu, dostpnego dla u*ytkowników klasy

prywatnej implementacji, okrelajcej sposób realizacji zachowa okrelonych w
interfejsie

Caá sztuk w modelowaniu pojedynczej klasy jest skoncentrowanie si na pierwszym z
tych skáadników, bdcym jej abstrakcj. Oznacza to zdefiniowanie roli, speánianej
przez klas, bez dokáadnego wgábiania si w to, jak bdzie ona t rol odgrywaáa.

Podstawy programowania

234

Taka abstrakcja mo*e byü równie* przedstawiona w postaci krótkiego, najczciej
jednozdaniowego opisu w jzyku naturalnym, np.:

Klasa

Dokument

reprezentuje pojedynczy schemat, który mo*e byü edytowany przez u*ytkownika przy

u*yciu naszego programu.

Zauwa*my, *e powy*sze streszczenie nic nie mówi choüby o formie, w jakiej nasz
dokument-schemat bdzie przechowywany w pamici. Czy to bdzie bitmapa, rysunek
wektorowy, zbiór innych obiektów albo mo*e jeszcze co innego?… Wszystkie te
odpowiedzi mog byü poprawne, jednak na etapie okrelania abstrakcji klasy s one poza
obszarem naszego zainteresowania.

Abstrakcja klasy jest okreleniem roli, jak ta klasa peáni w programie.

Jawne formuáowanie opisu podobnego do powy*szego mo*e wydawaü si niepotrzebne,
skoro i tak przecie* bdzie on wymagaá uszczegóáowienia. Posiadanie go daje jednak
mo*liwoü prostej kontroli poprawnoci definicji klasy. Je*eli nie speánia ona zaáo*onych
ról, to najprawdopodobniej zawiera bády.

Skáadowe interfejsu klasy

Publiczny interfejs klasy to zbiór metod, które mog wywoáywaü jej u*ytkownicy. Jego
okrelenie jest drugim etapem definiowania klasy i wyznacza zadania, jakie nale*y
wykonaü podczas jej implementacji.

Nasza klasa Dokument bdzie naturalnie zawieraáa kilka publicznych metod. Co ciekawe,
sporo informacji o nich mo*emy „wycignü” i wydedukowaü z ju* raz analizowanego
opisu caáego programu. Na jego podstawie daj si sprecyzowaü takie funkcje jak:

Otwórz - otwierajc dokument zapisany w pliku

Zapisz - zachowujca dokument w postaci pliku

Eksportuj - metoda eksportujca dokument do pliku graficznego z mo*liwoci
wyboru docelowego formatu

Z pewnocia w toku dalszego projektowania aplikacji (byü mo*e w trakcie definicji
kolejnych klas albo ich zwizków?) mo*na by znale(ü tak*e inne metody, których
umieszczenie w klasie bdzie sáusznym posuniciem. W ka*dej sytuacji musimy jednak
pamitaü, aby postaü klasy zgadzaáa si z jej abstrakcj.

Mówi o tym, gdy* nie powiniene zapominaü, *e projektowanie jest procesem
cyklicznym, w którym mo*e wystpowaü wiele iteracji oraz kilka podejü do tego samego
problemu.

Implementacja

Implementacja klasy wyznacza drog, po jakiej przebiega realizacja zada klasy,
okrelonych w abstrakcji oraz przybli*onych poprzez jej interfejs. Skáadaj si na ni
wszystkie wewntrzne skáadniki klasy, niedostpne jej u*ytkowników - a wic prywatne
pola, a tak*e kod poszczególnych metod.

Dogmaty cisáej in*ynierii oprogramowania mówi, aby dokáadne implementacje
poszczególnych metod (zwane specyfikacjami algorytmów) byáy dokonywane jeszcze
podczas projektowania programu. Do tego celu najczciej u*ywa si pseudokodu, o
którym ju* kiedy wspominaáem. W nim zwykle zapisuje si wstpne wersje algorytmów
metod.
Jednak wedáug mnie ma to sens chyba tylko wtedy, kiedy nad projektem pracuje wiele
osób albo gdy nie jestemy zdecydowani, w jakim jzyku programowania bdziemy go
ostatecznie realizowaü. Wydaje si, *e obie sytuacje na razie nas nie dotycz :)

Programowanie obiektowe

235

W praktyce wic implementacja klasy jest dokonywana podczas programowania, czyli po
prostu pisania jej kodu. Mo*na by zatem spieraü si, czy faktycznie nale*y ona jeszcze do
procesu projektowania. Osobicie uwa*am, *e to po prostu jego przedáu*enie, praktyczna
kontynuacja, realizacja - ró*nie mo*na to nazywaü, ale generalnie chodzi po prostu o
zaoszczdzenie sobie pracy. àczenie projektowania z programowaniem jest w tym
wypadku uzasadnione.

Schemat 28. Proces tworzenia klasy

Odkáadanie implementacji na koniec projektowania, w zasadzie „na styk” z kodowaniem
programu, jest zwykle konieczne. Zaimplementowanie klasy oznacza przecie*
zadeklarowanie i zdefiniowanie wszystkich jej skáadowych - pól i metod, publicznych i
prywatnych. Do tego wymagana jest ju* peána wiedza o klasie - nie tylko o tym, co ma
robiü, jak ma to robiü, ale tak*e o jej zwizkach z innymi klasami.

Zwizki midzy klasami

Potg programowania obiektowego nie s autonomiczne obiekty, ale wspóápracujce ze
sob klasy. Ka*da musi wic wchodziü z innymi przynajmniej w jedn relacj, czyli
zwizek.

Obecnie zapoznamy si z trzema rodzajami takich zwizków. Spajaj one obiekty
poszczególnych klas i umo*liwiaj realizacj zaáo*onych funkcji programu.

Dziedziczenie i zawieranie si

Pierwsze dwa typy relacji bdziemy rozpatrywaü razem z tego wzgldu, i* przy ich okazji
czsto wystpuj pewne nieporzumienia. Nie zawsze jest bowiem oczywiste, którego z
nich nale*y u*yü w niektórych sytuacjach. Postaram si wic rozwiaü te wtpliwoci,
zanim jeszcze zd*ysz o nich pomyleü ;)

Zwizek generalizacji-specjalizacji

Relacja ta jest niczym innym, jak tylko znanym ci ju* dobrze dziedziczeniem.
Generalizacja-specjalizacja (ang. is-a relationship) to po prostu bardziej uczona nazwa
dla tego zwizku.

Podstawy programowania

236

W dziedziczeniu wystpuj dwie klasy, z których jedna jest nadrzdna, za druga
podrzdna. Ta pierwsza to klasa bazowa, czyli generalizacja; reprezentuje ona szeroki
zbiór jakich obiektów. Wród nich mo*na jednak wyró*niü takie, które zasáuguj na
odrbny typ, czyli klas pochodn - specjalizacj.

Schemat 29. Ilustracja zwizku generalizacji-specjalizacji

Klasa bazowa jest czsto nazywana nadtypem, za pochodna - podtypem. Na

schemacie bardzo dobrze widaü, dlaczego :D

Najistotniejsz konsekwencj u*ycia tego rodzaju relacji jest przejcie przez klas
pochodn caáej funkcjonalnoci, zawartej w klasie bazowej. Jako *e jest ona jej bardziej
szczegóáowym wariantem, mo*liwe jest te* rozszerzenie odziedziczonych mo*liwoci, lecz
nigdy - ich ograniczenie.
Klasa pochodna jest wic po prostu pewnym rodzajem klasy bazowej.

Zwizek agregacji

Agregacja (ang. has-a relationship) sugeruje zawieranie si jednego obiektu w innym.
Mówic inaczej, obiekt bdcy caáoci skáada si z okrelonej liczby obiektów-
skáadników.

Schemat 30. Ilustracja zwizku agregacji

Przykáadów na podobne zachowanie nie trzeba daleko szukaü. Wystarczy chocia*by
rozejrzeü si po dysku twardym we wáasnym komputerze: nie doü, *e zawiera on foldery

Programowanie obiektowe

237

i pliki, to jeszcze same foldery mog zawieraü inne foldery i pliki. Podobne zjawisko
wystpuje te* na przykáad dla kluczy i wartoci w Rejestrze Windows.

Implementacja tej relacji w C++ oznacza umieszczenie w deklaracji obiektu agregatu
pola, które bdzie reprezentowaáo jego skáadnik, np.:

// skáadnik

class

CIngredient {

/* ... */

};

// obiekt nadrzdny

class

CAggregate

{

private

// pole ze skáadowym skáadnikiem

CIngredient*

m_pSkladnik;

public

// konstruktor i destruktor

CAggregate()

{ m_pSkladnik =

new

CIngredient; }

~CAggregate()

{

delete

m_pSkladnik; }

};

Mo*na by tu tak*e zastosowaü zmienn obiektow, ale wtedy zwizek staáby si
obligatoryjny, czyli musiaá zawsze wystpowaü. Natomiast w przypadku wska(nika
istnienie obiektu nie jest konieczne przez caáy czas, wic mo*e byü on tworzony i
niszczony w razie potrzeby.

Trzeba jednak uwa*aü, aby po ka*dym zniszczeniu obiektu ustawiaü jego wska(nik na
wartoü NULL. W ten sposób bdziemy mogli áatwo sprawdzaü, czy nasz skáadnik istnieje,
czy te* nie. Unikniemy wic bádów ochrony pamici.

Odwieczny problem: byü czy mieü?

Rozró*nienie pomidzy dziedziczeniem a zawieraniem mo*e czasami nastrczaü pewnych
trudnoci. W takich sytuacjach istnieje na szczcie jedno proste rozwizanie.

Otó* je*eli relacj pomidzy dwoma obiektami lepiej opisuje okrelenie „ma” („zawiera”,
„skáada si” itp.), to nale*y zastosowaü agregacj. Kiedy natomiast klasy s naturalnie
poáczone poprzez stwierdzenie „jest”, wtedy odpowiedniejszym rozwizaniem jest
dziedziczenie.
Co to znaczy? Dokáadnie to, co widzisz i o czym mylisz. Nale*y po prostu sprawdziü,
które ze sformuáowa:

Klasa1

je st

rodzajem

Klasa2

Klasa1

zawier a obiekt

typu

Klasa2

jest poprawne, wstawiajc oczywicie nazwy swoich klas w oznaczonych miejscach, np.:

Kwadrat

je st

rodzajem

Figury

Samochód

zawiera obiekt

typu

Koáo

Mamy wic kolejny przykáad na to, *e programowanie obiektowe jest bliskie ludzkiemu
sposobowi mylenia, co mo*e nas tylko cieszyü :)

Zwizek asocjacji

Najbardziej ogólnym zwizkiem midzy klasami jest przyporzdkowanie, czyli wáanie
asocjacja (ang. uses-a relationship). Obiekty, których klasy s poáczone tak relacj,
posiadaj po prostu mo*liwoü wymiany informacji midzy sob podczas dziaáania
programu.

Podstawy programowania

238

Praktyczna realizacja takiego zwizku to zwykle u*ycie przynajmniej jednego wska(nika,
a najprostszy wariant wyglda w ten sposób:

class

CFoo {

/* ... */

};

class

CBar

{

private

wska(nik do poáczonego obiektu klasy CFoo

CFoo*

m_pFoo;

public

void

UstanowRelacje(CFoo* pFoo) { m_pFoo = pFoo; }

};

atwo tutaj zauwa*yü, *e zawieranie si jest szczególnym przypadkiem asocjacji dwóch

obiektów.

Poáczenie klas mo*e oczywicie przybieraü znacznie bardziej pogmatwane formy, my za
powinnimy je wszystkie dokáadnie poznaü :D Pomówmy wic o dwóch aspektach tego
rodzaju zwizków: krotnoci oraz kierunkowoci.

Krotnoü zwizku

Pod dziwn nazw krotnoci kryje si po prostu liczba obiektów, biorcych udziaá w
relacji. Trzeba bowiem wiedzieü, *e przy asocjacji dwóch klas mo*liwe s ró*ne iloci
obiektów, wystpujcych z ka*dej strony. Klasy s przecie* tylko typami, z nich s
dopiero tworzone wáaciwe obiekty, które w czasie dziaáania aplikacji bd si ze sob
komunikowaáy i wykonywaáy zadania programu.

Mo*emy wic wyró*niü cztery ogólne rodzaje krotnoci zwizku:

jeden do jednego. W takim przypadku pojedynczemu obiektowi jednej z klas
odpowiada równie* pojedynczy obiekt drugiej klasy. Przyporzdkowanie jest
zatem jednoznaczne.
Z takimi relacjami mamy do czynienia bardzo czsto. We(my na przykáad dowoln
list osób - uczniów, pracowników itp. Ka*demu numerowi odpowiada tam jedno
nazwisko oraz ka*de nazwisko ma swój unikalny numer. Podobnie „dziaáa” te*
choüby tablica znaków ANSI.

jeden do wielu. Tutaj pojedynczy obiekt jednej z klas jest przyporzdkowany
kilku obiektom drugiej klasy. Wyglda to podobnie, jak wáo*enie skarpety do kilku
szuflad naraz - byü mo*e w prawdziwym wiecie byáoby to trudne, ale w
programowaniu wszystko jest mo*liwe ;)

wiele do jednego. Ten rodzaj zwizku oznacza, *e kilka obiektów jednej z klas
jest poáczonych z pojedynczym obiektem drugiej klasy.
Dobrym przykáadem s tu rozdziaáy w ksi*ce, których mo*e byü wiele w jednej
publikacji. Ka*dy z nich jest jednak przynale*ny tylko jednemu tomowi.

wiele do wielu. Najbardziej rozbudowany rodzaj relacji to záczenie wielu
obiektów od jednej z klas oraz wielu obiektów drugiej klasy.
Wracajc do przykáadu z ksi*kami mo*emy stwierdziü, *e zwizek midzy
autorem a jego dzieáem jest wáanie takim typem relacji. Dany twórca mo*e
przecie* napisaü kilka ksi*ek, a jednoczenie jedno wydawnictwo mo*e byü
redagowane przez wielu autorów.

Implementacja wielokrotnych zwizków polega zwykle na tablicy lub innej tego typu
strukturze, przechowujcej wska(niki do obiektów danej klasy. Dokáadny sposób
zakodowania relacji zale*y rzecz jasna tak*e od tego, jak iloü obiektów rozumiemy pod
pojciem „wiele”…

Programowanie obiektowe

239

Pojedyncze zwizki s natomiast z powodzeniem programowane za pomoc pól,
bdcych wska(nikami na obiekty.

Widzimy wic, *e poznanie obsáugi obiektów poprzez wska(niki w poprzednim rozdziale
byáo zdecydowanie dobrym pomysáem :)

Tam i (byü mo*e) z powrotem

Gdy do obiektu jakiej klasy dodamy pole - wska(nik na obiekt innej klasy, wtedy
utworzymy midzy nimi relacj asocjacji. Zwizek ten bdzie jednokierunkowy, gdy*
jedynie obiekt posiadajcy wska(nik stanie si jego aktywn czci i bdzie inicjowaá
komunikacj z drugim obiektem. Ten drugi obiekt mo*e w zasadzie „nie wiedzieü”, *e jest
czci relacji!

W zwizku jednokierunkowym z pierwszego obiektu mo*emy otrzymaü drugi, lecz
odwrotna sytuacja nie jest mo*liwa.

Naturalnie, niekiedy bdziemy potrzebowali obustronnego, wzajemnego dostpu do
obiektów relacji. W takim przypadku nale*y zastosowaü zwizek dwukierunkowy.

W zwizku dwukierunkowym oba obiekty maj do siebie wzajemny dostp.

Taka sytuacja czsto uáatwia pisanie bardziej skomplikowanego kodu oraz organizacj
przeplywu danych. Jej implementacja napotyka jednak ma pewn, zdawaáoby si
nieprzekraczaln przeszkod. Popatrzmy bowiem na taki oto kod:

class

CFoo

{

private

wska(nik do poáczonego obiektu CBar

CBar*

m_pBar;

};

class

CBar

{

private

wska(nik do poáczonego obiektu CFoo

CFoo*

m_pFoo;

};

Zdawaáoby si, *e poprawnie realizuje on zwizek dwukierunkowy klas CFoo i CBar. Próba
jego kompilacji skoczy si jednak niepowodzeniem, a to z powodu wska(nika na obiekt
klasy CBar, zadeklarowanego wewntrz CFoo. Kompilator analizuje bowiem kod
sekwencyjnie, wiersz po wierszu, zatem na etapie definicji CFoo nie ma jeszcze bladego
pojcia o klasie CBar, wic nie pozwala na zadeklarowanie wska(nika do niej.
à

atwo przewidzieü, *e zamiana obu definicji miejscami w niczym tu nie pomo*e.

Dochodzimy do paradoksu: aby zdefiniowaü pierwsz klas, potrzebujemy drugiej klasy,
za by zdefniowaü drug klas, potrzebujemy definicji pierwszej klasy! Sytuacja wydaje
si byü zupeánie bez wyjcia…

A jednak rozwizanie istnieje, i jest do tego bardzo proste. Skoro kompilator nie wie, *e
CBar jest klas, trzeba mu o tym zawczasu powiedzieü. Aby jednak znowu nie wpaü w
bádne koáo, nie udzielimy o CBar *adnych bli*szych informacji; zamiast definicji
zastosujemy deklaracj zapowiadajc:

class

CBar;

// rzeczona deklaracja

Podstawy programowania

240

// (dalej definicje obu klas, jak w kodzie wy*ej)

Po tym zabiegu kompilator bdzie ju* wiedziaá, *e CBar jest typem (dokáadnie klas) i
pozwoli na zadeklarowanie odpowiedniego wska(nika jako pola klasy CFoo.

Niektórzy, by uniknü takich sytuacji, od razu deklaruj deklaruj wszystkie klasy przed
ich zdefiniowaniem.

Widzimy wic, *e zwizki dwukierunkowe, jakkolwiek wygodniejsze ni* jednokierunkowe,
wymagaj nieco wicej uwagi. S te* zwykle mniej wydajne przy áczeniu nim du*ej
liczby obiektów. Prowadzi to do prostego wniosku:

Nie nale*y stosowaü zwizków dwukierunkowych, je*eli w konkretnym przypadku
wystarcz relacje jednokierunkowe.

***

Projektowanie aplikacji nawet z u*yciem technik obiektowych nie zawsze jest prostym
zadaniem. Ten podrozdziaá powinien jednak stanowiü jak pomoc w tym zakresie. Nie da
si jednak ukryü, *e praktyka jest zawsze najlepszym nauczycielem, dlatego
zdecydowanie nie powiniene jej unikaü :) Samodzielne zaprojektowanie i wykonanie
choüby prostego programu obiektowego bdzie bardziej pouczajce ni* lektura
najobszerniejszych podrczników.

Koczacy si podrozdziaá w wielu miejscach dotykaá zagadnie in*ynierii

oprogramowania. Je*eli chciaáby poszerzyü swoj wiedz na ten temat (a warto), to

zapraszam do Materiaáu Pomocniczego C, Podstawy in*ynierii oprogramowania.

Podsumowanie

Kolejny bardzo dáugi i bardzo wa*ny rozdziaá :) Zawiera on bowiem dokoczenie opisu
techniki programowania obiektowego.

Rozpoczlimy od mechanizmu dziedziczenia oraz jego roli w ponownym
wykorzystywaniu kodu. Zobaczylimy te*, jak tworzyü proste i bardziej záo*one hierarchie
klasy.
Dalej byáo nawet ciekawiej: dziki metodom wirtualnym i polimorfizmu przekonalimy
si, *e programowanie z u*yciem technik obiektowych jest efektywniejsze i prostsze ni*
dotychczas.
Na koniec zostaáe te* obdarzony spor porcj informacji z zakresu projektowania
aplikacji. Dowiedziaáe si wic o rodzajach obiektów, sposobach znajdowania wáaciwych
klas oraz zwizkach midzy nimi.

W nastpnym rozdziale - ostatnim w podstawowym kursie C++ - przypatrzymy si
wska(nikom jako takim, ju* niekoniecznie w kontekcie OOPu. Pomówimy te* o pamici,
jej alokowaniu i zwalnianiu.

Pytania i zadania

Na kocu rozdziaáu nie mo*e naturalnie zabraknü odpowiedniego pakietu pyta oraz
ü

wicze :)

Programowanie obiektowe

241

Pytania

Na czym polega mechanizm dziedziczenia i jakie zjawisko jest jego gáównym
skutkiem?

Jaka jest ró*nica midzy specyfikatorami praw dostpu do skáadowych,

private

oraz

protected

Co nazywamy páask hierarchi klas?

Czym ró*ni si metoda wirtualna od zwykáej?

Co jest szczegoln cech klasy abstrakcyjnej?

Kiedy klasa jest typem polimorficznym?

Na czym polegaj polimorficzne zachowania klas w C++?

Co to jest RTTI? Na jakie dwa sposoby mechanizm ten umo*liwia sprawdzenie
klasy obiektu, na który wskazuje dany wska(nik?

Jakie trzy rodzaje obiektów mo*na wyró*niü w programie?

10.

Czym jest abstrakcja klasy, a czym jej implementacja?

11.

Podaj trzy typy relacji midzy klasami.

wiczenia

Zaprojektuj dowoln, dwupoziomow hierarchi klas.

(Trudne) Napisz obiektow wersj gry Kóáko i krzy*yk z rozdziaáu 1.5.
Wskazówki: dobrym kandydatem na obiekt jest oczywicie plansza. Zdefiniuj te*
klas graczy, przechowujc ich imiona (niech program pyta si o nie na pocztku
gry).

WSKA'NIKI

Im bardziej zagldaá do rodka,

tym bardziej nic tam nie byáo.

A. A. Milne „Kubu Puchatek”

Dwa poprzednie rozdziaáy upáynáy nam na poznawaniu ró*norodnych aspektów
programowania obiektowego. Nawet teraz, w kilkanacie lat po powstaniu, jest ona
czasem uwa*ana mo*e nie za awangard, ale powa*n nowoü i „odstpstwo” od
„klasycznych” reguá programowania.
Takie opinie, pojawiajce si oczywicie coraz rzadziej, s po czci echem dawnej
popularnoci jzyka C. Fakt, *e C++ zachowuje wszystkie wáaciwoci swego
poprzednika, zdaje si usprawiedliwaü podejcie, i* s one wa*niejsze i bardziej znaczce
ni* „dodatki” wprowadzone wraz z dwoma plusami w nazwie jzyka. Do owych
„dodatków” ma rzecz jasna nale*eü programowanie obiektowe.

Sprawia to, *e ogromna wikszoü kursów i podrczników jzyka C++ jest
usystematyzowana wedle osobliwej zasady. Otó* mówi ona, *e najpierw nale*y wyáo*yü
wszystkie zagadnienia zwizane z C, a dopiero potem zajü si „nowinkami”, w które
zostaá wyposa*ony jego nastpca.
Zastanawiajc si nad tym bli*ej, mo*na nieomal nabraü wtpliwoci, czy w ten sposób
nadal uczymy si przede wszystkim programowania, czy mo*e bardziej zajmuj nas ju*
kwestie formalne danego jzyka? Je*eli nawet nie odnosimy takiego wra*enia, to
nietrudno znale(ü szczliwsze i bardziej naturalne drogi poznania tajników kodowania.

Pamitajmy, *e programowanie jest raczej praktyczn dziedzin informatyki, a jego
nauka jest w du*ej mierze zdobywaniem umiejtnoci, a nie tylko samej wiedzy. Dlatego
te* wymaga ona mniej teoretycznego nastawienia, a wicej wytrwaáoci w osiganiu
coraz lepszego „wtajemniczenia” w zagadnienia programistyczne. Naturaln kolej rzeczy
jest wic uszeregowanie tych zagadnie wedáug wzrastajcego poziomu trudnoci czy te*
ze wzgldu na ich wiksz lub mniejsz u*ytecznoü praktyczn.
Takie te* zaáo*enie przyjáem w tym kursie. Nie chc sobie jednak robiü autoreklamy
twierdzc, *e jest on „inny ni* wszystkie” pozostaáe; mam nawet nadziej, *e to
okrelenie jest caákowit nieprawd i *e istnieje jeszcze mnóstwo innych publikacji,
których autorzy skupili si gáównie na nauczaniu programowania, a nie na opisywaniu
jzyków programowania.

Zatem zgodnie z powy*sz tez kwestie programowania obiektowego, jako niezwykle
wa*ne same w sobie, wprowadziáem tak wczenie jak to tylko byáo mo*liwe - nie
przywizujc wagi to faktu, czy s one wáaciwe jeszcze jzykowi C, czy mo*e ju* C++.
Bardziej liczyáa si bowiem ich rzeczywista przydatnoü.
Na tej samej zasadzie opieram si tak*e teraz, gdy przyszedá czas na szczegóáowe
omówienie wska(ników. To równie* wa*ne zagadnienie, którego geneza nie wydaje si
wcale tak bardzo istotna. Najwa*niejsze, i* s one czci jzyka C++, w dodatku jedn
z kluczowych - chocia* mo*e nie najprostszych. Umiejtnoü wáaciwego posáugiwania si
wska(nikami oraz pamici operacyjn jest wic niebagatelna dla programisty C++.
Opanowaniu przez ciebie tej umiejtnoci zostaá powicony caáy niniejszy rozdziaá.
Mo*esz wic do woli z niego korzystaü :)

Podstawy programowania

244

Ku pamici

Wska(niki s cile zwizane z pamici komputera - a wic miejscem, w którym
przechowuje on dane. Przydatne bdzie zatem przypomnienie sobie (a mo*e dopiero
poznanie?) kilku podstawowych informacji na ten temat.

Rodzaje pamici

Mo*na wyró*niü wiele rodzajów pamici, jakimi dysponuje pecet, kierujc si ró*nymi
przesáankami. Najczciej stosuje si kryteria szybkoci i pojemnoci; s one wa*ne
nie tylko dla nas, programistów, ale praktycznie dla ka*dego u*ytkownika komputera.

Nietrudno przy tym zauwa*yü, *e s one ze sob wzajemnie powizane: im wiksza jest
szybkoü danego typu pamici, tym mniej danych mo*na w niej przechowywaü, i na
odwrót. Nie ma niestety pamici zarówno wydajnej, jak i pojemnej - zawsze potrzebny
jest jaki kompromis.
Zjawisko to obrazuje poni*szy wykres:

Wykres 2. Szybkoü oraz pojemnoü kilku typów pamici komputera

Zostaáy na nim umieszczone wszystkie rodzaje pamici komputera, jakimi si zaraz
dokáadnie przyjrzymy.

Rejestry procesora

Procesor jest jednostk obliczeniow w komputerze. Nieszczególnie zatem kojarzy si z
przechowywaniem danych w jakiej formie pamici. A jednak posiada on wáasne jej
zasoby, które s kluczowe dla prawidáowego funkcjonowania caáego systemu. Nazywamy
je rejestrami.

Ka*dy rejestr ma postaü pojedynczej komórki pamici, za ich liczba zale*y gáównie od
modelu procesora (generacji). Wielkoü rejestru jest natomiast potocznie znana jako
„bitowoü” procesora: najpopularniejsze obecnie jednostki 32-bitowe maj wic rejestry
o wielkoci 32 bitów, czyli 4 bajtów.

Ten sam rozmiar maj te* w C++ zmienne typu

int

, i nie jest to bynajmniej

przypadek :)

Wikszoü rejestrów ma cile okrelone znaczenie i zadania do wykonania. Nie s one
wic przeznaczone do reprezentowania dowolnych danych, które by si we zmieciáy.
Zamiast tego peáni ró*ne wa*ne funkcje w obrbie caáego systemu.
Ze wzgldu na wykonywane przez siebie role, wród rejestrów procesora mo*emy
wyró*niü:

Wska(niki

245

cztery rejestry uniwersalne (EAX, EBX, ECX i EDX

). Przy ich pomocy procesor

wykonuje operacje arytmetyczne (dodawanie, odejmowanie, mno*enie i
dzielenie). Niektóre wspomagaj te* wykonywanie programów, np. EAX jest
u*ywany do zwracania wyników funkcji, za ECX jako licznik w ptlach.
Rejestry uniwersalne maj wic najwiksze znaczenie dla programistów (gáównie
asemblera), gdy* czsto s wykorzystywane na potrzeby ich aplikacji. Z
pozostaáych natomiast korzysta prawie wyácznie sam procesor.

Ka*dy z rejestrów uniwersalnych zawiera w sobie mniejsze, 16-bitowe, a te z kolei po

dwa rejestry omiobitowe. Mog one byü modyfikowane niezale*nie do innych, ale trzeba

oczywicie pamitaü, *e zmiana kilku bitów pociga za sob pewn zmian caáej wartoci.

rejestry segmentowe pomagaj organizowaü pamiü operacyjn. Dziki nim
procesor „wie”, w której czci RAMu znajduje si kod aktualnie dziaáajcego
programu, jego dane itp.

rejestry wska(nikowe pokazuj na wa*ne obszary pamici, jak choüby
aktualnie wykonywana instrukcja programu.

dwa rejestry indeksowe s u*ywane przy kopiowaniu jednego fragmentu
pamici do drugiego.

Ten podstawowy zestaw mo*e byü oczywicie uzupeániony o inne rejestry, jednak
powy*sze s absolutnie niezbdne do pracy procesora.

Najwa*niejsz cech wszystkich rejestrów jest báyskawiczny czas dostpu. Poniewa*
ulokowane s w samym procesorze, skorzystanie z nich nie zmusza do odbycia
„wycieczki” wgáb pamici operacyjnej i dlatego odbywa si wrcz ekspresowo. Jest to w
zasadzie najszybszy rodzaj pamici, jakim dysponuje komputer.
Cen za t szybkoü jest oczywicie znikoma objtoü rejestrów - na pewno nie mo*na w
nich przechowywaü záo*onych danych. Co wicej, ich panem i wáadc jest tylko i
wyácznie sam procesor, zatem nigdy nie mo*na mieü pewnoci, czy zapisane w nich
informacje nie zostan zastpione innymi. Trzeba te* pamitaü, *e nieumiejtne
manipulowanie innymi rejestrami ni* uniwersalne mo*e doprowadziü nawet do
zawieszenia komputera; na tak niskim poziomie nie ma ju* bowiem *adnych
komunikatów o bádach…

Zmienne przechowywane w rejestrach

Mo*emy jednak odnieü pewne korzyci z istnienia rejestrów procesora i sprawiü, by
zaczáy dziaáaü po naszej stronie. Jako niezwykle szybkie porcje pamici s idealne do
przechowywania maáych, ale czsto i intensywnie u*ywanych zmiennych.

Na dodatek nie musimy wcale martwiü si o to, w którym dokáadnie rejestrze mo*emy w
danej chwili zapisaü dane oraz czy pozostan one tam nienaruszone. Czynnoci te mo*na
bowiem zleciü kompilatorowi: wystarczy jedynie u*yü sáowa kluczowego

- na

przykáad:

int

nZmiennaRejestrowa;

Gdy opatrzymy deklaracj zmiennej tym modyfikatorem, to bdzie ona w miar
mo*liwoci przechowywana w którym z rejestrów uniwersalnych procesora. Powinno to
rzecz jasna przyspieszyü dziaáanie caáego programu.

Wszystkie nazwy rejestrów odnosz si do procesorów 32-bitowych.

Podstawy programowania

246

Dostp do rejestrów

Rejestry procesora, jako zwizane cisle ze sprztem, s rzecz niskopoziomow. C++
jest za jzykiem wysokiego poziomu i szczyci si niezale*noci od platformy
sprztowej.

Powoduje to, i* nie posiada on *adnych specjalnych mechanizmów, pozwalajcych
odczytaü lub zapisywaü dane do rejestrów procesora. Zdecydowaáa o tym nie tylko
przenonoü, ale i bezpieczestwo - „mieszanie” w tak zaawansowanych obszarach
systemu mo*e bowiem przynieü sporo szkody.

Jedynym sposobem na uzyskanie dostpu do rejestrów jest skorzystanie z wstawek

asemblerowych, ujmowanych w bloki

__asm

. Mo*na o nich przeczytaü w

MSDN

; u*ywajc

ich trzeba jednak mieü wiadomoü, w co si pakujemy :)

Pamiü operacyjna

Do sensownego funkcjonowania komputera potrzebne jest miejsce, w którym mógáby on
skáadowaü kod wykonywanych przez siebie programów (obejmuje to tak*e system
operacyjny) oraz przetwarzane przez nie dane. Jest to stosunkowo spora iloü informacji,
wic wymaga znacznie wicej miejsca ni* to oferuj rejestry procesora. Ka*dy komputer
posiada wic osobn pamiü operacyjn, przeznaczon na ten wáanie cel. Nazywamy
j czsto angielskim skrótem RAM (ang. random access memory - pamiü o dostpie
bezporednim).

Skd si bierze pamiü operacyjna?

Pamiü tego rodzaju uto*samiamy zwykle z jedn lub kilkoma elektronicznymi ukáadami
scalonymi (tzw. koümi), wáo*onymi w odpowiednie miejsca páyty gáównej peceta.

Fotografia 2. Kilka koci RAM typu DIMM

(zdjcie pochodzi z serwisu

Tom’s Hardware Guide

)

Rzeczywicie jest to najwa*niejsza czü tej pamici (sama zwana jest czasem pamici
fizyczn), ale na pewno nie jedyna. Obecnie wiele podzespoáów komputerowych posiada
wáasne zasoby pamici operacyjnej, przystosowane do wykonywania bardziej
specyficznych zada.
W szczególnoci dotyczy to kart graficznych i d(wikowych, zoptymalizowanych do pracy
z wáaciwymi im typami danych. Iloü pamici, w jak s wyposa*ane, systematycznie
ronie.

Wska(niki

247

Pamiü wirtualna

Istnieje jeszcze jedno, przebogate (ródáo dodatkowej pamici operacyjnej: jest nim dysk
twardy komputera, a cilej jego czü zwana plikiem wymiany (ang. swap file) lub
plikiem stronnicowania (ang. paging file).

Obszar ten sáu*y systemowi operacyjnemu do „udawania”, i* ma poka(nie wicej pamici
ni* posiada w rzeczywistoci. Wáanie dlatego tak symulowan pamiü nazywamy
wirtualn.
Podobny zabieg jest niewtpliwie konieczny w rodowisku wielozadaniowym, gdzie naraz
mo*e byü uruchomionych wiele programów. Chocia* w danej chwili pracujemy tylko z
jednym, to pozostaáe mog nadal dziaáaü w tle - nawet wówczas, gdy áczna iloü
potrzebnej im pamici znacznie przekracza fizyczne mo*liwoci komputera.

Cen za ponadplanowe miejsce jest naturalnie wydajnoü. Dysk twardy charakteryzuje
si dáu*szym czasem dostpu ni* ukáady RAM, zatem wykorzystanie go jako pamici
operacyjnej musi pocignü za sob spowolnienie dziaáania systemu. Dzieje si jednak
tylko wtedy, gdy uruchamiamy wiele aplikacji naraz.

Mechanizm pamici wirtualnej, jako niemal niezbdny do dziaáania ka*dego
nowoczesnego systemu operacyjnego, funkcjonuje zazwyczaj bardzo dobrze. Mo*na
jednak poprawiü jego osigi, odpowiednio ustawiajc pewne opcje pliku wymiany. Przede
wszystkim warto umieciü go na nieu*ywanej zwykle partycji (Linux tworzy nawet sam
odpowiedni partycj) i ustaliü staáy rozmiar na mniej wicej dwukrotnoü iloci
posiadanej pamici fizycznej.

Pamiü trwaáa

Przydatnoü komputerów nie wykraczaáaby wiele poza zastosowania kalkulatorów, gdyby
swego czasu nie wynaleziono sposobu na trwaáe zachowywanie informacji midzy
kolejnymi uruchomieniami maszyny. Tak narodziáy si dyskietki, dyski twarde,
zapisywalne páyty CD, przenone noniki „dáugopisowe” i inne media, sáu*ce do
dáugotrwaáego magazynowania danych.
Sporód nich na najwicej uwagi zasáuguj dyski twarde, jako *e obecnie s niezbdnym
elementem ka*dego komputera. Zwane s czasem pamici trwaá (z wyjanionych
wy*ej wzgldów) albo masow (z powodu ich du*ej pojemnoci).

Mo*liwoü zapisania du*ego zbioru informacji jest aczkolwiek okupiona lamazarnoci
dziaáania. Odczytywanie i zapisywanie danych na dyskach magnetycznych trwa bowiem
zdecydowanie dáu*ej ni* odwoáanie do komórki pamici operacyjnej. Ich wykorzystanie
ogranicza si wic z reguáy do jednorazowego wczytywania du*ych zestawów danych (na
przykáad caáych plików) do pamici operacyjnej, poczynienia dowolnej iloci zmian oraz
powtórnego, trwaáego zapisania. Wszelkie operacje np. na otwartych dokumentach s
wic w zasadzie dokonywane na ich kopiach, rezydujcych wewntrz pamici
operacyjnej.

Nie zajmowalimy si jeszcze odczytem i zapisem informacji z plików na dysku przy
pomocy kodu C++. Nie martw si jednak, gdy* ostatecznie poznamy nawet wicej ni*
jeden sposób na dokonanie tego. Pierwszy zdarzy si przy okazji omawiania strumieni,
bdcych czci Biblioteki Standardowej C++.

Organizacja pamici operacyjnej

Sporód wszystkich trzech rodzajów pamici, dla nas w kontekcie wska(ników
najwa*niejsza bdzie pamiü operacyjna. Poznamy teraz jej budow widzian z
koderskiego punktu widzenia.

Podstawy programowania

248

Adresowanie pamici

Wygodnie jest wyobra*aü sobie pamiü operacyjn jako co w rodzaju wielkiej tablicy
bajtów. W takiej strukturze ka*dy element (zmiemy go komórk) powinien daü si
jednoznacznie identyfikowaü poprzez swój indeks. I tutaj rzeczywicie tak jest - numer
danego bajta w pamici nazywamy jego adresem.
W ten sposób dochodzimy te* do pojcia wska(nika:

Wska(nik (ang. pointer) jest adresem pojedynczej komórki pamici operacyjnej.

Jest to wic w istocie liczba, interpretowana jako unikalny indeks danego miejsca w
pamici. Specjalne znaczenie ma tu jedynie wartoü zero, interpretowana jako wska(nik
pusty (ang. null pointer), czyli nieodnoszcy si do *adnej konkretnej komórki pamici.
Wska(niki sáu* wic jako ácz do okrelonych miejsc w pamici operacyjnej; poprzez
nie mo*emy odwoáywaü si do tych*e miejsc. Bdziemy równie* potrafili pobieraü
wska(niki na zmienne oraz funkcje, zdefiniowane we wáasnych aplikacjach, i wykonywaü
przy ich pomocy ró*ne wspaniaáe rzeczy :)

Zanim jednak zajmiemy si bli*ej samymi wska(nikami w jzyku C++, powiümy nieco
uwagi na to, w jaki sposób systemy operacyjne zajmuj si organizacj i systematyzacj
pamici operacyjnej - czyli jej adresowaniem. Pomo*e nam to lepiej zrozumieü dziaáanie
wska(ników.

Epoka niewygodnych segmentów

Dawno, dawno temu (co oznacza przeáom lat 80. i 90. ubiegáego stulecia) wikszoü
programistów nie mogáa byü zbytnio zadowolona z metod, jakich musieli u*ywaü, by
obsáugiwaü wiksze iloci pamici operacyjnej. Byáa ona bowiem podzielona na tzw.
segmenty, ka*dy o wielkoci 64 kilobajtów.
Aby zidentyfikowaü konkretn komórk nale*aáo wic podaü a* dwie opisujce jej liczby:
oczywicie numer segmentu, a tak*e offset, czyli konkretny ju* indeks w ramach danego
segmentu.

Schemat 31. Segmentowe adresowanie pamici. Adres zaznaczonej komórki zapisywano zwykle

jako 012A:0007, a wic oddzielajc dwukropkiem numer segmentu i offset (oba zapisane w

systemie szesnastkowym). Do ich przechowywania potrzebne byáy dwie liczby 16-bitowe.

Mo*e nie wydaje si to wielk niedogodnoci, ale naprawd ni byáo. Przede wszystkim
niemo*liwe byáo operowanie na danych o rozmiarze wikszym ni* owe 64 kB (a wic
chocia*by na dáugich napisach). Chodzi te* o fakt, i* to programista musiaá martwiü si o
rozmieszczenie kodu oraz danych pisanego programu w pamici operacyjnej. Czas
pokazaá, *e obowizek ten z powodzeniem mo*na przerzuciü na kompilator - co zreszt
wkrótce staáo si mo*liwe.

Wska(niki

249

Páaski model pamici

Dzisiejsze systemy operacyjne maj znacznie wygodniejszy sposób organizacji pamici
RAM. Jest nim wáanie ów páaski model (ang. flat memory model), likwidujcy wiele
mankamentów swego segmentowego poprzednika.

32-bitowe procesory pozwalaj mianowicie, by caáa pamiü byáa jednym segmentem.
Taki segment mo*e mieü rozmiar nawet 4 gigabajtów, wic z áatwoci zmieszcz si w
nim wszystkie fizyczne i wirtualne zasoby RAMu.
To jednak*e nie wszystko. Otó* páaski model umo*liwia zgrupowanie wszystkich
dostpnych rodzajów pamici operacyjnej (koci RAM, plik wymiany, pamiü karty
graficznej, itp.) w jeden cigáy obszar, zwany przestrzeni adresow. Programista nie
musi si przy tym martwiü, do jakiego szczególnego typu pamici odnosi si dany
wska(nik! Na poziomie jzyka programowania znikaj bowiem wszelkie praktyczne
ró*nice midzy nimi: oto mamy jeden, wielki segment caáej pamici operacyjnej i
basta!

Schemat 32. Idea páaskiego modelu pamici. Adresy skáadaj si tu tylko z offsetów,

przechowywanych jako liczby 32-bitowe. Mog one odnosiü si do jakiegokolwiek rzeczywistego

rodzaju pamici, na przykáad do takich jak na ilustracji.

W Windows dodatkowo ka*dy proces (program) posiada swoj wáasn przestrze

adresow, niedostpn dla innych. Wymiana danych mo*e wic zachodzi jedynie poprzez

dedykowane do tego mechanizmy. Bdziemy o nich mówiü, gdy ju* przejdziemy do

programowania aplikacji okienkowych.

Przy takim modelu pamici porównanie jej do ogromnej, jednowymiarowej tablicy staje
si najzupeániej sáuszne. Wska(niki mo*na sobie wtedy caákiem dobrze wyobra*aü jako
indeksy tej tablicy.

Stos i sterta

Na koniec wspomnimy sobie o dwóch wa*nych dla programistów rejonach pamici
operacyjnych, a wic wáanie o stosie oraz stercie.

Czym jest stos?

Stos (ang. stack) jest obszarem pamici, który zostaje automatycznie przydzielony do
wykorzystania dla programu.

Podstawy programowania

250

Na stosie egzystuj wszystkie zmienne zadeklarowane jawnie w kodzie (szczególne te
lokalne w funkcjach), jest on tak*e u*ywany do przekazywania parametrów do funkcji.

Faktycznie wic mo*na by w ogóle nie wiedzieü o jego istnieniu. Czasem jednak objawia
si ono w doü nieprzyjemny sposób: poprzez bád przepeánienia stosu (ang. stack
overflow). Wystpuje on zwykle wtedy, gdy nastpi zbyt wiele wywoáa funkcji.

O stercie

Reszta pamici operacyjnej nosi oryginaln nazw sterty.

Sterta (ang. heap) to caáa pamiü dostpna dla programu i mogca byü mu przydzielona
do wykorzystania.

Czytajc oba opisy (stosu i sterty) pewnie trudno jest wychwyciü midzy nimi jakie
ró*nice, jednak w rzeczywistoci s one caákiem spore.

Przede wszystkim, rozmiar stosu jest ustalany raz na zawsze podczas kompilacji
programu i nie zmienia si w trakcie jego dziaáania. Wszelkie dane, jakie s na nim
przechowywane, musz wic mieü staáy rozmiar - jak na przykáad skalarne zmienne,
struktury czy te* statyczne tablice.
Kontrol pamici sterty zajmuje si natomiast sam programista i dlatego mo*e przyznaü
swojej aplikacji odpowiedni jej iloü w danej chwili, podczas dziaáania programu. Jest
to bardzo dobre rozwizanie, kiedy konieczne jest przetwarzanie zbiorów informacji o
zmiennym rozmiarze.

Terminy ‘stos’ i ‘sterta’ maj w programowaniu jeszcze jedno znaczenie. Tak mianowicie

nazywaj si dwie czsto wykorzystywane struktury danych. Omówimy je przy okazji

poznawania Biblioteki Standardowej C++.

***

Na tym zakoczymy ten krótki wykáad o samej pamici operacyjnej. Czü tych
wiadomoci byáa niektórym pewnie doskonale znana, ale chyba ka*dy miaá okazj
dowiedzieü si czego nowego :)

Wiedza ta bdzie nam teraz szczególnie przydatna, gdy* rozpoczynamy wreszcie
zasadnicz czü tego rozdziaáu, czyli omówienie wska(ników w jzyku C++: najpierw na
zmienne, a potem wska(ników na funkcje.

Wska(niki na zmienne

Trudno zliczyü, ile razy stosowalimy zmienne w swoich programach. Takie statystyki nie
maj zreszt zbytniego sensu - programowanie bez u*ycia zmiennych jest przecie* tym
samym, co prowadzenie samochodu bez korzystania z kierownicy ;D

Wiele razy przypominaáem te*, *e zmienne rezyduj w pamici operacyjnej. Mechanizm
wska(ników na nie jest wic zupeánie logiczn konsekwencj tego zjawiska. W tym
podrozdziale zajmiemy si wáanie takimi wska(nikami.

U*ywanie wska(ników na zmienne

Wska(nik jest przede wszystkim liczb - adresem w pamici, i w takiej te* postaci istnieje
w programie. Jzyk C++ ma ponadto cisáe wymagania dotyczce kontroli typów i z tego
powodu ka*dy wska(nik musi mieü dodatkowo okrelony typ, na jaki wskazuje. Innymi

Wyszukiwarka

Podobne podstrony:
Od zera do gier kodera6
Od zera do gier kodera6
Od zera do gier kodera8
Od zera do gier kodera5
Od zera do gier kodera1
Od zera do gier kodera3np
Od zera do milionera
od zera do ecedeela cz 2 (2)
od zera do ecedeela cz 7
Od zera do milionera fragment
od zera do ecedeela cz 4
od zera do ecedeela cz 3
inwestycje, OD ZERA DO MILIONERA
M Smyczek i M Kaim Od zera do ECeDeeLa cz 2 Użytkowanie komputerów
Od zera do milionera
od zera do milionera
od zera do ecedeela cz 7
od zera do ecedeela cz 6

więcej podobnych podstron