Od zera do gier kodera6

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 pomi dzy
tymi dwoma klasami jest fakt, *e pierwsza wyst puje w definicji CHomeDog, za druga nie.

Páaskie hierarchie

Oprócz rozbudowanych, wielopoziomowych relacji typu baza-pochodna w powszechnym
zastosowaniu s te* takie modele, w których z jednej klasy bazowej dziedziczy wiele klas
pochodnych. Jest to tzw. páaska hierarchia i 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 j zyk 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 j zyka polskiego, lecz po prostu angielskimi nazwami figur szachowych.

Podstawy programowania

202

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Mo*na zauwa*yü, ze bazowa klasa CChessPiece nie b dzie tutaj sáu*yü do tworzenia

obiektów, lecz tylko do wyprowadzania z niej kolejnych klas. Sprawia to, *e byáaby ona

dobrym kandydatem na tzw. klas abstrakcyjn. O tym zagadnieniu b dziemy mówiü

przy okazji metod wirtualnych.

Podsumowanie

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 j zyku 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 j zyków, które udost pniaj 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 wi c posiadaü caákiem spore
dowiadczenie w programowaniu.
Jakkolwiek zatem dziedziczenie wielokrotne bywa czasem przydatnym narz dziem,
stosowanie go (przynajmniej powszechne) w tworzonych aplikacjach nie jest zalecane.
Je*eli pojawia si taka koniecznoü, nale*y wtedy najprawdopodobniej zweryfikowaü swój
projekt; w wi kszoci 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 nastr czaü pewnych problemów. S one
zazwyczaj specyficzne dla konkretnego j zyka programowania, jako *e wyst puj w tym
wzgl dzie pewne ró*nice mi dzy nimi.

W tym paragrafie zajmiemy si takimi wáanie drobnymi niuansami, które s zwizane z
dziedziczeniem klas w j zyku 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 wewn trznych obiektów czy te* alokacja
dodatkowej pami ci. Czynnoci te prawie zawsze wymagaj zatem dost pu do
prywatnych pól klasy. Je*eli wi c konstruktor z klasy bazowej zostaáby „wrzucony”
do klasy pochodnej, to utraciáby z nimi niezb dne poáczenie - wszak „zostaáyby”
one w klasie bazowej! Z tego te* powodu konstruktory nie s dziedziczone.

Programowanie obiektowe

203

destruktory. Sprawa wyglda tu podobnie jak punkt wy*ej. Dziaáanie
destruktorów najcz ciej tak*e opiera si na polach prywatnych, a skoro one nie
s dziedziczone, zatem destruktor te* nie powinien przechodziü do klas
pochodnych.

Doü ciekawym uzasadnieniem niedziedziczenia konstruktorów i destruktorów s tak*e
same ich nazwy, 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 zapami taj, *e
skáadowa ta odpowiada za sposób, w jaki obiekt jest kopiowany z jednej zmiennej
do drugiej. Taki transfer zazwyczaj równie* wymaga dost pu do pól prywatnych
klasy, co od razu wyklucza dziedziczenie.

Ze wzgl du na specjalne znaczenie konstruktorów i destruktorów, ich funkcjonowanie w
warunkach dziedziczenia jest doü specyficzne. Nieco dalej zostaáo ono bli*ej opisane.

Obiekty kompozytowe

Sposób, w jaki C++ realizuje pomysá dziedziczenia, jest sam w sobie dosyü interesujcy.
Wi kszoü koderów uczcych si tego j zyka 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 zakr cona :)

Otó* wewn trznie u*ywana przez kompilator definicja klasy pochodnej jest identyczna z
t, któr wpisujemy do kodu; nie zawiera *adnych pól i metod pochodzcych z klas
bazowych! Jakim wi c cudem s one dost pne?
Odpowied( jest raczej zaskakujca: podczas tworzenia obiektu klasy pochodnej
dokonywana jest tak*e kreacja obiektu klasy bazowej, który staje si jego cz ci.
Zatem nasz obiekt pochodny to tak naprawd obiekt bazowy plus dodatkowe pola,
zdefiniowane w jego wáasnej klasie. Przy bardziej rozbudowanej hierarchii klas zaczyna
on przypominaü cebul :

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

Praktyczne konsekwencje tego stanu rzeczy s zwizane chocia*by z konstruowaniem i
niszczeniem tych wewn trznych 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ü wi cej ni* jeden konstruktor, kompilator musiaáby podjü decyzj ,
który z nich powinien zostaü u*yty. Nie robi tego jednak, lecz oczekuje, *e zawsze

b dzie obecny domylny konstruktor bezparametrowy.

Dlatego te* ka*da klasa, z której b d 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 wi c dowiedzieü si , w jaki sposób
tworzyü nowe klasy na podstawie ju* istniejcych i projektowaü ich hierarchie, obrazujce
naturalne zwizki typu „ogóá-szczegóá”.

W nast pnej kolejnoci poznamy zalety metod wirtualnych oraz porozmawiamy sobie o
najwi kszym osigni ciu OOPu, czyli polimorfizmie. B dzie wi c bardzo ciekawie :D

Metody wirtualne i polimorfizm

Dziedziczenie jest oczywicie niezwykle wa*nym, a wr cz niezb dnym skadnikiem
programowania obiektowego. Stanowi jednak tylko podstaw dla dwóch kolejnych
technik, majcych du*o wi ksze znaczenie i pozwalajcych na o wiele efektywniejsze
pisanie kodu. Mam tu na myli tytuáowe metody wirtualne oraz cz ciowo 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 zast powalimy ju* istniejce metody ich nowymi wersjami, wáaciwymi dla
tworzonych klas.
Takie sytuacje s jednak w praktyce dosyü cz ste - 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 niezb dny 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 zwierz ta 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 wi c klasy wywodzce si do Zwierz cia 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 cz ci 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 szcz liwe rozwizanie skáadniowe, poniewa* mo*e cz sto
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 zast puje star, która jest jednak dost pna 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
b dzie wyjanienie ró*nicy pomi dzy zwykáymi oraz wirtualnymi metodami.

Programowanie obiektowe

207

Posáu*y nam do tego nast pujcy 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 mi dzy zwykáymi a wirtualnymi funkcjami skáadowymi
b dzie 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 wi c, 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 podj ta ju* na etapie kompilacji programu. Nazywamy j wtedy
wczesnym wizaniem (ang. early binding) funkcji. Do jej podj cia 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 b dzie 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 dost pna podczas kompilacji

, dlatego te* tutaj zostaje asekuracyjnie

wykorzystany jedynie znany typ CAnimal. Faktycznie wywoáywan metod b dzie wi c
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 b dzie, 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 podj cie nastpi dopiero w stosowanej chwili podczas dziaáania gotowej
aplikacji; nazywamy to pó(nym wizaniem (ang. late binding) funkcji. W tym
momencie b dzie 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 wi c
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
pami ci, czyli bezpowrotnej utraty zaalokowanej pami ci 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 wewn trznych, na przykáad serca czy páuc. Poczynimy
wi c 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 niezb dne páuca, tak wi c po*yj sobie jeszcze troch i
b d 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 rozstrzygn limy pojedynek mi dzy 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ü usuni ty, 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 wi c tak*e efektom zwizanym z wirtualnoci oraz wczesnym i pó(nym
wizaniem. Je*eli wi c nasz destruktor nie b dzie 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
wi c 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 poj cia.
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

{

(oszcz dnoü jest cnot, wi c znowu pomijamy reszt skáadowych :D)

public

virtual

~CAnimal()

{

delete

m_pSerce; }

};

Wtedy te* operator

delete

b dzie usuwaá obiekt, na który faktycznie wskazuje podany

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

Pami taj 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 cz sto 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 wi c 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 zb dne 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 oszcz dnociowych :))

public

virtual

void

Oddychaj() =

;

};

Jest nim wyst pujca 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 wi c 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 b dzie 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 wzgl du 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 j zyka Object Pascal.

Takie klasy buduj zawsze najwy*sze pi tra 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 b dzie 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 wi c poni*szy kod b dzie 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 b dzie 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 poj cia „klasy” i „obiekty”, rodkowe pi tra budowaáoby
„dziedziczenie” oraz „metody wirtualne”, za u samego szczytu sytuowaáby si
„polimorfizm”. Jest to bowiem najwi ksze osigni cie 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 b dzie si wi c odnosiü do takich tworów, które
mo*na interpretowaü na ró*ne sposoby - a wi c 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 wi kszoü 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 b dzie 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 wi kszoci 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 cz sto
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 poj cie 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 wi c, *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 dost powe 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 dost powe 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 dost powe do pól

std::string

ISBN()

const

{

return

m_strISBN; }

};

Z klasy CDocument, reprezentujcej dowolny dokument, dziedzicz dwie nast pne:
COnlineDocument, odpowiadajca tekstom dost pnym 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, b dcy zasadniczo wska(nikiem na obiekt typu CDocument. W
jego charakterze mo*e jednak wyst powaü tak*e wskazanie na który z obiektów
potomnych, zatem poni*szy kod b dzie 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 b dzie 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 wi c
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

wzgl dna 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 wi c nic ponad autora, tytuá oraz dat stworzenia dokumentu.

Trzeba jednak przyznaü, *e sami niejako jestemy sobie winni. Wyodr bniajc 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 b dzie uczynienie
jej funkcj wirtualn - wtedy klasy dziedziczce od CDocument b d 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

{

(wi kszoü skáadowych wyci to z powodu zbyt du*ej obj toci)

public

virtual

void

PokazDane();

};

// (reszty klas nieuwzgl dniono 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 b dzie 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 wi kszej 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 b dzie ograniczaá
si do wywoáania zaledwie jednej metody! I to wáanie jest pi kne :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 p tli
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 wi kszoci operacji do podobnie
trywialnych konstrukcji jak powy*sza.
Od tej pory do nas nale*y wi c 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 wi ksz elastycznoü.

Pami taj, *e praktyka czyni mistrza! Poznanie teoretycznych aspektów programowania
obiektowego jest wprawdzie niezb dne, ale najwi cej wartociowych umiej tnoci
zdob dziesz 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 uwzgl dniü tak*e bardziej szczegóáowe
przypadki, co oznacza koniecznoc sprawdzania faktycznego typu obiektów, na które
wskazuj nasze wska(niki.
Na szcz cie 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, wi c 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 wi c udost pniaü 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 j zyka C++ po to, by umo*liwiü kompleksow obsáug typów
polimorficznych w zakresie konwersji „w dóá” hierarchii klas. Jego przeznaczenie jest
zatem nast pujce:

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 wi c tak*e sprawdzanie, czy rzeczywicie mamy do czynienia
z wska(nikiem do obiektu potomnego, przechowywanym przez zmienn b dc
wska(nikiem do typu bazowego.

Uff, wszystko to wydaje si bardzo zakr cone, zatem najlepiej b dzie, 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. Nast pnie 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 zwierz cia, dziedziczcego z klasy bazowej IAnimal.

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

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

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

takie mog wi c 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 wi c 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

, dzi ki 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 b dzie, 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 b dzie

dokonanie podanego rzutowania.

Aby j wychwyciü potrzebujemy oczywicie dodatkowego warunku, porównujcego
zmienn pSsak z t specjaln wartoci NULL (b dc 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 wi ksze 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 pami ci (access violation).

Nale*y wi c 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

nast pnym 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 cz ci RTTI, czyli operatora

typeid

, generalnie nie jest tak

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

Skorzystanie z RTTI wymaga podj cia dwóch wst pnych 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
podr cznego 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
nast pujca:

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 wewn trznie 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 dost pne 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 wi c 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 wzi ty
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 si gajc nawet do
mechanizmów polimorficznych, poniewa* wyra(nie zadeklarowalimy go jako IAnimal*.
Aby zmusiü krnbrny operator do wi kszego 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 wyst pujcym tu operatorze dereferencji - gwiazdce (*) powiemy sobie bli*ej, gdy
przejdziemy do dokáadnego omawiania wska(ników jako takich. Na razie zapami taj, *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 cz sto 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 por czne 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 b d 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

wielopi trowej 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 pami taü, *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 cz sto, 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” - pami tajmy t sentencj :D

***

Gratulacje! Wáanie poznaáe wszystkie teoretyczne zaáo*enia programowania
obiektowego i ich praktyczn realizacj w C++. Wykorzystujc zdobyt wiedz , b dziesz
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 wi c, *e
dobrze b dzie powi ciü 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 pi knie… 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 - niezb dnych szczegóáów,
koniecznych do stosowania OOPu w praktyce. Czas jednak wypáynü na powierzchni i
ponownie spojrzeü na zagadnienie bardziej caáociowo. Temu celowi b dzie sáu*yü
niniejszy podrozdziaá.

Wiele podr cznikó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 j zyka. Je*eli jednak mówimy o materiaáach dla caákiem pocztkujcych,
b dcych 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 wi c uniknü tego bá du i przedstawiam programowanie obiektowe tak*e od
strony programisty-praktyka. Mam jednoczenie nadziej , *e w ten sposób przynajmniej
cz ciowo 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ó* wi c znajdziemy w aktualnym podrozdziale? )aáuj , ale nie b dzie 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 wewn trznej, 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 wyst puj. Dalej zajmiemy si kwesti
definiowania odpowiednich klas - ich interfejsu i implementacji, a wreszcie zwizkami
pomi dzy nimi, dzi ki 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 b dzie ju* wówczas wiedz tajemn, ale normaln i, co
wa*niejsze, satysfakcjonujc cz ci pracy kodera.
Nie przedáu*ajc ju* wi cej zacznijmy zatem wáaciw treü tego podrozdziaáu.

Rodzaje obiektów

Ka*dy program zawiera w mniejszej lub wi kszej cz ci 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. B dzie on zreszt punktem wyjcia dla nieco bardziej szczegóáowych
kwestii, opisanych pó(niej.
Pomówmy wi c kolejno o ka*dym rodzaju z owej podstawowej trójki.

Singletony

Wi kszoü 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 wi c co najwy*ej jeden egzemplarz
klasy, b dcej singletonem.

Obiekty takie s dosáownie jedyne w swoim rodzaju i dlatego zwykle przechowuj one
najwa*niejsze dane programu oraz wykonaj wi kszoü newralgicznych czynnoci.
Najcz ciej 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(wi k, sieü,
AI, itd., w edytorach: moduáy obsáugi plików, dokumentów, formatowania itp.

Niekiedy zastosowanie singletonów wymuszaj warunki zewn trzne, 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 wi kszoci odwoáaniami do innych obiektów: niekiedy do wielu drobnych, ale
cz ciej do kilku kolejnych zarzdców, czyli nast pnego, ni*szego poziomu hierarchii
zawierania si obiektów.

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

Przykáady wykorzystania

Najbardziej oczywistym przykáadem singletonu mo*e byü caáociowy obiekt programu,
a wi c klasa w rodzaju CApplication czy CGame. B dzie ona nadrz dnym obiektem
wobec wszystkich innych, a tak*e przechowywaáa b dzie 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 b d 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 wyst puj w pojedynczych instancjach, gdy* unikatowa jest ich rola.
Kwesti otwart jest natomiast ich ewentualna podlegáoü najbardziej nadrz dnemu
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, dost pnymi 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 dost pie do podsystemów z zewntrz).

Dlaczego jednak w ogóle stosowaü singletony, je*eli i tak b d 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 dost pem, co zwi ksza 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 wi c 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 szcz cie 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 wi c ono inn

funkcj ni* ta, któr znalimy dotychczas.

Pami tajmy, *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 b dzie ten sam.
Musimy jakkolwiek pami taü, *e nadal obowizuj tutaj specyfikatory praw dost pu, wi c
jeli powy*szy kod umiecimy poza metodami klasy, to b dzie 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 dost pu. Ka*de odniesienie do statycznego pola b dzie jednak
dost pem do tej samej zmiennej, rezydujcej w tym samym miejscu pami ci. W
szczególnoci poszczególne obiekty danej klasy nie b d posiadaáy wáasnej kopii takiego
pola, bo b dzie 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

nast pujco:

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 dost pu 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 dost pny 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 wi c statyczne pole, którego zadaniem b dzie 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 b d 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 dost powej do niego, która
zreszt tak*e b dzie 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 nast puje wi c przy pierwszym
u*yciu.
Odbywa si ona poprzez bezporednie wywoáanie konstruktora… którego na razie nie
mamy (jest domylny)! Czym pr dzej 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 wi cej ni* jednej kopii naszego singletonu.
Uprawniona do wywoáania prywatnego konstruktora jest bowiem tylko skáadowa klasy,
czyli metoda CSingleton::Obiekt(). Wszelkie zewn trzne próby stworzenia obiektu
klasy CSingleton zakocz si wi c bá dem kompilacji, za jedyny jego egzemplarz
b dzie dost pny wyácznie poprzez wspomnian metod .

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

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

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

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

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

wzgl du koniecznoü znacznie wi kszej znajomoci j zyka C++ do ich poprawnego

zastosowania

Musimy jeszcze pami taü, aby usunü obiekt, gdy ju* nie b dzie 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 wi cej) 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 zewn trznymi zdarzeniami, wtedy przebieg
programu nie b dzie ju* taki oczywisty. Powy*szy sposób na implementacj singletonu
b dzie wówczas znacznie u*yteczniejszy.

Obiekty zasadnicze

Drugi rodzaj obiektów skupia te, które stanowi najwi kszy 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 mi dzy sob oraz przekazujc dane, realizuj one wszystkie
funkcje aplikacji.

Budowanie sieci takich obiektów jest wi c lwi cz ci procesu tworzenia obiektowej
struktury programu. Definiowanie odpowiednich klas, zwizków mi dzy 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 narz dziowe

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 b dziesz jednak cz sto wcielaá si w obie
role, dlatego znajomoü wszystkich rodzajów obiektów z pewnoci oka*e si pomocna.

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

Obiekty narz dziowe, 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. Cz sto zreszt traktuje
si je podobnie jak typy podstawowe - zwáaszcza w C++.

Obiekty narz dziowe 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 narz dziowe 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 najcz ciej kilka konstruktorów, ale ich przeznaczenie ogranicza si
zazwyczaj do wst pnego 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 wi c umieszczana bezporednio w definicji klasy.
Bezwzgl dnie 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 wi c 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 b dziemy mówiü w jednym z dalszych rozdziaáów

nazewnictwo klas narz dziowych jest zwykle takie samo, jak normalnych typów
sklarnych. Nie stosuje si wi c 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 narz dziowych. Z jednym z takich obiektów masz zreszt stale do czynienia:
jest nim typ std::string, b dcy 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 cz ci Standardowej Biblioteki Typów C++, któr poznamy
szczegóáowo po zakoczeniu nauki samego j zyka. Nale* do niej tak*e inne typy, które
z pewnoci mo*emy uznaü za narz dziowe, jak na przykáad std::complex,
reprezentujcy liczb zespolon czy std::bitset, b dcy cigiem bitów.
Matematyka dostarcza zreszt najwi kszej liczby kandydatów na potencjalne obiekty
narz dziowe. Wystarczy pomyleü o wektorach, macierzach, punktach, prostoktach,
prostych, powierzchniach i jeszcze wielu innych poj ciach. Nie s one przy tym jedynie
obrazowym przykáadem, lecz niedzownym elementem programowania - gier w
szczególnoci. Wi kszoü bibliotek zawiera je wi c 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óárz dne 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óárz dn 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, wi c

// musimy z tym poczekaü :)

};

Najwi cej kontrowersji wzbudza pewnie to, *e pola x, y, z s publicznie dost pne. 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 dost powych,
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
powi caü pieczoáowitej uwagi na tworzenie i niszczenie obiektów, zatem wystarcz nam
zwykáe zmienne obiektowe zamiast wska(ników. Nawet wi cej - 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óárz dnych

// 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 b dzie 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 nast pnym rozdziale.

à

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

które mo*na i trzeba realizowaü jako obiekty narz dziowe. 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

pami ci 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 b d si na skáadaáy, oraz pól i metod, które zostan
zawarte w ich definicjach. Drugim jest okrelenie zwizków pomi dzy tymi klasami,
dzi ki 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 cz sto wi c 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
rozpocz cie jego kodowania. Sáusznie mówi si , *e co nagle, to po diable; niezb dne jest
wi c 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 b dzie do tego potrzebowaá i jakie czynnoci b d
przez nie wykonywane?”.
Tym kluczowym sprawom powi cimy rzecz jasna nieco miejsca.

Identyfikacja klas

Klasy i obiekty stanowi skáadniki, z których budujemy program. Aby wi c 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, wi c podanie niezawodnego sposobu na
skonstruowanie ka*dej aplikacji jest zadaniem porównywalnym z opracowaniem metody
pisania ksi*ek, które zawsze b d bestsellerami, lub te* kr cenia filmów, które na
pewno otrzymaj Oscara. To oczywicie nie jest mo*liwe, niemniej dziedzina informatyka
powi cona projektowaniu aplikacji (zwana in*ynieri oprogramowania) poczyniáa w
ostatnich latach du*e post py.

Chocia* nadal najlepsz gwarancj sukcesu jest posiadane dowiadczenie, intuicja oraz
odrobina szcz cia, 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. Post p, 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 j zyk naturalny, i to w ka*dej cz ci 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 wcini cia 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 j zyka naturalnego,
u*ywanego przez ludzi. Prowadzi to do prostego wniosku i jednoczenie drogi do caákiem
dobrego rozwizania dr czacego nas problemu:

Skuteczn pomoc w poszukiwaniu klas odpowiednich dla tworzonego programu mo*e
byü opis jego funkcjonowania w j zyku 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 udost pniaü 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 mi dzy
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 osigni cie 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 wi c analiza opisu w j zyku 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 umiej tnoci 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 cz sto wyst pujce 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. Pami tajmy przy tym, *e definicja klasy skáada si z dwóch koncepcyjnych
cz ci:

publicznego interfejsu, dost pnego 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, b dcym jej abstrakcj. Oznacza to zdefiniowanie roli, speánianej
przez klas , bez dokáadnego wgá biania si w to, jak b dzie ona t rol odgrywaáa.

Podstawy programowania

234

Taka abstrakcja mo*e byü równie* przedstawiona w postaci krótkiego, najcz ciej
jednozdaniowego opisu w j zyku 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 b dzie przechowywany w pami ci. Czy to b dzie 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* b dzie 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 b dzie 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 b dzie sáusznym posuni ciem. W ka*dej sytuacji musimy jednak
pami taü, 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 wyst powaü 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 wewn trzne skáadniki klasy, niedost pne jej u*ytkowników - a wi c 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 najcz ciej u*ywa si pseudokodu, o
którym ju* kiedy wspominaáem. W nim zwykle zapisuje si wst pne 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 j zyku programowania b dziemy go
ostatecznie realizowaü. Wydaje si , *e obie sytuacje na razie nas nie dotycz :)

Programowanie obiektowe

235

W praktyce wi c 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
zaoszcz dzenie 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 mi dzy klasami

Pot g programowania obiektowego nie s autonomiczne obiekty, ale wspóápracujce ze
sob klasy. Ka*da musi wi c 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 b dziemy rozpatrywaü razem z tego wzgl du, i* przy ich okazji
cz sto wyst puj pewne nieporzumienia. Nie zawsze jest bowiem oczywiste, którego z
nich nale*y u*yü w niektórych sytuacjach. Postaram si wi c 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 wyst puj dwie klasy, z których jedna jest nadrz dna, za druga
podrz dna. 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
odr bny typ, czyli klas pochodn - specjalizacj .

Schemat 29. Ilustracja zwizku generalizacji-specjalizacji

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

schemacie bardzo dobrze widaü, dlaczego :D

Najistotniejsz konsekwencj u*ycia tego rodzaju relacji jest przej cie 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 wi c po prostu pewnym rodzajem klasy bazowej.

Zwizek agregacji

Agregacja (ang. has-a relationship) sugeruje zawieranie si jednego obiektu w innym.
Mówic inaczej, obiekt b dcy 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
wyst puje 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 b dzie reprezentowaáo jego skáadnik, np.:

// skáadnik

class

CIngredient {

/* ... */

};

// obiekt nadrz dny

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 wyst powaü. Natomiast w przypadku wska(nika
istnienie obiektu nie jest konieczne przez caáy czas, wi c 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 b dziemy mogli áatwo sprawdzaü, czy nasz skáadnik istnieje,
czy te* nie. Unikniemy wi c bá dów ochrony pami ci.

Odwieczny problem: byü czy mieü?

Rozró*nienie pomi dzy dziedziczeniem a zawieraniem mo*e czasami nastr czaü pewnych
trudnoci. W takich sytuacjach istnieje na szcz cie jedno proste rozwizanie.

Otó* je*eli relacj pomi dzy 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 wi c 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 mi dzy 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 mi dzy 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 wi c 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, wyst pujcych z ka*dej strony. Klasy s przecie* tylko typami, z nich s
dopiero tworzone wáaciwe obiekty, które w czasie dziaáania aplikacji b d si ze sob
komunikowaáy i wykonywaáy zadania programu.

Mo*emy wi c 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 cz sto. 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 mi dzy
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
poj ciem „wiele”…

Programowanie obiektowe

239

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

Widzimy wi c, *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 mi dzy nimi relacj asocjacji. Zwizek ten b dzie jednokierunkowy, gdy*
jedynie obiekt posiadajcy wska(nik stanie si jego aktywn cz ci i b dzie inicjowaá
komunikacj z drugim obiektem. Ten drugi obiekt mo*e w zasadzie „nie wiedzieü”, *e jest
cz ci relacji!

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

Naturalnie, niekiedy b dziemy potrzebowali obustronnego, wzajemnego dost pu do
obiektów relacji. W takim przypadku nale*y zastosowaü zwizek dwukierunkowy.

W zwizku dwukierunkowym oba obiekty maj do siebie wzajemny dost p.

Taka sytuacja cz sto 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
poj cia o klasie CBar, wi c 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 b dzie 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 wi c, *e zwizki dwukierunkowe, jakkolwiek wygodniejsze ni* jednokierunkowe,
wymagaj nieco wi cej 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 b dzie bardziej pouczajce ni* lektura
najobszerniejszych podr cznikó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.

Rozpocz limy 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: dzi ki 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 wi c o rodzajach obiektów, sposobach znajdowania wáaciwych
klas oraz zwizkach mi dzy nimi.

W nast pnym rozdziale - ostatnim w podstawowym kursie C++ - przypatrzymy si
wska(nikom jako takim, ju* niekoniecznie w kontekcie OOPu. Pomówimy te* o pami ci,
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 mi dzy specyfikatorami praw dost pu 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 mi dzy 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 „odst pstwo” od
„klasycznych” reguá programowania.
Takie opinie, pojawiajce si oczywicie coraz rzadziej, s po cz ci echem dawnej
popularnoci j zyka 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 j zyka. Do owych
„dodatków” ma rzecz jasna nale*eü programowanie obiektowe.

Sprawia to, *e ogromna wi kszoü kursów i podr czników j zyka 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 nast pca.
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 j zyka? Je*eli nawet nie odnosimy takiego wra*enia, to
nietrudno znale(ü szcz liwsze i bardziej naturalne drogi poznania tajników kodowania.

Pami tajmy, *e programowanie jest raczej praktyczn dziedzin informatyki, a jego
nauka jest w du*ej mierze zdobywaniem umiej tnoci, a nie tylko samej wiedzy. Dlatego
te* wymaga ona mniej teoretycznego nastawienia, a wi cej wytrwaáoci w osiganiu
coraz lepszego „wtajemniczenia” w zagadnienia programistyczne. Naturaln kolej rzeczy
jest wi c uszeregowanie tych zagadnie wedáug wzrastajcego poziomu trudnoci czy te*
ze wzgl du na ich wi ksz 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
j zykó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 j zykowi 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 cz ci j zyka C++, w dodatku jedn
z kluczowych - chocia* mo*e nie najprostszych. Umiej tnoü wáaciwego posáugiwania si
wska(nikami oraz pami ci operacyjn jest wi c niebagatelna dla programisty C++.
Opanowaniu przez ciebie tej umiej tnoci zostaá powi cony caáy niniejszy rozdziaá.
Mo*esz wi c do woli z niego korzystaü :)

Podstawy programowania

244

Ku pami ci

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

Rodzaje pami ci

Mo*na wyró*niü wiele rodzajów pami ci, jakimi dysponuje pecet, kierujc si ró*nymi
przesáankami. Najcz ciej 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 wi ksza jest
szybkoü danego typu pami ci, tym mniej danych mo*na w niej przechowywaü, i na
odwrót. Nie ma niestety pami ci 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 pami ci komputera

Zostaáy na nim umieszczone wszystkie rodzaje pami ci 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 pami ci. 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 pami ci, 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 wi c 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 :)

Wi kszoü rejestrów ma cile okrelone znaczenie i zadania do wykonania. Nie s one
wi c przeznaczone do reprezentowania dowolnych danych, które by si we zmieciáy.
Zamiast tego peáni ró*ne wa*ne funkcje w obr bie caáego systemu.
Ze wzgl du 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 p tlach.
Rejestry uniwersalne maj wi c najwi ksze znaczenie dla programistów (gáównie
asemblera), gdy* cz sto 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 pami taü, *e zmiana kilku bitów pociga za sob pewn zmian caáej wartoci.

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

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

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

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

Najwa*niejsz cech wszystkich rejestrów jest báyskawiczny czas dost pu. Poniewa*
ulokowane s w samym procesorze, skorzystanie z nich nie zmusza do odbycia
„wycieczki” wgáb pami ci operacyjnej i dlatego odbywa si wr cz ekspresowo. Jest to w
zasadzie najszybszy rodzaj pami ci, jakim dysponuje komputer.
Cen za t szybkoü jest oczywicie znikoma obj toü rejestrów - na pewno nie mo*na w
nich przechowywaü záo*onych danych. Co wi cej, 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* pami taü, *e nieumiej tne
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 pami ci s idealne do
przechowywania maáych, ale cz sto 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 b dzie 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

Dost p do rejestrów

Rejestry procesora, jako zwizane cisle ze sprz tem, s rzecz niskopoziomow. C++
jest za j zykiem wysokiego poziomu i szczyci si niezale*noci od platformy
sprz towej.

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 dost pu 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,
wi c wymaga znacznie wi cej miejsca ni* to oferuj rejestry procesora. Ka*dy komputer
posiada wi c osobn pami ü operacyjn, przeznaczon na ten wáanie cel. Nazywamy
j cz sto angielskim skrótem RAM (ang. random access memory - pami ü o dost pie
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

(zdj cie pochodzi z serwisu

Tom’s Hardware Guide

)

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

Wska(niki

247

Pami ü wirtualna

Istnieje jeszcze jedno, przebogate (ródáo dodatkowej pami ci 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 wi cej pami ci
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 pami ci znacznie przekracza fizyczne mo*liwoci komputera.

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

Mechanizm pami ci wirtualnej, jako niemal niezb dny 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 wi cej dwukrotnoü iloci
posiadanej pami ci 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 mi dzy
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 najwi cej uwagi zasáuguj dyski twarde, jako *e obecnie s niezb dnym
elementem ka*dego komputera. Zwane s czasem pami ci trwaá (z wyjanionych
wy*ej wzgl dó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 pami ci operacyjnej. Ich wykorzystanie
ogranicza si wi c z reguáy do jednorazowego wczytywania du*ych zestawów danych (na
przykáad caáych plików) do pami ci operacyjnej, poczynienia dowolnej iloci zmian oraz
powtórnego, trwaáego zapisania. Wszelkie operacje np. na otwartych dokumentach s
wi c w zasadzie dokonywane na ich kopiach, rezydujcych wewntrz pami ci
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 wi cej ni*
jeden sposób na dokonanie tego. Pierwszy zdarzy si przy okazji omawiania strumieni,
b dcych cz ci Biblioteki Standardowej C++.

Organizacja pami ci operacyjnej

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

Podstawy programowania

248

Adresowanie pami ci

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 pami ci nazywamy jego adresem.
W ten sposób dochodzimy te* do poj cia wska(nika:

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

Jest to wi c w istocie liczba, interpretowana jako unikalny indeks danego miejsca w
pami ci. Specjalne znaczenie ma tu jedynie wartoü zero, interpretowana jako wska(nik
pusty (ang. null pointer), czyli nieodnoszcy si do *adnej konkretnej komórki pami ci.
Wska(niki sáu* wi c jako ácz do okrelonych miejsc w pami ci operacyjnej; poprzez
nie mo*emy odwoáywaü si do tych*e miejsc. B dziemy 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 j zyku C++, powi ümy nieco
uwagi na to, w jaki sposób systemy operacyjne zajmuj si organizacj i systematyzacj
pami ci 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) wi kszoü
programistów nie mogáa byü zbytnio zadowolona z metod, jakich musieli u*ywaü, by
obsáugiwaü wi ksze iloci pami ci operacyjnej. Byáa ona bowiem podzielona na tzw.
segmenty, ka*dy o wielkoci 64 kilobajtów.
Aby zidentyfikowaü konkretn komórk nale*aáo wi c 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 pami ci. Adres zaznaczonej komórki zapisywano zwykle

jako 012A:0007, a wi c 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 wi kszym ni* owe 64 kB (a wi c
chocia*by na dáugich napisach). Chodzi te* o fakt, i* to programista musiaá martwiü si o
rozmieszczenie kodu oraz danych pisanego programu w pami ci 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 pami ci

Dzisiejsze systemy operacyjne maj znacznie wygodniejszy sposób organizacji pami ci
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, wi c 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
dost pnych rodzajów pami ci 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 pami ci odnosi si dany
wska(nik! Na poziomie j zyka programowania znikaj bowiem wszelkie praktyczne
ró*nice mi dzy nimi: oto mamy jeden, wielki segment caáej pami ci operacyjnej i
basta!

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

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

rodzaju pami ci, na przykáad do takich jak na ilustracji.

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

adresow, niedost pn dla innych. Wymiana danych mo*e wi c zachodzi jedynie poprzez

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

programowania aplikacji okienkowych.

Przy takim modelu pami ci 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 pami ci
operacyjnych, a wi c wáanie o stosie oraz stercie.

Czym jest stos?

Stos (ang. stack) jest obszarem pami ci, 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 wi c 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). Wyst puje on zwykle wtedy, gdy nastpi zbyt wiele wywoáa funkcji.

O stercie

Reszta pami ci operacyjnej nosi oryginaln nazw sterty.

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

Czytajc oba opisy (stosu i sterty) pewnie trudno jest wychwyciü mi dzy 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 wi c mieü staáy rozmiar - jak na przykáad skalarne zmienne,
struktury czy te* statyczne tablice.
Kontrol pami ci 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 cz sto wykorzystywane struktury danych. Omówimy je przy okazji

poznawania Biblioteki Standardowej C++.

***

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

Wiedza ta b dzie nam teraz szczególnie przydatna, gdy* rozpoczynamy wreszcie
zasadnicz cz ü tego rozdziaáu, czyli omówienie wska(ników w j zyku 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 pami ci operacyjnej. Mechanizm
wska(ników na nie jest wi c 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 pami ci, i w takiej te* postaci istnieje
w programie. J zyk 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 kodera8
Od zera do gier kodera7
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