Od zera do gier kodera5

Záo*one zmienne

151

(Pole != ZgodnePole)

{

ZgodnePole = Pole;

uLiczbaZgodnychPol

;

}

else

++uLiczbaZgodnychPol;

}

Koszmarnie wygldajca pierwsza linijka bloku powy*szej ptli nie bdzie wydawaü si a*
tak straszne, jeli uwiadomimy sobie, i* LINIE[i][j][

] oraz LINIE[i][j][

] to

odpowiednio: wspóárzdna pionowa oraz pozioma j-tego pola i-tej potencjalnie
wygrywajcej linii. Sáusznie wic u*ywamy ich jako indeksów tablicy g_aPlansza,
pobierajc stan pola do sprawdzenia.
Nastpujca dalej instrukcja warunkowa rozstrzyga, czy owe pole zgadza si z
ewentualnymi poprzednimi - tzn. je*eli na przykáad poprzednio sprawdzane pole
zawieraáo kóáko, to aktualne tak*e powinno mieciü ten symbol. W przypadku gdy
warunek ten nie jest speániony, sekwencja zgodnych pól „urywa si”, co oznacza w tym
wypadku wyzerowanie licznika uLiczbaZgodnychPol. Sytuacja przeciwstawna - gdy
badane pole jest ju* którym z kolei kóákiem lub krzy*ykiem - skutkuje naturalnie
zwikszeniem tego* licznika o jeden.
Po zakoczeniu caáej ptli (czyli wykonaniu trzech cykli, po jednym dla ka*dego pola)
nastpuje kontrola otrzymanych rezultatów. Najwa*niejszym z nich jest wspomniany
licznik uLiczbaZgodnychPol, którego wartoü konfrontujemy z trójk. Jednoczenie
sprawdzamy, czy „zgodzone” pole nie jest przypadkiem polem pustym, bo przecie* z
takiej zgodnoci nic nam nie wynika. Oba te testy wykonuje instrukcja:

(uLiczbaZgodnychPol ==

&& ZgodnePole != FLD_EMPTY)

Speánienie tego warunku daje pewnoü, i* mamy do czynienia z prawidáow sekwencj
trzech kóáek lub krzy*yków. Sáusznie wic mo*emy wtedy przyznaü palm zwycistwa
aktualnemu graczowi i zakoczyü caá funkcj:

g_StanGry = GS_WON;

return

true

;

W przeciwnym wypadku nasza gáówna ptla si zaptla w swym kolejnym cyklu i bada w
nim kolejn ustalon lini symboli - i tak a* do znalezienia pasujcej kolumny, rzdu lub
przektnej albo wyczerpania si tablicy przegldowej LINIE.

Uff?… Nie, to jeszcze nie wszystko! Nie zapominajmy przecie*, *e zwycistwo nie jest
jedynym mo*liwych rozstrzygniciem rozgrywki. Drugim jest remis - zapeánienie
wszystkich pól planszy symbolami graczy bez utworzenia *adnej wygrywajcej linii.
Jak obsáu*yü tak sytuacj? Wbrew pozorom nie jest to wcale trudne, gdy* mo*emy
wykorzystaü do tego fakt, i* przebycie przez program poprzedniej, wariackiej ptli
oznacza nieobecnoü na planszy *adnych uáo*e zapewniajcych zwycistwo. Niejako „z
miejsca” mamy wic speániony pierwszy warunek konieczny do remisu.
Drugi natomiast - szczelne wypeánienie caáej planszy - jest bardzo áatwy do sprawdzenia i
wymagania jedynie zliczenia wszystkich niepustych jej pól:

unsigned

uLiczbaZapelnionychPol =

;

for

(

int

i =

; i <

; ++i)

for

(

int

j =

; j <

; ++j)

(g_aPlansza[i][j] != FLD_EMPTY)

++uLiczbaZapelnionychPol;

Podstawy programowania

152

Je*eli jakim dziwnym sposobem iloü ta wyniesie 9, znaczyü to bdzie, *e gra musi si
zakoczyü z powodu braku wolnych miejsc :) W takich okolicznociach wynikiem
rozgrywki bdzie tylko maáo satysfakcjonujcy remis:

(uLiczbaZapelnionychPol ==

)

{

g_StanGry = GS_DRAW;

return

true

;

}

W taki oto sposób wykrylimy i obsáu*ylimy obydwie sytuacje „wyjtkowe”, koczce
gr - zwycistwo jednego z graczy lub remis. Pozostaáo nam jeszcze zajcie si bardziej
zwyczajnym rezultatem wykonania ruchu, kiedy to nie powoduje on *adnych
dodatkowych efektów. Nale*y wtedy przekazaü prawo do posunicia drugiemu graczowi,
co te* czynimy:

g_AktualnyGracz = (g_AktualnyGracz == SGN_CIRCLE ?

SGN_CROSS : SGN_CIRCLE);

Przy pomocy operatora warunkowego zmieniamy po prostu znak aktualnego gracza na
przeciwny (z kóáka na krzy*yk i odwrotnie), osigajc zamierzony skutek.
Jest to jednoczenie ostatnia czynnoü funkcji Ruch()! Wreszcie, po dáugich bojach i
bólach gáowy ;) mo*emy j zakoczyü zwróceniem bezwarunkowo pozytywnego wyniku:

return

true

;

a nastpnie udaü si po co do jedzenia ;-)

Funkcja RysujPlansze()

Jako ostatni napiszemy funkcj, której zadaniem bdzie wywietlenie na ekranie (czyli w
oknie konsoli) bie*cego stanu gry:

Screen 29. Ekran gry w kóáko i krzy*yk

Najwa*niejsz jego skáadow bdzie naturalnie osáawiona plansza, o zajcie której tocz
boje nasi dwaj gracze. Oprócz niej mo*na jednak wyró*niü tak*e kilka innych elementów.
Wszystkie one bd „rysowane” przez funkcj RysujPlansze(). Niezwáocznie wic
rozpocznijmy jej implementacj!

Tradycyjnie ju* pierwsze linijki s szukaniem dziury w caáym, czyli potencjalnego bádu.
Tym razem usterk bdzie wywoáanie kodowanej wáanie funkcji przez rozpoczciem
wáaciwego pojedynku, gdy* w tej sytuacji nie ma w zasadzie nic do pokazania. Logiczn
konsekwencj jest wtedy przerwanie funkcji:

(g_StanGry == GS_NOTSTARTED)

return

false

;

Záo*one zmienne

153

Jako *e jednak wierzymy w rozsdek programisty wywoáujcego pisan teraz funkcj
(czyli nomen-omen w swój wáasny), przejd(my raczej do kodowania jej wáaciwej czci
„rysujcej”.
Od czego zaczniemy? Odpowied( nie jest szczególnie trudna; co ciekawe, w przypadku
ka*dej innej gry i jej odpowiedniej funkcji byáaby taka sama. Rozpoczniemy bowiem od
wyczyszczenia caáego ekranu (czyli konsoli) - tak, aby mieü wolny obszar dziaáania.
Dokonamy tego poprzez polecenie systemowe CLS, które wywoáamy funkcj C++ o
nazwie system():

system (

"cls"

);

Majc oczyszczone przedpole przystpujemy do zasadniczego rysowania. Ze wzgldu na
specyfik tekstowej konsoli zmuszeni jestemy do zapeániania jej wierszami, od góry do
doáu. Nie powinno nam to jednak zbytnio przeszkadzaü.
Na samej górze umiecimy tytuá naszej gry, staáy i niezmienny. Kod odpowiedzialny za t
czynnoü przedstawia si wic raczej trywialnie:

std::cout <<

" KOLKO I KRZYZYK "

<< std::endl;

std::cout <<

"---------------------"

<< std::endl;

std::cout << std::endl;

)

dnych wra*e pocieszam jednak, i* dalej bdzie ju* ciekawiej :) Oto mianowicie

przystpujemy do prezentacji planszy w postaci tekstowej - z zaznaczonymi kóákami i
krzy*ykami postawionymi przez graczy oraz numerami wolnych pól. Operacj t
przeprowadzamy w sposób nastpujcy:

std::cout <<

" -----"

<< std::endl;

for

(

int

i =

; i <

; ++i)

{

// lewa czü ramki

std::cout

" |"

;

// wiersz

for

(

int

j =

; j <

; ++j)

{

(g_aPlansza[i][j] == FLD_EMPTY)

// numer pola

std::cout << i *

+ j +

;

else

// tutaj wywietlamy kóáko lub krzy*yk... ale jak? :)

}

// prawa czü ramki

std::cout

"|"

<< std::endl;

}
std::cout <<

" -----"

<< std::endl;

std::cout << std::endl;

Caáy kod to oczywicie znowu dwie zagnie*d*one ptle

for

- staáy element pracy z

dwuwymiarow tablic. Zewntrzna przebiega po poszczególnych wierszach planszy, za
wewntrzna po jej pojedynczych polach.
Wywietlenie takiego pola oznacza pokazanie albo jego numerku (je*eli jest puste), albo
du*ej litery O lub X, symulujcej wstawione we kóáko lub krzy*yk. Numerek wyliczamy
poprzez prost formuák i *

+ j +

(dodanie jedynki to znowu* kwestia indeksów

liczonych od zera), w której i jest numerem wiersza, za j - kolumny. Có* jednak zrobiü
z drugim przypadkiem - zajtym polem? Musimy przecie* rozró*niü kóáka i krzy*yki…
Mo*na oczywicie skorzystaü z instrukcji

lub operatora ?:, jednak ju* raz

zastosowalimy lepsze rozwizanie. Dopasujmy mianowicie staáe typu FIELD (ka*dy

Podstawy programowania

154

element tablicy g_aPlansza nale*y przecie* do tego typu) do znaków

'O'

'X'

Przypatrzmy si najpierw definicji rzeczonego typu:

enum

FIELD { FLD_EMPTY,

FLD_CIRCLE

SGN_CIRCLE,

FLD_CROSS

= SGN_CROSS };

Widaü nim skutek pierwszego zastosowania sztuczki, z której chcemy znowu skorzystaü.
Dotyczy on zreszt interesujcych nas staáych FLD_CIRCLE i FLD_CROSS, równych
odpowiednio SGN_CIRCLE i SGN_CROSS. Czy to oznacza, i* z triku nici?
Bynajmniej nie. Nie mo*emy wprawdzie bezporednio zmieniü wartoci interesujcych
nas staáych, ale mo*liwe jest „signicie do (ródeá” i zmodyfikowanie SGN_CIRCLE oraz
SGN_CROSS, zadeklarowanych w typie SIGN:

enum

SIGN { SGN_CIRCLE =

'O'

, SGN_CROSS =

'X'

};

T drog, porednio, zmienimy te* wartoci staáych FLD_CIRCLE i FLD_CROSS, przypisujc
im kody ANSI wielkich liter „O” i „X”. Teraz ju* mo*emy skorzystaü z rzutowania na typ

char

, by wywietliü niepuste pole planszy:

std::cout <<

static_cast

char

>(g_aPlansza[i][j]);

Kod rysujcy obszar rozgrywki jest tym samym skoczony.

Pozostaá nam jedynie komunikat o stanie gry, wywietlany najni*ej. Zale*nie od
bie*cych warunków (wartoci zmiennej g_StanGry) mo*e on przyjmowaü form proby
o wpisanie kolejnego ruchu lub te* zwyczajnej informacji o wygranej lub remisie:

switch

(g_StanGry)

{

case

GS_MOVE:

proba o nastpny ruch

std::cout

"Podaj numer pola, w ktorym"

<< std::endl;

std::cout

"chcesz postawic "

;

std::cout << (g_AktualnyGracz == SGN_CIRCLE ?

"kolko"

"krzyzyk"

) <<

": "

;

break

;

case

GS_WON:

// informacja o wygranej

std::cout

"Wygral gracz stawiajacy "

;

std::cout << (g_AktualnyGracz == SGN_CIRCLE ?

"kolka"

"krzyzyki"

) <<

"!"

;

break

;

case

GS_DRAW:

// informacja o remisie

std::cout

"Remis!"

;

break

;

}

Analizy powy*szego kodu mo*esz z áatwoci dokonaü samodzielnie

Na tym*e elemencie „scenografii” koczymy nasz funkcj RysujPlansze(), wieczc j
oczywicie zwyczajowym oddaniem wartoci

true

A jak*e! Ju* coraz rzadziej bd omawiaá podobnie elementarne kody (ródáowe, bdce prostym

wykorzystaniem doskonale ci znanych konstrukcji jzyka C++. Je*eli solennie przykáadaáe si do nauki, nie
powinno byü to dla ciebie *adn niedogodnoci, za w zamian pozwoli na dogábne zajcie si nowymi
zagadnieniami bez koncentrowania wikszej uwagi na banaáach.

Záo*one zmienne

155

return

true

;

Mo*emy na koniec zauwa*yü, i* piszc t funkcj uporalimy si jednoczenie z
elementem programu o nazwie „interfejs u*ytkownika” :D

Funkcja main(), czyli skáadamy program

Byü mo*e trudno w to uwierzyü, ale mamy za sob zaprogramowanie wszystkich funkcji
sterujcych przebiegiem gry! Zanim jednak bdziemy mogli cieszyü si dziaáajcym
programem musimy wypeániü kodem gáówn funkcj aplikacji, od której zacznie si jej
wykonywanie - main().

W tym celu zostawmy ju* wymczony moduá game.cpp i wróümy do main.cpp, w którym
czeka nietknity szkielet funkcji main(). Poprzedzimy go najpierw dyrektywami
doáczenia niezbdnych nagáówków - tak*e naszego wáasnego, game.h:

#include

#include

<conio.h>

#include

"game.h"

Wáasne pliki nagáówkowe najlepiej umieszczaü na kocu szeregu instrukcji

#include

doáczajc je po tych pochodzcych od kompilatora.

Teraz ju* mo*emy zajü si treci najwa*niejszej funkcji w naszym programie.
Zaczniemy od nastpujcego wywoáania:

StartGry();

Spowoduje ono rozpoczcie rozgrywki - jak pamitamy, oznacza to midzy innymi
wylosowanie gracza, któremu przypadnie pierwszy ruch, oraz ustawienie stanu gry na
GS_MOVE.
Od tego momentu zaczyna si wic zabawa, a nam przypada obowizek jej prawidáowego
poprowadzenia. Wywi*emy si z niego w nieznany dotd sposób - u*yjemy ptli
nieskoczonej:

for

(;;)

{

...

}

Konstrukcja ta wcale nie jest taka dziwna, a w grach spotyka si j bardzo czsto. Istota
ptli nieskoczonej jest czciowo zawarta w jej nazwie, a po czci mo*na j
wydedukowaü ze skáadni. Mianowicie, nie posiada ona *adnego warunku zakoczenia

wic w zasadzie wykonywaáaby si do koca wiata i o jeden dzie dáu*ej ;) Aby tego
uniknü, nale*y gdzie wewntrz jej bloku umieciü instrukcj

break

;, która spowoduje

przerwanie tego zakltego krgu. Uczynimy to, kodujc kolejne instrukcje w tej*e ptli.
Najpierw funkcja RysujPlansze() wywietli nam aktualny stan rozgrywki:

RysujPlansze();

Poka*e wic tytuá gry, plansz oraz dolny komunikat - komunikat, który przez wikszoü
czasu bdzie prob o kolejny ruch. By sprawdziü, czy tak jest w istocie, porównamy
zmienn opisujc stan gry z wartoci GS_MOVE:

Zwanego te* czasem warunkiem terminalnym.

Podstawy programowania

156

(g_StanGry == GS_MOVE)

{

unsigned

uNumerPola;

std::cin >> uNumerPola;

Ruch

(uNumerPola);

}

Pozytywny wynik wspomnianego testu sáusznie skáania nas do u*ycia strumienia wejcia i
pobrania od u*ytkownika numeru pola, w które chce wstawiü swoje kóáko lub krzy*yk.
Przekazujemy go potem do funkcji Ruch(), serca naszej gry.
Nastpujce po sobie posunicia graczy, czyli kolejne cykle ptli, doprowadz w kocu do
rozstrzygnicia rozgrywki - czyjej wygranej albo obustronnego remisu. I to jest wáanie
warunek, na który czekamy:

else

(g_StanGry == GS_WON || g_StanGry == GS_DRAW)

break

;

Przerywamy wtedy ptl, zostawiajc na ekranie kocowy stan planszy oraz odpowiedni
komunikat. Aby u*ytkownicy mieli szans go zobaczyü, stosujemy rzecz jasna funkcj
getch():

getch();

Po odebraniu wcinicia dowolnego klawisza program mo*e si ju* ze spokojem
zamknü ;)

Uroki kompilacji

Fanfary! Zdaje si, *e wáanie zakoczylimy kodowanie naszego wielkiego projektu!
Nareszcie zatem mo*emy przeprowadziü jego kompilacj i uzyskaü gotowy do
uruchomienia plik wykonywalny.
Zróbmy wic to! Uruchom Visual Studio (je*eli je przypadkiem zamknáe), otwórz swój
projekt, zamknij drzwi i okna, wyprowad( zwierzta domowe, wácz automatyczn
sekretark i wcinij klawisz F7 (lub wybierz pozycj menu Build|Build Solution)…

***

Co si staáo? Wyglda na to, *e nie wszystko udaáo si tak dobrze, jak tego
oczekiwalimy. Zamiast dziaáajcej aplikacji kompilator uraczyá nas czterema bádami:

c:\Programy\TicTacToe\main.cpp(20) : error C2065: 'g_StanGry' : undeclared identifier
c:\Programy\TicTacToe\main.cpp(20) : error C2677: binary '==' : no global operator found which takes
type 'GAMESTATE' (or there is no acceptable conversion)
c:\Programy\TicTacToe\main.cpp(28) : error C2677: binary '==' : no global operator found which takes
type 'GAMESTATE' (or there is no acceptable conversion)
c:\Programy\TicTacToe\main.cpp(28) : error C2677: binary '==' : no global operator found which takes
type 'GAMESTATE' (or there is no acceptable conversion)

Wszystkie one dotycz tego samego, ale najwicej mówi nam pierwszy z nich.
Dwukrotnie kliknicie na dotyczcy go komunikat przeniesie nas bowiem do linijki:

(g_StanGry == GS_MOVE)

Wystpuje w niej nazwa zmiennej g_StanGry, która, sdzc po owym komunikacie, jest
tutaj uznawana za niezadeklarowan…
Ale dlaczego?! Przecie* z pewnoci umiecilimy jej deklaracj w kodzie programu. Co
wicej, stale korzystalimy z tej*e zmiennej w funkcjach StartGry(), Ruch() i

Záo*one zmienne

157

RysujPlansze(), do których kompilator nie ma najmniejszych zastrze*e. Czy*by wic
tutaj dopadáa go nagáa amnezja?

Wyjanienie tego, jak by si wydawaáo, doü dziwnego zjawiska jest jednak w miar
logiczne. Otó* g_StanGry zostaáa zadeklarowana wewntrz moduáu game.cpp, wic jej
zasig ogranicza si jedynie do tego* moduáu. Funkcja main(), znajdujca si w pliku
main.cpp, jest poza tym zakresem, zatem dla niej rzeczona zmienna po prostu nie
istnieje. Nic dziwnego, i* kompilator staje si wobec nieznanej nazwy g_StanGry
zupeánie bezradny.
Nasuwa si oczywicie pytanie: jak zaradziü temu problemowi? Co zrobiü, aby nasza
zmienna byáa dostpna wewntrz funkcji main()?… Chyba najszybciej pomyleü mo*na o
przeniesieniu jej deklaracji w obszar wspólny dla obu moduáów game.cpp oraz main.cpp.
Takim wspóádzielonym terenem jest naturalnie plik nagáówkowy game.h. Czy nale*y wic
umieciü tam deklaracj GAMESTATE g_StanGry = GS_NOTSTARTED;?
Niestety, nie jest to poprawne. Musimy bowiem wiedzieü, *e zmienna nie mo*e
rezydowaü wewntrz nagáówka! Jej prawidáowe zdefiniowanie powinno byü zawsze
umieszczone w module kodu. W przeciwnym razie ka*dy moduá, który doáczy plik
nagáówkowy z definicj zmiennej, stworzy swoj wáasn kopi tej*e! U nas znaczyáoby
to, *e zarówno main.cpp, jak i game.cpp posiadaj zmienne o nazwach g_StanGry, ale s
one od siebie caákowicie niezale*ne i „nie wiedz o sobie nawzajem”!

Definicja musi zatem pozostaü na swoim miejscu, ale plik nagáówkowy niewtpliwie nam
si przyda. Mianowicie, wpiszemy do nastpujc linijk:

extern

GAMESTATE g_StanGry;

Jest to tak zwana deklaracja zapowiadajca zmiennej. Jej zadaniem jest
poinformowanie kompilatora, *e gdzie w programie

istnieje zmienna o podanej nazwie

i typie. Deklaracja ta nie tworzy *adnego nowego bytu ani nie rezerwuje dla miejsca w
pamici operacyjnej, lecz jedynie zapowiada (std nazwa), i* czynnoü ta zostanie
wykonana. Obietnica ta mo*e byü speániona podczas kompilacji lub (tak jak u nas)
dopiero w czasie linkowania.
Z praktycznego punktu widzenia deklaracja

extern

(ang. external - zewntrzny) peáni

bardzo podobn rol, co prototyp funkcji. Podaje bowiem jedynie minimum informacji,
potrzebnych do skorzystania z deklarowanego tworu bez marudzenia kompilatora, a
jednoczenie odkáada jego wáaciw definicj w inne miejsce i/lub czas.

Deklaracja zapowiadajca (ang. forward declaration) to czciowe okrelenie jakiego
programistycznego bytu. Nie definiuje dokáadnie wszystkich jego aspektów, ale wystarcza
do skorzystania z niego wewntrz zakresu umieszczenia deklaracji.
Przykáadem mo*e byü prototyp funkcji czy u*ycie sáowa

extern

dla zmiennej.

Umieszczenie powy*szej deklaracji w pliku nagáówkowym game.h udostpnia zatem
zmienn g_StanGry wszystkim moduáom, które doácz wspomniany nagáówek. Tym
samym jest ju* ona znana tak*e funkcji main(), wic ponowna kompilacja powinna
przebiec bez *adnych problemów.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Czujny czytelnik zauwa*yá pewnie, *e doü swobodnie operuj terminami „deklaracja”

oraz „definicja”, u*ywajc ich zamiennie. Niektórzy puryci ka* jednak je rozró*niaü.

Wedáug nich jedynie to, co nazwalimy przed momentem „deklaracja zapowiadajc”,

mo*na nazwaü krótko „deklaracj”. „Definicj” ma byü za to dokáadne sprecyzowanie

cech danego obiektu, oraz, przede wszystkim, przygotowanie dla niego miejsca w

pamici operacyjnej.

Mówic cile: gdzie poza bie*cym zakresem.

Podstawy programowania

158

Zgodnie z tak terminologi instrukcje w rodzaju

int

nX; czy

float

fY; miaáyby byü

„definicjami zmiennych”, natomiast

extern int

nX; oraz

extern float

fY; -

„deklaracjami”. Osobicie twierdz, *e jest to jeden z najjaskrawszych przykáadów

szukania dziury w caáym i prób niezmiernego gmatwania programistycznego sáownika.

Czy ktokolwiek przecie* mówi o „definicjach zmiennych”? Pojcie to brzmi tym bardziej

sztucznie, *e owe „definicje” nie przynosz *adnych dodatkowych informacji w stosunku

do „deklaracji”, a skáadniowo s od nich nawet krótsze!

Jak wic w takiej sytuacji nie nazwaü spierania si o nazewnictwo zwyczajnym

malkontenctwem? :)

Uruchamiamy aplikacj

To niemal*e niewiarygodne, jednak staáo si faktem! Zakoczylimy w kocu
programowanie naszej gry! Wreszcie mo*esz wic u*yü klawisza F5, by cieszyü tym oto
wspaniaáym widokiem:

Screen 30. Gra w „Kóáko i krzy*yk” w akcji

A po kilkunastominutowym, zasáu*onym relaksie przy wáasnorcznie napisanej grze
przejd( do dalszej czci tekstu :)

Wnioski

Stworzyáe wáanie (przy drobnej pomocy :D) swój pierwszy w miar powa*ny program,
w dodatku to, co lubimy najbardziej - czyli gr. Zdobyte przy tej okazji dowiadczenie
jest znacznie cenniejsze od najlepszego nawet, lecz tylko teoretycznego wykáadu.

Warto wic podsumowaü nasz prac, a przy okazji odpowiedzieü na pewne ogólne
pytania, które byü mo*e przyszáy ci na myl podczas realizacji tego projektu.

Dziwaczne projektowanie

Tworzenie naszej gry rozpoczlimy od jej dokáadnego zaprojektowania. Miaáo ono na
celu wykreowanie komputerowego modelu znanej od dziesicioleci gry dwuosobowej i
zaadaptowanie go do potrzeb kodowania w C++.
W tym celu podzielilimy sobie zadanie na trzy czci:

okrelenie struktur danych wykorzystywanych przez aplikacj

sprecyzowanie wykonywanych przez ni czynnoci

stworzenie interfejsu u*ytkownika

Aby zrealizowaü pierwsze dwie, musielimy przyjü doü dziwn i raczej nienaturaln
drog rozumowania. Nale*aáo bowiem zapomnieü o takich „namacalnych” obiektach jak
plansza, gracz czy rozgrywka. Zamiast tego mówilimy o pewnych danych, na których
program miaá wykonywaü jakie operacje.
Te dwa wiaty - statycznych informacji oraz dynamicznych dziaáa - rozdzieliáy nam owe
„naturalne” obiekty zwizane z gr i kazaáy oddzielnie zajmowaü si ich cechami (jak np.
symbole graczy) oraz realizowanymi przeze czynnociami (np. wykonanie ruchu).

Záo*one zmienne

159

Podejcie to, zwane programowaniem strukturalnym, mogáo byü dla ciebie trudne do
zrozumienia i sztuczne. Nie martw si tym, gdy* podobnie uwa*a wikszoü
wspóáczesnych koderów! Czy to znaczy, *e programowanie jest udrk?
Domylasz si pewnie, *e wszystko co niedawno uczynilimy, daáoby si zrobiü bardziej
naturalnie i intuicyjne. Masz w tym caákowit racj! Ju* w nastpnym rozdziale poznamy
znacznie wygodniejsz i przyja(niejsz technik programowania, który zbli*y kodowanie
do ludzkiego sposobu mylenia.

Doü skomplikowane algorytmy

Kiedy ju* uporalimy si z projektowaniem, przyszedá czas na uruchomienie naszego
ulubionego rodowiska programistycznego i wpisanie kodu tworzonej aplikacji.

Jakkolwiek wikszoü u*ytych przy tym konstrukcji jzyka C++ byáa ci znana od dawna,
a du*a czü pozostaáej mniejszoci wprowadzona w tym rozdziale, sam kod nie nale*aá z
pewnoci do elementarnych. Ró*nica midzy poprzednimi, przykáadowymi programami
byáa znaczca i widoczna niemal przez caáy czas.
Na czym ona polegaáa? Po prostu jzyk programowania przestaá tu byü celem, a staá si

rodkiem. Ju* nie tylko pr*yá swe „muskuáy” i prezentowaá szeroki wachlarz mo*liwoci.

Staá si w pokornym sáug, który speániaá nasze wymagania w imi wy*szego d*enia,
którym byáo napisanie dziaáajcej i sensownej aplikacji.

Oczywiste jest wic, i* zaczlimy wymagaü wicej tak*e od siebie. Pisane algorytmy nie
byáy ju* trywialnymi przepisami, wywa*ajcymi otwarte drzwi. Wy*yny w tym wzgldzie
osignlimy chyba przy sprawdzaniu stanu planszy w poszukiwaniu ewentualnych
sekwencji wygrywajcych. Zadanie to byáo swoiste i unikalne dla naszego kodu, dlatego
te* wymagaáo nieszablonowych rozwiza. Takich, z jakimi bdziesz si czsto spotykaá.

Organizacja kodu

Ostatnia uwaga dotyczy porzdku, jaki wprowadzilimy w nasz kod (ródáowy. Zamiast
pojedynczego moduáu zastosowalimy dwa i zintegrowalimy je przy pomocy wáasnego
pliku nagáówkowego.

Nie obyáo si rzecz jasna bez drobnych problemów, ale ogólnie zrobilimy to w caákowicie
poprawny i efektywny sposób. Nie mo*na te* zapominaü o tym, *e jednoczenie
poznalimy kolejny skrawek informacji na temat programowania w C++, tym razem
dotyczcy dyrektywy

#include

, prototypów funkcji oraz modyfikatora

extern

Drogi samodzielny programisto - ty, który dokoczyáe kod gry od momentu, w którym

rozstalimy si nagáówkiem game.h, bez zagldania do dalszej czci tekstu!

Je*eli udaáo ci si dokonaü tego z zachowaniem zaáo*onej funkcjonalnoci programu oraz

podziaáu kodu na trzy odrbne pliki, to naprawd chyl czoáa :) Znaczy to, *e jeste

wrcz idealnym kandydatem na wietnego programist, gdy* sam potrafiáe rozwizaü

postawiony przed tob szereg problemów oraz znalazáe brakujce ci informacje w

odpowiednich (ródáach. Gratulacje!

Aby jednak uniknü ewentualnych káopotów ze zrozumieniem dalszej czci kursu,

doradzam powrót do opuszczonego fragmentu tekstu i przeczytanie chocia* tych

urywków, które dostarczaj wspomnianych nowych informacji z zakresu jzyka C++.

Podsumowanie

Dotarlimy (wreszcie!) do koca tego rozdziaáu. Nabyáe w nim bardzo du*o wiadomoci
na temat modelowania záo*onych struktur danych w C++.

Podstawy programowania

160

Zaczlimy od prezentacji tablic, czyli zestawów okrelonej liczby tych samych
elementów, opatrzonych wspóln nazw. Poznalimy sposoby ich deklaracji oraz u*ycia w
programie, a tak*e mo*liwe zastosowania.
Dalej zajlimy si definiowaniem nowych, wáasnych typów danych. Wród nich byáy typy
wyliczeniowe, dopuszczajce jedynie kilka mo*liwych wartoci, oraz agregaty w rodzaju
struktur, zamykajce kilka pojedynczych informacji w jedn caáoü. Zetknlimy si przy
tym z wieloma przykáadami ich zastosowania w programowaniu.
Wreszcie, na ukoronowanie tego i kilku poprzednich rozdziaáów stworzylimy caákiem
spory i caákiem skomplikowany program, bdcy w dodatku gr! Mielimy niepowtarzaln
okazj na zastosowanie zdobytych ostatnimi czasy umiejtnoci w praktyce.

Kolejny rozdziaá przyniesie nam natomiast zupeánie nowe spojrzenie na programowanie w
C++.

Pytania i zadania

Jako *e mamy za ju* sob sporo wyczerpujcego kodowania, nie zadam zbyt wielu
programów do samodzielnego napisania. Nie uciekniesz jednak od pyta sprawdzajcych
wiedz! :)

Pytania

Co to jest tablica? Jak deklarujemy tablice?

W jaki sposób u*ywamy ptli

for

oraz tablic?

Jak C++ obsáuguje tablice wielowymiarowe? Czym s one w istocie?

Czym s i do czego sáu* typy wyliczeniowe? Dlaczego s lepsze od zwykáych
staáych?

Jak definiujemy typy strukturalne?

Jak drog mo*na dostaü si do pojedynczych pól struktury?

wiczenia

Napisz program, który pozwoli u*ytkownikowi na wprowadzenie dowolnej iloci
liczb (iloü t bdzie podawaá na pocztku) i obliczenie ich redniej arytmetycznej.
Podawane liczby przechowuj w 100-elementowej tablicy (wykorzystasz ze tylko
czü).
(Trudne) Mo*esz te* zrobiü tak, by program nie pytaá o iloü liczb, lecz prosiá o
kolejne a* do wpisania innych znaków.
(Bardzo trudne) Czy mo*na jako zapobiec marnotrawstwu pamici,
zwizanemu z tak du*, lecz u*ywan tylko czciowo tablic? Jak?

Stwórz aplikacj, która bdzie pokazywaáa liczb dni do koca bie*cego roku.
Wykorzystaj w niej struktur tm i funkcj localtime() w taki sam sposób, jak w
przykáadzie

Biorhytm

(Trudne) W naszej grze w kóáko i krzy*yk jest ukryta pewna usterka. Objawia si
wtedy, gdy gracz wpisze co innego ni* liczb jako numer pola. Spróbuj naprawiü
ten bád; niech program reaguje tak samo, jak na wartoü spoza przedziaáu
<1; 9>.
Wskazówka: zadanie jest podobne do trudniejszego wariantu üwiczenia 1.

(Bardzo trudne) Ulepsz napisan gr. Niech rozmiar planszy nie bdzie zawsze
wynosiá 3u3, lecz mógá byü zdefiniowany jako staáa w pliku game.h.
Wskazówka: poniewa* plansza pozostanie kwadratem, warunkiem zwycistwa
bdzie nadal uáo*enie linii poziomej, pionowej lub ukonej z wáasnych symboli.
Modyfikacji musi jednak ulec algorytm sprawdzania planszy (ten straszny :D) oraz
sposób numerowania i rysowania pól.

OBIEKTY

y*ka nie istnieje…

Neo w filmie „Matrix”

Lektura kilku ostatnich rozdziaáów daáa ci spore pojcie o programowaniu w jzyku C++,
ze szczególnym uwzgldnieniem sposób realizacji w nim pewnych algorytmów oraz
u*ycia takich konstrukcji jak ptle czy instrukcje warunkowe. Zapoznaáe si tak*e z
mo*liwociami, jakie oferuje ten jzyk w zakresie manipulowania bardziej záo*onymi
porcjami informacji.

Wreszcie, miaáe sposobnoü realizacji konkretnej aplikacji - poczynajc od jej
zaprojektowania, a na kodowaniu i ostatecznej kompilacji skoczywszy. Wierz, i* samo
programowanie byáo wtedy raczej zrozumiaáe - chocia* nie pisalimy ju* wówczas
trywialnego kodu.
Podejrzewam jednak, *e wstpne konstruowanie programu nosiáo dla ciebie znamiona co
najmniej dziwnej czynnoci; wspominaáem o tym zreszt w podsumowaniu caáego
naszego projektu, obiecujc pokazanie w niniejszym rozdziale znacznie przyja(niejszej,
naturalniejszej i, jak sdz, przyjemniejszej techniki programowania. Przyszedá czas, by
speániü t obietnic.

Zatem nie tracc czasu, zajmijmy si tym wyczekiwanym tsknie zagadnieniem :)

Przedstawiamy klasy i obiekty

Poznamy teraz sposób kodowania znany jako programowanie obiektowe (ang. object-
oriented programming - OOP), które speánia wszystkie niedawno záo*one przeze mnie
obietnice. Nie dziwi wic, i* jest to najszerzej stosowana przez dzisiejszych programistów
technika projektowania i implementacji programów.

Nie zawsze jednak tak byáo; myl zatem, *e warto przyjrzeü si drodze, jak pokonaá
fach o nazwie programowanie komputerów - od pocztku a* do chwili obecnej. Dziki
temu bdziemy mogli lepiej doceniü u*ywane przez siebie narzdzia, z C++ na czele :)

Skrawek historii

Pomysá programowania komputerów jest nawet starszy ni* one same. Zanim bowiem
powstaáy pierwsze maszyny zdolne do wykonywania sekwencji oblicze, istniaáo ju* wiele
teoretycznych modeli, wedle których miaáyby funkcjonowaü

Maáo zachcajce pocztki

Nie dziwi wic, i* pojawienie si „mózgów elektronowych”, jak wtedy nazywano
komputery, na wielu uniwersytetach w latach 50. wywoáaáo spory entuzjazm. Mnóstwo

Najbardziej znanym jest maszyna Turinga.

Podstawy programowania

162

ludzi zaczáo zajmowaü si oprogramowywaniem tych wielkich i topornych urzdze. Byáa
to praca na wskro heroiczna - zwa*ywszy, *e „pisanie” programów oznaczaáo wtedy
odpowiednie dziurkowanie zwykáych papierowych kart i przepuszczanie je przez
wntrznoci maszyny. Najmniejszy bád zmuszaá do uruchamiania programu od pocztku,
co zazwyczaj skutkowaáo trafieniem na koniec kolejki oczekujcych na mo*liwoü
skorzystania z drogocennej mocy obliczeniowej.

Fotografia 1. ENIAC - pierwsza maszyna liczca nazwana komputerem, skonstruowana w

1946 roku. Byá to doprawdy cud techniki - przy poborze mocy równym zaledwie 130 kW mógá

wykonaü a* 5 tysicy oblicze na sekund (ok. milion razy mniej ni* wspóáczesne komputery).

(zdjcie pochodzi z serwisu

Internetowe Muzeum Starych Programów i Komputerów

)

Zwyczaj jej starannego wydzielania utrzymaá si przez wiele lat, choü z czasem techniki
programistyczne ulegáy usprawnieniu. Kiedy koderzy (a wáaciwie hakerzy, bo w tych
czasach gáównie maniacy zajmowali si komputerami) dostali wreszcie do dyspozycji
monitory i klawiatury (prymitywne i prawie w ogóle niepodobne do dzisiejszych cacek),
programowanie zaczáo bardziej przypominaü znajom nam czynnoü i staáo si nieco
á

atwiejsze. Jednak*e okrelenie „przyjazne” byáo jeszcze zdecydowanie przedwczesne :)

Zakodowanie programu oznaczaáo najczciej koniecznoü wklepywania dáugich rzdów
numerków, czyli jego kodu maszynowego. Dopiero pó(niej pojawiáy si bardziej
zrozumiaáe, lecz nadal niezbyt przyjazne jzyki asemblera, w których liczbowe
instrukcje procesora zastpiono ich sáownymi odpowiednikami. Caáy czas byáo to jednak
operowanie na bardzo niskim poziomie abstrakcji, cile zwizanym ze sprztem.
Listingi byáy wic maáo czytelne i podobne np. do poni*szego:

mov ah,

4Ch

int 21h

Przyznasz chyba, *e odgadnicie dziaáania tego* kodu wymaga nielichych zdolnoci
profetycznych

;)

Wy*szy poziom

Nie dziwi wic, *e kiedy tylko potencjaá komputerów na to pozwoliá (a staáo si to na
pocztku lat 70.), powstaáy znacznie wygodniejsze w u*yciu jzyki programowania
wysokiego poziomu (algorytmiczne), zwane te* jzykami drugiej generacji.
Zawieraáy one, tak oczywiste dla nas, lecz wówczas nowatorskie, konstrukcje w rodzaju
instrukcji warunkowych czy ptli. Nie byáy te* zale*ne od konkretnej platformy
sprztowej, co czyniáo programy w nich napisane wielce przenonymi. Tak narodziáo si
programowanie strukturalne.

Nie robi on jednak nic szczególnego, gdy* po prostu koczy dziaáanie programu :) O dziwo, te dwie linijki

powinny funkcjonowaü na prawie wszystkich dzisiejszych pecetach z systemami DOS lub Windows!

Obiekty

163

W tym okresie stworzone zostaáy znane i u*ywane do dzi jzyki - Pascal, C czy BASIC.
Programowanie staáo si áatwiejsze, bardziej dostpne i popularniejsze - równie* wród
niewielkiej jeszcze grupy u*ytkowników domowych komputerów. Pocignáo to za sob
tak*e rozwój oprogramowania: pojawiáy si systemy operacyjne w rodzaju Unixa, DOSa
czy Windows (wszystkie napisane w C), rosáa te* liczba przeznaczonych dla aplikacji.
Chocia* niekiedy pisano jeszcze drobne fragmenty kodu w asemblerze, ogromna
wikszoü projektów byáa ju* realizowana wedle zasad programowania strukturalnego.

Mo*na w zasadzie powiedzieü, *e z posiadanymi umiejtnociami sytuujemy si wáanie
w tym punkcie historii. Wprawdzie u*ywamy jzyka C++, ale dotychczas korzystalimy
jedynie z tych jego mo*liwoci, które byáy dostpne tak*e w C.
To si oczywicie wkrótce zmieni :)

Skostniaáe standardy

Czasy wietnoci metod programowania strukturalnego trwaáy zaskakujco dáugo, bo a*
kilkanacie lat. Mo*e to si wydawaü dziwne - szczególnie w odniesieniu do,
przywoáywanego ju* niejednokrotnie, wyjtkowo sztucznego projektowania kodu przy
u*yciu tych*e metod. Je*eli dodamy do tego fakt, i* ju* wtedy istniaáa caákiem poka(na
liczba jzyków trzeciej generacji, pozwalajcych na programowanie obiektowe

sytuacja jawi si wrcz niedorzecznie. Dlaczego koderzy nie porzucili swych wysáu*onych
i topornych instrumentów przez tak dáugi okres?…

„Winowajc” jest gáównie jzyk C, który zd*yá przez ten czas urosnü do rangi niemal
jedynego sáusznego jzyka programowania. Jako *e byá on narzdziem, którego u*ywano
nawet do pisania systemów operacyjnych, istniaáo mnóstwo jego kompilatorów oraz
ogromna liczba stworzonych w nim programów. Zmiana tak silnie zakorzenionego
standardu byáa w zasadzie niemo*liwa, tote* przez wiele lat nikt si jej nie podjá.

Obiektów czar

A* tu w 1983 roku duski programista Bjarne Stroustrup zaprezentowaá stworzony przez
siebie jzyk C++. Miaá on niezaprzeczaln zalet (jzyk, nie jego twórca ;D): áczyá
skáadni C (przez co zachowywaá kompatybilnoü z istniejcymi aplikacjami) z
mo*liwociami programowania zorientowanego obiektowo.
Fakt ten sprawiá, *e C++ zaczá powoli wypieraü swego poprzednika, zajmujc czoáowe
miejsce wród u*ywanych jzyków programowania. Zajmuje je zreszt do dzi.

Obiektowych nastpców dorobiáy si te* dwa pozostaáe jzyki strukturalne. Pascal

wyewoluowaá w Object Pascala, który jest podstaw dla popularnego rodowiska Delphi.

BASIC’iem natomiast zaopiekowaá si Microsoft, tworzc z niego Visual Basic; dopiero

jednak ostatnie wersje tego jzyka (oznaczone jako .NET) mo*na nazwaü w peáni

obiektowymi.

Co dalej?

Zaraz, w takim razie programowanie obiektowe i nasz ulubiony jzyk C++ maj ju* z
gór dwadziecia lat - w wiecie komputerów to przecie* caáy eon! Czy zatem technologii
tej nie czeka rycháy schyáek?…

Mo*naby tak przypuszczaü, gdyby istniaáa inna, równorzdna wobec OOPu technika
programowania. Dotychczas jednak nikt nie wynalazá niczego takiego i nie zanosi si na
to w przewidywalnej przyszáoci :) Programowanie obiektowe ma si dzisiaj co najmniej

Byáy to na przykáad LISP albo Smalltalk.

Podstawy programowania

164

tak samo dobrze (a nawet znacznie lepiej), jak w chwili swego powstania i trudno sobie
nawet wyobraziü jego ewentualny zmierzch.

Naturalnie, zawsze mo*na si z tym nie zgodziü :) Niektórzy przekonuj nawet, i* istnieje
co takiego jak jzyki czwartej generacji, zwane równie* deklaratywnymi. Zaliczaj do
nich na przykáad SQL (jzyk zapyta do baz danych) czy XSL (transformacje XML).
Nie da si jednak ukryü faktu, *e obszar zastosowa ka*dego z tych jzyków jest bardzo
specyficzny i ograniczony. Je*eli bowiem kiedykolwiek bdzie mo*liwe tworzenie
zwykáych aplikacji przy pomocy nastpców tych*e jzyków, to lada dzie zbdni stan si
tak*e sami programici ;))

Pierwszy kontakt

Nadeszáa wreszcie pora, kiedy poznamy podstawowe zaáo*enia osáawionego
programowania obiektowego. Byü mo*e dowiemy si te*, dlaczego jest takie wspaniaáe ;)

Obiektowy wiat

Z nazwy tej techniki programowania nietrudno wywnioskowaü, *e jej najwa*niejszym
pojciem jest obiekt. Tworzc obiekty i definiujc ich nowe rodzaje mo*na zbudowaü
dowolny program.

Wszystko jest obiektem

Ale czym w istocie jest taki obiekt? W jzyku potocznym sáowo to mo*e przecie* oznaczaü
w zasadzie wszystko. Obiektem mo*na nazwaü lamp stojc na biurku, drzewo za
oknem, ssiedni dom, samochód na ulicy, a nawet caáe miasto. Jakkolwiek czasem bdzie
to doü dziwny sposób nazewnictwa, ale jednak nale*y go uznaü za caákowicie
dopuszczalny.

Rysunek 3, 4 i 5. Obiekty otaczaj nas z ka*dej strony

Mylc o programowaniu, znaczenie terminu ‘obiekt’ nie ulega zasadniczej zmianie. Tak*e
tutaj obiektem mo*e byü praktycznie wszystko. Ró*nica polega jednak na tym, i*
programista wystpuje wówczas w roli stwórcy, pana i wáadcy wykreowanego „wiata”.
Wprowadzajc nowe obiekty i zapewniajc wspóáprac midzy nimi, tworzy dziaáajcy
system, podporzdkowany realizacji okrelonego zadania.

Zanotujmy wic pierwsze spostrze*enie:

Obiekt mo*e reprezentowaü cokolwiek. Programista wykorzystuje obiekty jako cegieáki,
z których buduje gotowy program.

Obiekty

165

Okrelenie obiektu

Przed chwil wykazalimy, *e programowanie nie jest wcale tak oderwane od
rzeczywistoci, jak si powszechnie sdzi :D Faktycznie techniki obiektowe powstaáy
wáanie dlatego, *eby przybli*yü nieco kodowanie do prawdziwego wiata.

O ile jednak w odniesieniu do niego mo*emy swobodnie u*ywaü doü enigmatycznego
stwierdzenia, *e „obiektem mo*e byü wszystko”, o tyle programowanie nie znosi przecie*
*

adnych niecisáoci. Obiekt musi wic daü si jasno zdefiniowaü i w jednoznaczny sposób

reprezentowaü w programie.
Wydawaü by si mogáo, i* to du*e ograniczenie. Ale czy tak jest naprawd?…

Wiele wskazuje na to, *e nie. Pojcie obiektu w rozumieniu programistycznym jest
bowiem na tyle elastyczne, *e mieci w sobie niemal wszystko, co tylko mo*na sobie
wymarzyü. Mianowicie:

Obiekt skáada si z opisujcych go danych oraz mo*e wykonywaü ustalone czynnoci.

Podobnie jak omówione niedawno struktury, obiekty zawieraj pola, czyli zmienne. Ich
rol jest przechowywanie pewnych informacji o obiekcie - jego charakterystyki.
Oczywicie, liczba i typy pól mog byü swobodnie definiowane przez programist.
Oprócz tego obiekt mo*e wykonywaü na sobie pewne dziaáania, a wic uruchamiaü
zaprogramowane funkcje; nazywamy je metodami albo funkcjami skáadowymi.
Czyni one obiekt tworem aktywnym - nie jest on jedynie pojemnikiem na dane, lecz
mo*e samodzielnie nimi manipulowaü.

Co to wszystko oznacza w praktyce? Najlepiej bdzie, je*eli przeledzimy to na
przykáadzie.
Zaáó*my, *e chcemy mieü w programie obiekt jadcego samochodu (bo mo*e piszemy
wáanie gr wycigow?). Ustalamy wic dla niego pola, które bd go okrelaáy, oraz
metody, które bdzie mógá wykonywaü.
Polami mog byü widoczne cechy auta: jego marka czy kolor, a tak*e te mniej rzucajce
si w oczy, lecz pewnie wa*ne dla nas: dáugoü, waga, aktualna prdkoü i maksymalna
szybkoü. Natomiast metodami uczynimy czynnoci, jakie nasz samochód mógáby
wykonywaü: przyspieszenie, hamowanie albo skrt.
W ten oto prosty sposób stworzymy wic komputerow reprezentacj samochodu. W
naszej grze moglibymy mieü wiele takich aut i nic nie staáoby na przeszkodzie, aby
ka*de miaáo np. inny kolor czy mark. Kiedy za dla jednego z nich wywoáalibymy
metod skrtu czy hamowania, zmieniáaby si prdkoü tylko tego jednego samochodu
- zupeánie tak, jakby kierowca poruszyá kierownic lub wcisná hamulec.

Schemat 16. Przykáadowy obiekt samochodu

W idei obiektu widaü zatem przeciwiestwo programowania strukturalnego. Tam
musielimy rozdzielaü dane programu od jego kodu, co przy wikszych projektach
prowadziáoby do sporego baáaganu. W programowaniu obiektowym jest zgoáa odwrotnie:
tworzymy niewielkie czstki, bdce poáczeniem informacji oraz dziaáania. S one

Podstawy programowania

166

niemal „namacalne”, dlatego áatwiej jest nam myleü o nich o skáadnikach programu,
który budujemy.

Zapiszmy zatem drugie spostrze*enie:

Obiekty zawieraj zmienne, czyli pola, oraz mog wykonywaü dla siebie ustalone
funkcje, które zwiemy metodami.

Obiekt obiektowi nierówny

Zestaw pól i metod rzadko jest charakterystyczny dla pojedynczego obiektu. Najczciej
istnieje wiele obiektów, ka*dy z wáaciwymi sobie wartociami pól. àczy je jednak
przynale*noü do jednego i tego samego rodzaju, który nazywamy klas.

Klasy wprowadzaj wic pewn systematyk w wiat obiektów. Byty nale*ce do tej
samej klasy s bowiem do siebie podobne: maj ten sam pakiet pól oraz mog
wykonywaü na sobie te same metody. Informacje te zawarte s w definicji klasy i
wspólne dla wszystkich wywodzcych si z niej obiektów.
Klasa jest zatem czym w rodzaju wzorca - matrycy, wedle którego „produkowane” s
kolejne obiekty (instancje) w programie. Mog one ró*niü si od siebie, ale tylko co do
wartoci poszczególnych pól; wszystkie bd jednak nale*eü do tej samej klasy i bd
mogáy wykonywaü na sobie te same metody.

Kot o czarnej sierci i kot o biaáej sierci to przecie* jeden i ten sam gatunek Felis catus…

Schemat 17. Definicja klasy oraz kilka nale*cych do obiektów (jej instancji)

W programowaniu obiektowym zadaniem twórcy jest przede wszystkim zaprojektowanie
modelu klas programu, zawierajcego definicj wszystkich klas wystpujcych w
aplikacji. Podczas dziaáania programu bd z nich tworzone obiekty, których wspóápraca
ma zapewniü realizacj celów aplikacji (przynajmniej w teorii ;D).

Obiekty

167

Zatem zamiast zajmowaü si oddzielnie danymi oraz kodem, bierzemy pod uwag ich
odpowiednie poáczenia - obiekty, „aktywne struktury”. Definiujc odpowiednie klasy
oraz umieszczajc w programie instrukcje kreujce obiekty tych klas, budujemy nasz
program kawaáek po kawaáku.
Byü mo*e brzmi to teraz troch tajemniczo, lecz niedáugo zobaczysz, i* w gruncie rzeczy
jest bardzo proste.

Sformuáujmy na koniec ostatnie spostrze*enie:

Ka*dy obiekt nale*y do pewnej klasy. Definicja klasy zawiera pola, z których skáada si
ów obiekt, oraz metody, którymi dysponuje.

Co na to C++?

Zakoczmy na razie te nieco zbyt teoretyczne dywagacje i zajmijmy si tym, co
programici lubi najbardziej, czyli kodowaniem :) Zobaczymy, jak C++ radzi sobie z
ide programowania obiektowego. Na razie spojrzymy na to zagadnienie przez kilka
prostych przykáadów, by pó(niej zagábiü si w nie nieco bardziej.

Definiowanie klas

Pierwszym i bardzo wa*nym etapem tworzenia kodu opartego na idei OOP jest, jak sobie
powiedzielimy, zdefiniowanie odpowiednich klas. W C++ jest to caákiem proste.

Klasy s tu de facto nowymi typami danych, podobnymi w pewnym sensie do struktur

Dlatego te* naturalnym miejscem umieszczania ich definicji s pliki nagáówkowe -
umo*liwia to áatwe wykorzystanie klasy w obrbie caáego programu.
Spójrzmy zatem na przykáadow definicj typu obiektów, który pary razy przewijaá si w
tekcie:

class

CCar

{

private

float

m_fMasa;

COLOR

m_Kolor;

VECTOR2

m_vPozycja;

public

VECTOR2

vPredkosc;

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

metody

void

Przyspiesz(

float

fIle);

void

Hamuj(

float

fIle);

void

Skrec(

float

fKat);

};

Zastosowanie tu typy danych COLOR i VECTOR2 maj charakter umowny. Powiedzmy, *e
COLOR w jaki sposób reprezentuje kolor, za VECTOR2 jest dwuwymiarowym wektorem (o
wspóárzdnych x i y).

Porównanie do struktury jest caákiem na miejscu, chocia* pojawiáo nam si kilka nowych
elementów, w tym najbardziej oczywiste zastpienie sáowa kluczowego

struct

przez

class

W C++ ró*nica midzy klas a struktur jest zreszt czysto kosmetyczna.

Podstawy programowania

168

Najwa*niejsze dla nas jest jednak pojawienie si deklaracji metod klasy. Maj one tutaj
form prototypów funkcji, wic bd musiaáy byü zaimplementowane gdzie indziej (jak -
o tym niedáugo powiemy). Równie dobrze wszak mo*na wpisywaü kod krótkich metod
bezporednio w definicji ich klasy.
Oprócz tego mamy w naszej klasie tak*e pewne pola, które deklarujemy w identyczny
sposób jak zmienne czy pola w strukturach. To one stanowi treü obiektów, nale*cych
do definiowanej klasy.

Nietrudno zauwa*yü, *e caáa definicja jest podzielona na dwie czci poprzez etykiety

private

public

. Byü mo*e domylasz , có* mog one znaczyü; je*eli tak, to punkt dla

ciebie :) A jeli nie, nic straconego - niedáugo wyjanimy ich dziaáanie. Chwilowo mo*esz
je wic zignorowaü.

Implementacja metod

Zdefiniowanie typu obiektowego, czyli klasy, nie jest najczciej ostatnim etapem jego
okrelania. Je*eli bowiem umiecilimy we prototypy jakich metod, nieodzowne jest
wpisanie ich kodu w którym z moduáów programu. Zobaczmy zatem, jak nale*y to
robiü.

Przede wszystkim nale*y udostpniü owemu moduáowi definicj klasy, co prawie zawsze
oznacza koniecznoü doáczenia zawierajcego j pliku nagáówkowego. Jeli zatem nasza
klasa jest zdefiniowana w pliku klasa.h, to w module kodu musimy umieciü dyrektyw:

#include

"klasa.h"

Potem mo*emy ju* przystpiü do implementacji metod.

Ich kody wprowadzamy w niemal ten sam sposób, który stosujemy dla zwykáych funkcji.
Jedyna ró*nica tkwi bowiem w nagáówkach tych*e metod, na przykáad:

void

CCar::Przyspiesz(

float

fIle)

{

// tutaj kod metody

}

Zamiast wic samej nazwy funkcji mamy tutaj tak*e nazw odpowiedniej klasy,
umieszczon wczeniej. Oba te miana rozdzielamy znanym ju* skdind operatorem
zasigu ::.
Dalej nastpuje zwyczajowa lista parametrów i wreszcie zasadnicze ciaáo metody.
Wewntrz tego bloku zamieszczamy instrukcje, skáadajce si na kod danej funkcji.

Tworzenie obiektów

Posiadajc zdefiniowan i zaimplementowan klas, mo*emy pokusiü si o stworzenie
paru przynale*nych jej obiektów.

Istnieje przynajmniej kilka sposobów na wykonanie tej czynnoci, z których najprostszy
nie ró*ni si niczym od zadeklarowania struktury i wyglda chocia*by tak:

CCar Samochod;

Kod ten spowoduje zadeklarowanie nowej zmiennej Samochod typu CCar oraz
stworzenie obiektu nale*cego do tej klasy. Podkrelam to, gdy* moment tworzenia
obiektu nie jest wcale tak báah spraw i mo*e powodowaü ró*ne akcje. Powiemy sobie
o tym niedáugo.

Obiekty

169

Majc ju* obiekt (a wic instancj klasy), jestemy w stanie operowaü na wartociach
jego pól oraz wywoáywaü przynale*ne jego klasie metody. Posáugujemy si tu znajomym
operatorem kropki (.):

// przypisanie wartoci polu

Samochod.vPredkosc.x =

100.0

;

Samochod.vPredkosc.y =

50.0

;

// wywoáanie metody obiektu

Samochod.Przyspiesz (

10.0

);

Czy nie spotkalimy ju* kiedy czego podobnego?… Zdaje si, *e tak. Przy okazji
á

acuchów znaków pojawiáa si bowiem konstrukcja typu strTekst.length(), której

u*ylimy do pobrania dáugoci napisu strTekst.
Byáo to nic innego jak tylko wywoáanie metody length() dla obiektu strTekst! Napisy w
C++ s wic obiektami, pochodzcymi od klasy std::string. Oprócz length()
posiadaj zreszt wiele innych metod, uáatwiajcych prac z nimi. Wikszoü poznamy
podczas omawiania Biblioteki Standardowej.

Kod wyglda zatem caákiem logicznie i spójnie; áatwo bowiem znale(ü wszystkie
instrukcje dotyczce obiektu Samochod, bo zaczynaj si one od jego nazwy. To jedna
(choü mo*e maáo znaczca) z licznych zalet programowania obiektowego, które poznasz
wkrótce i na które z utsknieniem czekasz ;)

***

W tym podrozdziale zaliczylimy pierwsze spotkanie z programowaniem zorientowanym
obiektowo. Mamy wic ju* jakie pojcie o klasach, obiektach oraz ich polach i metodach
- tak*e w odniesieniu do jzyka C++.

Dalsza czü rozdziaáu bdzie miaáa charakter systematyzacyjno-uzupeániajcy :)
Wyjanimy i uporzdkujemy sobie wikszoü szczegóáów dotyczcych definiowania klas
oraz tworzenia obiektów. Informuj przeto, i* absencja na tym wa*nym wykáadzie bdzie
zdecydowanie nierozsdna!

Obiekty i klasy w C++

Szczycc si chlubnym mianem jzyka w peáni obiektowego, C++ posiada wszystko, co
niezbdne do praktycznej realizacji idei programowanie zorientowanego obiektowo. Teraz
wáanie przyjrzymy si dokáadnie tym konstrukcjom jzykowym - wytáumaczymy sobie
ich dziaáanie oraz sposób u*ycia.

Klasa jako typ obiektowy

Wiemy ju*, *e pisanie programu zgodnie z filozofi OOP polega na definiowaniu i
implementowaniu odpowiednich klas oraz tworzeniu z nich obiektów i manipulowaniu
nimi. Klasa jest wic dla nas pojciem kluczowym, które na pocztek wypadaáoby
wyjaniü:

Klasa to záo*ony typ zmiennych, skáadajcy si z pól, przechowujcych dane, oraz
posiadajcy metody, wykonujce zaprogramowane czynnoci.

Zmienne nale*ce do owych typów obiektowych nazywamy oczywicie obiektami.

Podstawy programowania

170

Ka*dy obiekt posiada swój wáasny pakiet opisujcych go pól, które rezyduj w pamici
operacyjnej w identyczny sposób jak pola struktur. Metody s natomiast kodem
wspólnym dla caáej klasy, zatem w czasie dziaáania programu istnieje w pamici tylko
jedna ich kopia, wywoáywana w razie potrzeby na rzecz ró*nych obiektów. Jest to, jak
sdz, doü oczywiste: tworzenie odrbnych kopii tych samych przecie* funkcji dla
ka*dego nowego obiektu byáoby niewtpliwie szczytem absurdu.

Dwa etapy okrelania klasy

Skoro dowiedzielimy si dokáadnie, czym s klasy i jak (w teorii) dziaáaj, spójrzmy na
sposoby ich wykorzystania w jzyku C++. Zaczniemy rzecz jasna od wprowadzania do
programu wáasnych typów obiektowych, gdy* bez tego ani rusz :)

Na pocztek warto przypomnieü, i* klasa jest typem (podobnie jak struktura czy

enum

wic wáaciwym dla niej miejscem byáby zawsze plik nagáówkowy. Jednoczenie jednak
zawiera ona kod swoich funkcji skáadowych, czyli metod, co czyni j przynale*n do
jakiego moduáu (bo tylko wewntrz moduáów mo*na umieszczaü funkcje).
Te dwa przeciwstawne stanowiska sprawiaj, *e okrelenie klasy jest najczciej
rozdzielone na dwie czci:

definicj, wstawian w pliku nagáówkowym, w której okrelamy pola klasy oraz
wpisujemy prototypy jej metod

implementacj, umieszczan w module, bdc po prostu kodem wczeniej
zdefiniowanych metod

Ukáad ten nie doü, *e dziaáa nadzwyczaj dobrze, to jeszcze realizuje jeden z postulatów
programowania obiektowego, jakim jest ukrywanie niepotrzebnych szczegóáów.
Tymi szczegóáami bdzie tutaj kod poszczególnych metod, którego znajomoü nie jest
wcale potrzebna do korzystania z klasy.

Co wicej, mo*e on nie byü w ogóle dostpny w postaci pliku .cpp, a jedynie w wersji
skompilowanej! Tak jest chocia*by w przypadku biblioteki DirectX, o czym przekonasz si
za czas jaki.

Domylasz si zatem, *e za chwil skoncentrujemy si na tych dwóch etapach okrelania
klasy, a wic na definicji i implementacji. Jakkolwiek nie brzmi to zbyt odkrywczo, jednak
masz tutaj caákowit sáusznoü :D

Czasem, jeszcze przed definicj klasy musimy poinformowaü kompilator, *e dana nazwa

jest faktycznie klas. Robimy tak na przykáad wtedy, gdy obiekt klasy A odwoáuje si do

klasy B, za B do A. U*ywamy wtedy deklaracji zapowiadajcej, piszc po prostu

class

A; lub

class

B;.

Takie przypadki s dosyü rzadkie, ale warto wiedzieü, jak sobie z nimi radziü. O tym

sposobie wspomnimy zreszt nieco dokáadniej, gdy bdziemy zajmowaü si klasami

zaprzyja(nionymi.

Definicja klasy

Jest to konieczna i czsto pierwsza czynnoü przy wprowadzaniu do programu nowej
klasy. Jej definicja precyzuje bowiem zawarte w niej pola oraz deklaracje metod, którymi
klasa bdzie dysponowaáa.

Informacje te s niezbdne, aby móc utworzyü obiekt danej klasy; dlatego te*
umieszczamy je niemal zawsze w pliku nagáówkowym - miejscu nale*nym wáasnym
typom danych.
Skáadnia definicji klasy wyglda natomiast nastpujco:

class

nazwa_klasy

Obiekty

171

{

[specyfikator_dostpu:]

[pola]

[metody]

};

Nie widaü w niej zbytnich restrykcji, gdy* faktycznie jest ona caákiem swobodna.
Kolejnoü poszczególnych elementów (pól lub metod) nie jest cile ustalona i mo*e byü
w zasadzie dowolnie zmieniana. Najlepiej jednak zachowaü w tym wzgldzie jaki
porzdek, grupujc np. pola i metody w zwarte grupy.
Na razie wszak*e trudno byáoby stosowaü si do tych rad, skoro nie omówilimy
dokáadnie wszystkich czci definicji klasy. Czym prdzej wic naprawiamy ten bád :)

Kontrola dostpu do skáadowych klasy

Fraza oznaczona jako specyfikator_dostpu pewnie nie mówi ci zbyt wiele, chocia*
spotkalimy si ju* z ni w której z przykáadowych klas. Przyjmowaáa ona tam form

private

lub

public

, dzielc caáa definicj na jakby dwie odrbne sekcje. Nietrudno

wywnioskowaü, i* podziaá ten nie ma jedynie charakteru wizualnego, ale powoduje dalej
idce konsekwencje. Jakie?…

Nazwa specyfikator_dostpu, chocia* brzmi mo*e nieco sztucznie (jak zreszt wiele
terminów w programowaniu :)), dobrze oddaje rol, jak ta konstrukcja peáni. Otó*
specyfikuje ona wáanie prawa dostpu do czci skáadowych klasy (czyli pól lub
metod), wyró*niajc ich dwa rodzaje: prywatne (ang. private) oraz publiczne
(ang. public).
Ró*nica midzy nimi jest znaczca i bardzo wa*na, gdy* wpáywa na to, które elementy
klasy s widoczne tylko w ramach jej samej, a które tak*e na zewntrz. Te pierwsze
nazywamy wic prywatnymi, za drugie publicznymi.

Prywatne skáadowe klasy (wpisane po sáowie

private

: w jej definicji) s dostpne

jedynie wewntrz samej klasy, tj. tylko dla jej wáasnych metod.

Publiczne skáadowe klasy (wpisane po sáowie

public

: w jej definicji) widoczne s

zawsze i wszdzie - nie tylko dla samej klasy (jej metod), ale na zewntrz - np. dla jej
obiektów.

Danym specyfikatorem objte s wszystkie nastpujce po nim czci klasy, a* do jej
koca lub… kolejnego specyfikatora :) Ich iloü nie jest bowiem niczym ograniczona.

Nic wic nie stoi na przeszkodzie, aby nie byáo ich wcale! W takiej sytuacji wszystkie

skáadowe bd miaáy domylne reguáy dostpu. W przypadku klas (definiowanych

poprzez

class

) jest to dostp prywatny, natomiast dla typów strukturalnych

(sáówko

struct

) - dostp publiczny.

Trudno uwierzyü, ale w C++ jest to jedyna ró*nica pomidzy klasami a strukturami!

Sáowa

class

struct

s wic niemal synonimami; jest to rzecz niespotykana w innych

jzykach programowania, w których te dwie konstrukcje s zupeánie odrbne.

Dla skuteczniejszego rozwiania z powy*szego opisu mo*liwej mgáy niejasnoci, spójrzmy
na ten oto przykáadowy program i klas:

// DegreesCalc - kalkulator temperatur

// typ wyliczeniowy okrelajcy skal temperatur

A tak*e dla unii, chocia* jak wiemy, funkcjonuj one inaczej ni* struktury i klasy.

Podstawy programowania

172

enum

SCALE {SCL_CELSIUS =

'c'

, SCL_FAHRENHEIT =

'f'

, SCL_KELVIN =

'k'

};

class

CDegreesCalc

{

private

// temperatura w stopniach Celsjusza

double

m_fStopnieC;

public

// ustawienie i pobranie temperatury

void

UstawTemperature(

double

fTemperatura, SCALE Skala);

double

PobierzTemperature(SCALE Skala);

};

// ------------------------- funkcja main() -----------------------------

void

main()

{

// zapytujemy o skal, w której bdzie wprowadzona wartoü

char

chSkala;

std::cout

"Wybierz wejsciowa skale temperatur"

<< std::endl;

std::cout

"(c - Celsjusza, f - Fahrenheita, k - Kelwina): "

;

std::cin >> chSkala;

(chSkala !=

'c'

&& chSkala !=

'f'

&& chSkala !=

'k'

)

return

;

// zapytujemy o rzeczon temperatur

float

fTemperatura;

std::cout

"Podaj temperature: "

;

std::cin >> fTemperatura;

// deklarujemy obiekt kalkulatora i przekazujemy do temp.

CDegreesCalc

Kalkulator;

Kalkulator.UstawTemperature

(fTemperatura,

static_cast

<SCALE>(chSkala));

// pokazujemy wynik - czyli temperatur we wszystkich skalach

std::cout << std::endl;

std::cout

"- stopnie Celsjusza: "

<< Kalkulator.PobierzTemperature(SCL_CELSIUS) << std::endl;

std::cout

"- stopnie Fahrenheita: "

<< Kalkulator.PobierzTemperature(SCL_FAHRENHEIT) << std::endl;

std::cout

"- kelwiny: "

<< Kalkulator.PobierzTemperature(SCL_KELVIN) << std::endl;

// czekamy na dowolny klawisz

getch();
}

Caáa aplikacja jest prostym programem przeliczajcym midzy trzema skalami
temperatur:

Screen 31. Kalkulator przeliczajcy wartoci temperatur

Obiekty

173

Jej peány kod, z implementacj metod klasy CDegreesCalc, znale(ü mo*na w programach
przykáadowych. Nas jednak bardziej interesuje forma definicji tej*e klasy oraz podziaá jej
skáadowych na prywatne oraz publiczne.
Widzimy wic wyra(nie, i* klasa posiada jedno prywatne pole - jest nim m_fStopnieC, w
którym zapisywana jest temperatura w wewntrznie u*ywanej, wygodnej skali Celsjusza.
Oprócz niego mamy jeszcze dwie publiczne metody - UstawTemperature() oraz
PobierzTemperature(), dziki którym uzyskujemy dostp do naszego prywatnego pola.
Jednoczenie oferuj nam jednak dodatkow funkcjonalnoü, jak jest dokonywanie
przeliczania pomidzy wartociami wyra*onymi w ró*nych miarach.

To bardzo czsta sytuacja, gdy prywatne pole klasy „obudowane” jest publicznymi
metodami, zapewniajcymi do dostp. Daje to wiele po*ytecznych mo*liwoci, jak
choüby kontrola przypisywanej polu wartoci czy tworzenie pól tylko do odczytu.
Jednoczenie „prywatnoü” pola chroni je przed przypadkow, niepo*dan ingerencj z
zewntrz.
Takie zjawisko wyodrbniania pewnych fragmentów kodu nazywamy hermetyzacj.

Jak wiemy, prywatne skáadowe klasy nie s dostpne poza ni sam. Kiedy wic
tworzymy nasz obiekt:

CDegreesCalc Kalkulator;

jestemy niejako „skazani” na korzystanie tylko z jego publicznych metod; próba
odwoáania si do prywatnego pola (poprzez Kalkulator.m_fStopnieC) skoczy si
bowiem bádem kompilacji.
Fakt ten wcale nas jednak nie ogranicza, lecz zabezpiecza przed niepowoáanym dostpem
do wewntrznych informacji klasy, które z zasady powinny byü do jej wyácznej
dyspozycji. Do komunikacji z otoczeniem istniej za to dwie publiczne metody, i to z nich
wáanie bdziemy korzystaü w funkcji main().

Najpierw wic wywoáujemy funkcj skáadow UstawTemperature(), podajc jej wpisan
przez u*ytkownika wartoü oraz wybran skal

Kalkulator.UstawTemperature (fTemperatura,

static_cast

<SCALE>(chSkala));

W tym momencie w ogóle nie interesuj nas dziaáania, które zostan na tych danych
podjte - jest to wewntrzna sprawa klasy CDegreesCalc (podobnie zreszt jak jej pole
m_fStopnieC). Wa*ne jest, *e w ich nastpstwie mo*emy u*yü drugiej metody,
PobierzTemperature(), do uzyskania podanej wczeniej wartoci w wybranej przez
siebie, nowej skali:

std::cout <<

"- stopnie Celsjusza: "

<< Kalkulator.PobierzTemperature(SCL_CELSIUS) << std::endl;

// itd.

Wszystkie kwestie dotyczce szczegóáowych aspektów przeliczania owych wartoci s
zatem szczelnie poukrywane. Kod funkcji main() jest klarowny i wolny od niepotrzebnych
detali, co nie zmienia faktu, i* w razie potrzeby mo*liwe jest zajcie si nimi. Wystarczy
przecie* rzuciü okiem implementacje metod klasy CDegreesCalc.

Zaprowadzanie porzdku poprzez ograniczanie dostpu do pewnych elementów klasy to
jedna z reguá, a jednoczenie zalet programowania obiektowego. Do jej praktycznej

Znowu stosujemy tu technik odpowiedniego dobrania wartoci typu wyliczeniowego, przez co unikamy

instrukcji

switch

Podstawy programowania

174

realizacji sáu* w C++ poznane specyfikatory

private

oraz

public

. W miar nabywania

dowiadczenia w pracy z klasami bdziesz je coraz efektywniej stosowaá w swoim
wáasnym kodzie.

Deklaracje pól

Pola s wáaciw treci ka*dego obiektu klasy, to one stanowi jego reprezentacj w
pamici operacyjnej. Pod tym wzgldem nie ró*ni si niczym od znanych ci ju* pól w
strukturach i s po prostu zwykáymi zmiennymi, zgrupowanymi w jedn, kompleksow
caáoü.

Jako miejsce na przechowywanie wszelkiego rodzaju danych, pola maj kluczowe
znaczenie dla obiektów i dlatego powinny byü chronione przez niepowoáanym dostpem z
zewntrz. Przyjáo si wic, *e w zasadzie wszystkie pola w klasach deklaruje si jako
prywatne; ich nazwy zwykle poprzedza si te* przedrostkiem m_, aby odró*niü je od
zmiennych lokalnych:

class

CFoo

{

private

int

m_nJakasLiczba;

std::string

m_strJakisNapis;

Dostp do danych zawartych w polach musi si zatem odbywaü za pomoc
dedykowanych metod. Rozwizanie to ma wiele rozlicznych zalet: pozwala chocia*by na
tworzenie pól, które mo*na jedynie odczytywaü, daje sposobnoü wykrywania
niedozwolonych wartoci (np. indeksów przekraczajcych rozmiary tablic itp.) czy te*
podejmowania dodatkowych akcji podczas operacji przypisywania.
Rzeczone funkcje mog wygldaü chocia*by tak:

public

int

JakasLiczba()

{

return

m_nJakasLiczba;

}

void

JakasLiczba(

int

nLiczba) { m_nJakasLiczba = nLiczba; }

std::string

JakisNapis()

{

return

m_strJakisNapis;

}

};

Nazwaáem je tu identycznie jak odpowiadajce im pola, pomijajc jedynie przedrostki

Niektórzy stosuj nazwy w rodzaju Pobierz...()/Ustaw...() czy te* z angielskiego -
Get...()/Set...(). Le*y to caákowicie w zakresie upodoba programisty.
U*ycie naszych metod „dostpowych” mo*e za przedstawiaü si na przykáad tak:

CFoo Foo;
Foo.JakasLiczba (

);

// przypisanie 10 do pola m_nJakasLiczba

std::cout << Foo.JakisNapis();

// wywietlenie pola m_strJakisNapis

Zauwa*my przy okazji, *e pole m_strJakisNapis mo*e byü tutaj jedynie odczytane, gdy*
nie przewidzielimy metody do nadania mu jakiej wartoci. Takie postpowanie jest
czsto po*dane, ale zale*y rzecz jasna od konkretnej sytuacji, a tu jest jedynie
przykáadem.

Wielkim mankamentem C++ jest brak wsparcia dla tzw. wáaciwoci (ang. properties),

czyli „nakáadek” na pola klas, imitujcych zmienne i pozwalajcych na u*ycie bardziej

foo oraz bar to takie dziwne nazwy, stosowane przez programistów najczciej w przykáadowych kodach, dla

bli*ej nieokrelonych bytów, nie majcych *adnego praktycznego sensu i sáu*cych jedynie w celach
prezentacyjnych. Maj one t zalet, *e nie mo*na ich pomyliü tak áatwo, jak np. litery A, B, C, D itp.

Sprawia to, *e funkcje odpowiadajce temu samemu polu, a sáu*ce do zapisu i odczytu, s przeci*one.

Obiekty

175

naturalnej skáadni (choüby operatora =) ni* dedykowane metody.

Wiele kompilatorów udostpnia wic tego rodzaju funkcjonalnoü we wáasnym zakresie -

w Visual C++ jest to konstrukcja

__declspec

(

property

(...)), o której mo*esz

przeczytaü w

MSDN

. Nie dorównuje ona jednak podobnym mechanizmom znanym z

Delphi.

Metody i ich prototypy

Metody czyni klasy. To dziki swym funkcjom skáadowym pasywne zbiory danych,
którymi s struktury, staj si aktywnymi obiektami.

Z praktycznego punktu widzenia metody niewiele ró*ni si od zwyczajnych funkcji -
oczywicie poza faktem, i* s deklarowane zawsze wewntrz jakiej klasy:

class

CFoo

{

public

void

Metoda();

int

InnaMetoda(

int

);

itp.

};

Deklaracje te mog mieü form prototypów funkcji, a stworzone w ten sposób metody
wymagaü jeszcze implementacji, czyli wpisania ich kodu. Czynnoci t zajmiemy si
dokáadnie w nastpnym paragrafie.
Warto jednak wiedzieü, *e dopuszczalne jest tak*e wprowadzanie kodu metod
bezporednio wewntrz bloku

class

. Robilimy tak zreszt w przypadku metod

dostpowych do pól, a w podobnych sytuacjach rozwizanie to sprawdza si bardzo
dobrze. Nie nale*y aczkolwiek postpowaü w ten sposób z dáugimi metodami,
zawierajcymi skomplikowane algorytmy, gdy* mo*e to spowodowaü znaczcy wzrost
rozmiaru wynikowego pliku EXE.

Kompilator traktuje bowiem takie funkcje jako inline, tzn. rozwijane w miejscu

wywoáania, i wstawia caáy ich kod przy ka*dym odwoáaniu si do nich. Dla krótkich,

jednolinijkowych metod jest to dobre rozwizanie, przyspieszajce dziaáanie programu.

Dla dáu*szych nie musi wcale takie byü.

Dokáadniejszych informacji na

ten temat

oraz o samych

funkcjach inline

tradycyjnie

mo*na znale(ü w MSDN.

To jeszcze nie koniec zabawy z metodami :) Niektóre z nich mo*na mianowicie uczyniü
staáymi. Zabieg ten sprawia, *e funkcja, na której go zaaplikujemy, nie mo*e
modyfikowaü *adnego z pól klasy

, a tylko je co najwy*ej odczytywaü.

Po co komu takie udziwnienie? Teoretycznie jest to pewna wskazówka dla kompilatora,
który byü mo*e uczyni nam w zamian áask poczynienia jakich optymalizacji.
Praktycznie jest to te* pewien sposób na zabezpieczenie si przed omyákowym
zmodyfikowaniem obiektu w metodzie, która wcale nie miaáa czego takiego robiü.
Jednym sáowem korzyci s piorunujce ;)
Uczynienie jakiej metody staá jest banalnie proste: wystarczy tylko dodaü za list jej
parametrów magiczne sáówko

const

, np.:

class

CFoo

{

private

No mo*e nie caákiem *adnego; istnieje pewien drobny wyjtek od tej reguáy, ale jest on na tyle drobny i na

tyle sproadycznie stosowany, *e nie wyjaniam go bli*ej i odsyáam tylko purystów do stosownego wyjanienia w

MSDN

Podstawy programowania

176

int

m_nPole;

public

int

Pole()

const

{

return

m_nPole; }

};

Funkcja Pole() (bdca de facto obudow dla zmiennej m_nPole) bdzie tutaj sáusznie
metod staá.

Dla szczególnie zainteresowanych polecam

lektur uzupeániajc

o staáych metodach,

znajdujc si w miejscu wiadomym :)

Konstruktory i destruktory

Przebkiwaáem ju* parokrotnie o procesie tworzenia obiektów, podkrelaj przy tym
znaczenie tego procesu. Za chwil wyjani si, dlatego jest to takie wa*ne…

Decydujc si na zastosowanie technik obiektowych w konkretnym programie musimy
mieü na uwadze fakt, i* oznacza to zdefiniowane przynajmniej kilku klas oraz instancji
tych*e. Istot OOPu jest poza tym odpowiednia komunikacja midzy obiektami:
wymiana danych, komunikatów, podejmowanie dziaáa zmierzajcych do realizacji
danego zdania, itp. Aby zapewniü odpowiedni przepáyw informacji, krystalizuje si mniej
lub bardziej rozbudowana hierarchia obiektów, kiedy to jeden obiekt zawiera w sobie
drugi, czyli jest jego wáacicielem. To doü naturalne: wikszoü otaczajcych nas
rzeczy mo*na przecie* rozáo*yü na czci, z których si skáadaj (gorzej mo*e byü z
powtórnym záo*eniem ich w caáoü :D).
Konsekwencje tego stanu rzeczy dla procesu tworzenie (i niszczenia) obiektów s raczej
oczywiste: kreacja obiektu zbiorczego musi pocignü za sob stworzenie jego
skáadników; podobnie jest te* z jego destrukcj. Jasne, mo*na te kwestie zostawiü
kompilatorowi, ale paradoksalnie czyni to kod trudniejszym do zrozumienia, pisania i
konserwacji

C++ oferuje nam na szczcie mo*liwoü podjcia odpowiednich dziaáa zarówno
podczas tworzenia obiektu, jak i jego niszczenia. Korzystamy z niej, wprowadzajc do
naszej klasy dwa specjalne rodzaje metod - s to tytuáowe konstruktory oraz
destruktory.

Konstruktor to specyficzna funkcja skáadowa klasy, wywoáywana zawsze podczas
tworzenia nale*cego do obiektu.

Typowym zadaniem konstruktora jest zainicjowanie pól ich pocztkowymi wartociami,
przydzielenie pamici wykorzystywanej przez obiekt czy te* uzyskanie jakich kluczowych
danych z zewntrz.
Deklaracja konstruktora jest w C++ bardzo prosta. Metoda ta nie zwraca bowiem *adnej
wartoci (nawet

void

!), a jej nazwa odpowiada nazwie zawierajcej j klasy. Wyglda

wic mniej wicej tak:

class

CFoo

{

private

jakie przykáadowe pole...

float

m_fPewnePole;

public

// no i przyszáa pora na konstruktora ;-)

CFoo()

{ m_fPewnePole =

0.0

; }

Wbrew pozorom to racjonalna reguáa: im wicej jest rzeczy, które kompilator robi „za plecami” programisty,

tym bardziej zagmatwany jest kod - choüby nawet byá krótszy.

Obiekty

177

};

Zazwyczaj te* konstruktor nie przyjmuje *adnych parametrów, co nie znaczy jednak, *e
nie mo*e tego czyniü. Czsto s to na przykáad startowe dane przypisywane do pól:

class

CSomeObject

{

private

jaki rodzaj wspóárzdnych

float

m_fX, m_fY;

public

konstruktory

CSomeObject()

{

m_fX

m_fY

0.0

; }

CSomeObject(

float

fX,

float

fY)

{ m_fX = fX; m_fY = fY; }

};

Posiadanie takiego parametryzowanego konstruktora ma pewien wpáyw na sposób
tworzenia obiektów, gdy* musimy wtedy podaü dla odpowiednie wartoci. Dokáadniej
wyjanimy to w nastpnym paragrafie.
Warto te* wiedzieü, *e klasa mo*e posiadaü kilka konstruktorów - tak jak na powy*szym
przykáadzie. Dziaáaj one wtedy podobnie jak funkcje przeci*ane; decyzja, który z nich
faktycznie zostanie wywoáany, zale*y wic od instrukcji tworzcej obiekt.

Z wiadomych wzgldów konstruktory czynimy zawsze metodami publicznymi.

Umieszczenie ich w sekcji

private

daáoby bowiem doü dziwny efekt: taka klasa nie

mogáaby byü normalnie instancjowana, tzn. niemo*liwe byáoby utworzenie z niej obiektu

w zwykáy sposób.

OK, konstruktory maj zatem niebagateln rol, jak jest powoáywania do *ycia nowych
obiektów. Doskonale jednak wiemy, *e nic nie jest wieczne i nawet najdáu*ej dziaáajcy
program kiedy bdzie musiaá byü zakoczony, a jego obiekty zniszczone. T niechlubn
robot zajmuje si kolejny, wyspecjalizawany rodzaj metod - destruktory.

Destruktor jest specjaln metod, przywoáywan podczas niszczenia obiektu
zawierajcej j klasy.

W naszych przykáadowych klasach destruktor nie miaáby wiele do zrobienia - zgoáa nic,
poniewa* *aden z prezentowanych obiektów nie wykonywaá czynnoci, po których
nale*aáoby sprztaü. To si wszak niedáugo zmieni, zatem poznanie destruktorów z
pewnoci nie bdzie szkodliwe :)
Postaü destruktora jest tak*e niezwykle prosta i w dodatku zawsze identyczna. Funkcja ta
nie bierze bowiem *adnych parametrów (bo i jakie miaáaby braü?) i niczego nie zwraca.
Jej nazw jest za nazwa zawierajcej klasy poprzedzona znakiem tyldy (~).

Nazewnictwo destruktorów to jedna z niewielu rzeczy, za które twórcom C++ nale* si
tgie baty :D O co dokáadnie chodzi?
Otóz teoretycznie znak tyldy uzyskujemy za pomoc klawisza Shift oraz tego
znajdujcego si w lewym górnym rogu alfanumerycznej czci klawiatury. Problem
polega na tym, *e po pierwszym jego u*yciu *dany znak nie pojawia si na ekranie.
Dzieje si tak dlatego, i* dawniej za jego pomoc uzyskiwaáo si litery specyficzne dla
pewnych jzyków, z kreseczkami - np. , é czy ó.
Fakt ten mo*naby zignorowaü, jako *e wikszoü liter nie posiada swoich
„kreseczkowych” odpowiedników, wic wcinicie ich klawiszy po znaku tyldy powoduje
pojawienie si zarówno osáawionego szlaczka, jak i samej litery. Do tej grupy nie nale*y
jednak litera C, któr to przyjáo si pisaü na pocztku nazw klas. Zamiast wic *danej
sekwencji ~C uzyskujemy… û!
Jak sobie z tym radziü? Ja nawykáem do dwukrotnego przyciskania klawisza tyldy, a

Podstawy programowania

178

nastpnie usuwania nadmiarowego znaku. Mo*liwe jest te* u*ycie jakiej „neutralnej”
litery w miejsce C, a nastpnie skasowanie jej. Chyba najlepsze jest jednak wciskanie
klawisza tyldy, a nastpnie spacji - wprawdzie to dwa przycinicia, ale w ich wyniku
otrzymujemy sam w*yk.

Klasa wyposa*ona w odpowiedni destruktor mo*e zatem jawiü si nastpujco:

class

CBar

{

public

// konstruktor i destruktor

CBar()

{

/* czynnoci startowe */

}

// konstruktor

~CBar()

{

/* czynnoci koczce */

}

// destruktor

};

Jako *e jego forma jest cile okrelona, jedna klasa mo*e posiadaü tylko jeden
destruktor.

Co jeszcze?

Pola, zwykáe metody oraz konstruktory i destruktory to zdecydowanie najczciej
spotykane i chyba najwa*niejsze elementy klas. Aczkolwiek nie jedyne; w dalszej czci
tego kursu poznamy jeszcze skáadowe statyczne, funkcje przeci*ajce operatory oraz
tzw. deklaracje przyja(ni (naprawd jest co takiego! :D). Poznane tutaj skáadniki klasy
bd jednak zawsze miaáy najwiksze znaczenie.

Mo*na jeszcze wspomnieü, *e wewntrz klasy (a tak*e struktury i unii) mo*emy

zdefiniowaü… kolejn klas! Tak definicj nazywamy wtedy zagnie*d*on. Technika ta

nie jest stosowana zbyt czsto, wic zainteresowani poczytaj o niej w

MSDN

Podobnie zreszt jest z innymi typami, okrelanymi poprzez

enum

czy

typedef

Implementacja metod

Definicja klasy jest zazwyczaj tylko poáow sukcesu i nie stanowie wcale koca jej
okrelania. Dzieje si tak przynajmniej wtedy, gdy umiecimy w niej jakie prototypy
metod, bez podawania ich kodu.

Uzupeánieniem definicji klasy jest wówczas jej implementacja, a dokáadniej owych
prototypowanych funkcji skáadowych. Polega ona rzecz jasna na wprowadzeniu instrukcji
skáadajcych si na kod tych*e metod w jednym z moduáów programu.
Operacj t rozpoczynamy od doáczenia do rzeczonego moduáu pliku nagáówkowego z
definicj naszej klasy, np.:

#include

"klasa.h"

Potem mo*emy ju* zajü si ka*d z niezaimplementowanych metod; postpujemy tutaj
bardzo podobnie, jak w przypadku zwykáych, globalnych funkcji. Skáadnia metody
wyglda bowiem nastpujco:

[typ_wartoci/

void

]

nazwa_klasy::nazwa_metody([parametry]) [

const

]

{

instrukcje

}

Nowym elementem jest w niej nazwa_klasy, do której nale*y dana funkcja. Wpisanie jej
jest konieczne: po pierwsze mówi ona kompilatorowi, *e ma do czynienia z metod klasy,
a nie zwyczajn funkcj; po drugie za pozwala bezbádnie zidentyfikowaü macierzyst
klas danej metody.

Obiekty

179

Midzy nazw klasy a nazw metody widoczny jest operator zasigu ::, z którym ju* raz
mielimy przyjemnoü si spotkaü. Teraz mo*emy ogldaü go w nowej, chocia* zbli*onej
roli.

Zaleca si, aby bloki metod tyczce si jednej klasy umieszczaü w zwartej grupie, jeden
pod drugim. Czyni to kod lepiej zorganizowanym.

Dwie jeszcze nowoci mo*na zauwa*yü w nagáówku metody. Zaznaczyáem mianowicie
typ_zwracanej_wartoci lub

void

jako jego nieobowizkow czü. Faktycznie mo*e

ona byü zbdna - ale tylko w przypadku konstruktora tudzie* destruktora klasy. Dla
zwykáych funkcji skáadowych musi ona nadal wystpowaü.
Ostatni ró*nic jest ewentualny modyfikator

const

, który, jak pamitamy, czyni metod

staá. Jego obecnoü w tym miejscu powinna si pokrywaü z wystpowaniem tak*e w
prototypie funkcji. Niezgodnoü w tej kwestii zostanie srodze ukarana przez kompilator :)

Oczywicie wikszoci implementacji metody bdzie blok jej instrukcji, tradycyjnie
zawarty midzy nawiasami klamrowymi. Có* ciekawego mo*na o nim powiedzieü?
Bynajmniej niewiele: nie ró*ni si prawie wcale od analogicznych bloków globalnych
funkcji. Dodatkowo jednak ma on dostp do wszystkich pól i metod swojej klasy - tak,
jakby byáy one jego zmiennymi albo funkcjami lokalnymi.

Wska(nik

this

Z poziomu metody mamy dostp do jeszcze jednej, bardzo wa*nej i przydatnej
informacji. Chodzi tutaj o obiekt, na rzecz którego nasza metoda jest wywoáywana;
mówic cile, o odwoáanie (wska(nik) do niego.
Có* to znaczy?… Przypomnijmy sobie zatem któr z przykáadowych klas,
prezentowanych na poprzednich stronach. Gdybymy wywoáali jak jej metod,
przypuümy *e w ten sposób:

CFoo Foo;
Foo.JakasMetoda();

to wewntrz bloku funkcji CFoo::JakasMetoda() moglibymy u*yü omawianego
wska(nika, by zyskaü peáen wgld w obiekt Foo! Czasem mówi si wic, i* jest to
dodatkowy, specjalny parametr metody - wystpuje przecie* w jej wywoáaniu.

Ów wyjtkowy wska(nik, o którym traktuje powy*szy opis, nazywa si

this

(„to”).

U*ywamy go zawsze wtedy, gdy potrzebujemy odwoáaü si do obiektu jako caáoci, a nie
tylko do poszczególnych pól. Najczciej oznacza to przekazanie go do jakiej funkcji,
zwykle konstruktora innego obiektu.
Jako *e jest to wska(nik, a nie obiekt explicité, korzystanie z niego ró*ni si nieco od
postpowania z „normalnymi” zmiennymi obiektowymi. Wicej na ten temat powiemy
sobie w dalszej czci tego rozdziaáu, za caákowicie wyjanimy w rozdziale 8, Wska(niki.

Dla dociekliwych zawsze jednak istnieje

MSDN

Praca z obiektami

Nawet dziesitki wymienitych klas nie stanowi jeszcze gotowego programu, a jedynie
pewien rodzaj reguá, wedle których bdzie on realizowany. Wprowadzenie tych reguá w
*

ycie wymaga przeto stworzenia obiektów na podstawie zdefiniowanych klas.

W C++ mamy dwa gáówne sposoby „obchodzenia” si z obiektami; ró*ni si one pod
wieloma wzgldami, inne jest te* zastosowanie ka*dego z nich. Naturaln i rozsdn
kolej rzeczy bdzie wic przyjrzenie si im obu :)

Podstawy programowania

180

Zmienne obiektowe

Pierwsz strategi znamy ju* bardzo dobrze, u*ywalimy jej bowiem niejednokrotnie nie
tylko dla samych obiektów, lecz tak*e dla wszystkich innych zmiennych.
W tym trybie korzystamy z klasy dokáadnie tak samo, jak ze wszystkich innych typów w
C++ - czy to wbudowanych, czy te* definiowanych przez nas samych (jak

enum

’y,

struktury itd.).

Deklarowanie zmiennych i tworzenie obiektów

Zaczynamy oczywicie od deklaracji zmiennej, niebdcej dla nas *adn niespodziank:

CFoo Obiekt;

Powy*sza linijka kodu wykonuje jednak znacznie wicej czynnoci, ni* jest to widoczne
na pierwszy czy nawet drugi rzut oka. Ona mianowicie:

wprowadza nam now zmienn Obiekt typu CFoo. Nie jest to rzecz jasna *adna
nowoü, ale dla porzdku warto o tym przypomnieü.

tworzy w pamici operacyjnej obszar, w którym bd przechowywane pola
obiektu. To tak*e nie jest zaskoczeniem: pola, jako bd( co bd( zmienne,
musz rezydowaü gdzie w pamici, wic robi to w identyczny sposób jak pola
struktur.

wywoáuje konstruktor klasy CFoo (czyli procedur CFoo::CFoo()), by dokoczyá
aktu kreacji obiektu. Po jego zakoczeniu mo*emy uznaü nasz obiekt za
ostatecznie stworzony i gotowy do u*ycia.

Te trzy etapy s niezbdne, abymy mogli bez problemu korzystaü z stworzonego
obiektu. W tym przypadku s one jednak realizowane caákowicie automatycznie i nie
wymagaj od nas *adnej uwagi. Przekonamy si pó(niej, *e nie zawsze tak jest i, co
ciekawe, wcale nie bdziemy tym zmartwieni :D

Musz jeszcze wspomnieü o pewnym drobnym wymaganiu, stawianym nam przez
kompilator, któremu chcemy podaü wiersz kodu umieszczony na pocztku paragrafu.
Otó* klasa CFoo musi tutaj posiadaü bezparametrowy konstruktor, albo te* nie mieü
wcale procedury tego rodzaju (wtedy etap z jej wywoáywaniem zostanie po prostu
pominity).
W innym przypadku potrzebne jest jeszcze przekazanie odpowiednich parametrów
konstruktorowi, który takowych wymaga. Koniecznoü t realizujemy podobn metod,
co wywoáanie zwyczajnej funkcji:

CFoo Foo(

"jaki tekst"

);

// itp.

Czy nie przypomina nam to czego?… Ale* oczywicie - identycznie postpowalimy z
á

acuchami znaków (czyli obiektami klasy std::string), tworzc je chocia*by tak:

#include

std::string strBuffer(

"Jakie te obiekty s proste! ;-)"

);

Widzimy wic, *e znany nam i lubiany typ std::string wyjtkowo podpada pod zasady
programowania obiektowego :)

)

onglerka obiektami

Zadeklarowane przed chwil zmienne obiektowe s w istocie takimi samymi zmiennymi,
jak wszystkie inne w programach C++. Mo*liwe jest zatem przeprowadzanie na
operacji, którym podlegaj na przykáad liczby caákowite, napisy czy tablice.

Obiekty

181

Nie mam tu wcale na myli jakich záo*onych manipulacji, wymagajcych
skomplikowanych algorytmów, lecz caákiem zwyczajnych i codziennych, jak przypisanie
czy przekazywanie do funkcji.
Czy mo*na powiedzieü cokolwiek ciekawego o tak trywialnych czynnociach? Okazuje si,
*

e tak. Zwrócimy wprawdzie uwag na doü oczywiste fakty z nimi zwizane, lecz

znajomoü owych „banaáów” oka*e si pó(niej niezwykle przydatna. Przy okazji bdzie to
dobra okazja to powtórzenia nabytej wiedzy, a tego przecie* nigdy doü :D

Na u*ytek dalszych wyjanie zdefiniujemy sobie tak oto klas lampy:

class

CLamp

{

private

COLOR

m_Kolor;

// kolor lampy

bool

m_bWlaczona;

// czy lampa wieci si?

public

konstruktory

CLamp()

{ m_Kolor = COLOR_WHITE; }

CLamp(COLOR Kolor)

{ m_Kolor = Kolor; }

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

metody

void

Wlacz()

{ m_bWlaczona =

true

; }

void

Wylacz()

{ m_bWlaczona =

false

; }

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

// metody dostpowe do pól

COLOR

Kolor()

const

{

return

m_Kolor; }

bool

Wlaczona()

const

{

return

m_bWlaczona; }

};

Klasa ta jest znakomit syntez wszystkich wiadomoci przekazanych w tym
podrozdziale. Je*eli wic nie rozumiesz do koca znaczenia którego z jej elementów,
powiniene powróciü do powiconemu mu miejsca w tekcie.

Natychmiast te* zadeklarujemy i stworzymy dwa obiekty nale*ce do naszej klasy:

CLamp Lampa1(COLOR_RED), Lampa2(COLOR_GREEN);

Tym sposobem mamy wic lampy, sztuk dwie, w kolorze czerwonym oraz zielonym.
Moglibymy u*yü ich metod, aby je obie wáczyü; zrobimy jednak co dziwniejszego -
przypiszemy jedn lamp do drugiej:

Lampa1 = Lampa2;

„A co to za dziwadáo?”, sáusznie pomylisz. Taka operacja jest jednak caákowicie
poprawna i daje doü ciekawe rezultaty. By j dobrze zrozumieü musimy pamitaü, *e
Lampa1 oraz Lampa2 s to przede wszystkim zmienne, zmienne które przechowuj
pewne wartoci. Fakt, *e tymi wartociami s obiekty, które w dodatku interpretujemy
w sposób prawie realny, nie ma tutaj wikszego znaczenia.
Pomylmy zatem, jaki efekt spowodowaáby ten kod, gdybymy zamiast klasy CLamp u*yli
jakiego zwykáego, skalaranego typu?…

int

nLiczba1 =

, nLiczba2 =

;

nLiczba1 = nLiczba2;

Podstawy programowania

182

Dawna wartoü zmiennej, do której nastpiáo przypisanie, zostaáaby zapomniana i obie
zmienne zawieraáyby t sam liczb.
Dla obiektów rzecz ma si identycznie: po wykonaniu przypisania zarówno Lampa1, jak i
Lampa2 reprezentowaü bd obiekty zielonych lamp. Czerwona lampa, pierwotnie zawarta
w zmiennej Lampa1, zostanie zniszczona

, a w jej miejsce pojawi si kopia zawartoci

zmiennej Lampa2.

Nie bez powodu zaakcentowaáem wy*ej sáowo „kopia”. Obydwa obiekty s bowiem od
siebie caákowicie niezale*ne. Je*eli wáczylibymy jeden z nich:

Lampa1.Wlacz();

drugi nie zmieniáby si wcale i nie obdarzyá nas swym wáasnym wiatáem.

Mo*emy wic podsumowaü nasz wywód krótk uwag na temat zmiennych obiektowych:

Zmienne obiektowe przechowuje obiekty w ten sam sposób, w jaki czyni to zwykáe
zmienne ze swoimi wartociami. Identycznie odbywa si te* przypisywanie

takich

zmiennych - tworzone s wtedy odpowiednie kopie obiektów.

Wspominaáem, *e wszystko to mo*e wydawaü si naturalne, oczywiste i niepodwa*alne.
Konieczne byáo jednak dokáadne wyjanienie w tym miejscu tych z pozoru prostych
zjawisk, gdy* drugi sposób postpowania z obiektami (który poznamy za moment)
wprowadza w tej materii istotne zmiany.

Dostp do skáadników

Kontrolowanie obiektu jako caáoci ma rozliczne zastosowania, ale jednak znacznie
czciej bdziemy u*ywaü tylko jego pojedynczych skáadników, czyli pól lub metod.

Doskonale wiemy ju*, jak si to robi: z pomoc przychodzi nam zawsze operator
wyáuskania - kropka (.). Stawiamy wic go po nazwie obiektu, by potem wpisaü nazw
wybranego elementu, do którego chcemy si odwoáaü.

Pamitajmy, *e posiadamy wtedy dostp jedynie do skáadowych publicznych klasy, do
której nale*y obiekt.

Dalsze postpowanie zale*y ju* od tego, czy nasz uwag zwrócilimy na pole, czy na
metod. W tym pierwszym, rzadszym przypadku nie odczujemy *adnej ró*nicy w
stosunku do pól w strukturach - i nic dziwnego, gdy* nie ma tu rzeczywicie najmniejszej
rozbie*noci :) Wywoáanie metody jest natomiast áudzco zbli*one do uruchomienia
zwyczajnej funkcji - tyle *e w gr wchodz tutaj nie tylko jej parametry, ale tak*e obiekt,
na rzecz którego dan metod wywoáujemy.

Jak wiemy, jest on potem dostpny wewntrz metody poprzez wska(nik

this

Niszczenie obiektów

Ka*dy stworzony obiekt musi prdzej czy po(niej zostaü zniszczony, aby móc odzyskaü
zajmowan przez niego pamiü i spokojnie zakoczyü program. Dotyczy to tak*e
zmiennych obiektowych, lecz dzieje si to troch jakby za plecami programisty.

W peánym znaczeniu tego sáowa - z wywoáaniem destruktora i pó(niejszym zwolnieniem pamici.

To samo mo*na zreszt powiedzieü o wszystkich operacjach podobnych do przypisania, tj. inicjalizacji oraz

przekazywaniu do funkcji.

Obiekty

183

Zauwa*my bowiem, i* w *adnym z naszych dotychczasowych programów,
wykorzystujcych techniki obiektowe, nie pojawiáy si instrukcje, które jawnie
odpowiadaáyby za niszczenie stworzonych obiektów. Nie oznacza to bynajmniej, *e
zalegaj one w pamici operacyjnej

, zajmujc j niepotrzebnie. Po prostu kompilator

sam dba o to, by ich destrukcja nastpiáa w stosownej chwili.

A zatem kiedy jest ona faktycznie dokonywana? Nietrudno jest obmyliü odpowied( na to
pytanie, je*eli przypomnimy sobie pojcie zasigu zmiennej. Powiedzielimy sobie ongi,
i* jest to taki obszar kodu programu, w którym dana zmienna jest dostpna. Dostpna -
to znaczy zadeklarowana, z przydzielon dla siebie pamici, a w przypadku zmiennej
obiektowej - posiadajca równie* obiekt stworzony poprzez konstruktor klasy.
Moment opuszczenia zasigu zmiennej przez punkt wykonania programu jest wic
kresem jej istnienia. Jeli nieszczsna zmienna byáa obiektow, do akcji wkracza
destruktor klasy (je*eli zostaá okrelony), sprztajc ewentualny baáagan po obiekcie i
niszczc go. Dalej nastpuje ju* tylko zwolnienie pamici zajmowanej przez zmienn i
jej kariera koczy si w niebycie :)

Zapamitajmy wic, *e:

Wyjcie programu poza zasig zmiennej obiektowej niszczy zawarty w niej obiekt.

Podsumowanie

Prezentowane tu wáasnoci zmiennych obiektowych byü mo*e wygldaj na nieznane i
niespotkane wczeniej. Naprawd jednak nie s niczym szczególnym, gdy* spotykalimy
si z nimi od samego pocztku nauki programowania - w wikszoci (z wyáczeniem
wyáuskiwania skáadników) dotycz one bowiem wszystkich zmiennych!
Teraz wszak*e omówilimy je sobie nieco dokáadniej, koncentrujc si przede wszystkim
na „*yciu” obiektów - chwilach ich tworzenia i niszczenia oraz operacjach na nich. Majc
ugruntowan t widz, bdzie nam áatwiej zmierzyü si z drugim sposobem stosowania
obiektów, który jest przedstawiony w nastpnym paragrafie.

Wska(niki na obiekty

Przyznam szczerze: miaáem pewne wtpliwoci, czy sáuszne jest zajmowanie si
wska(nikami na obiekty ju* w tej chwili, bez dogáebnego przedstawienia samych
wska(ników. T naruszon przeze mnie kolejnoü zachowaáaby pewnie wikszoü
autorów kursów czy ksi*ek o C++.
Ja jednak postawiáem sobie za cel nauczenie czytelnika programowania w jzyku C++ (i
to w konkretnym celu!), nie za samego jzyka C++. Narzuca to nieco inny porzdek
treci, skoncentrowany w pierwszej kolejnoci na najpotrzebniejszych zagadnieniach
praktycznych, a dopiero potem na pozostaáych mo*liwociach jzyka. Do tych „kwestii
pierwszej potrzeby” niewtpliwie nale*y zaliczyü ide programowania obiektowego,
wska(niki spychajc tym samym na nieco dalszy plan.
Jednoczenie jednak nie mog przy okazji OOPu pominü milczeniem tematu wska(ników
na obiekty, które s praktycznie niezbdne do poprawnego konstruowania aplikacji z
wykorzystaniem klas. Dlatego te* pojawia si on wáanie teraz; mimo wszystko ufam, *e
zrozumienie go nie bdzie dla ciebie wielkim káopotem.

Po tak „zachcajcym” wstpie nie bd zdziwiony, je*eli w tej chwili du*a czü
czytelników zakoczy lektur ;-) Skrycie wierz jednak, *e ambitnym kandydatom na
programistów gier *adne wska(niki nie bd straszne, a ju* na pewno nie przelkn si
ich obiektowych odmian. Nie bedziemy zatem traciü wicej czasu oraz miejsca i
natychmiast przystpimy do dzieáa.

Zjawisko to nazywamy wyciekiem pamici i jest ono wysoce niepo*dane, za interesowaü nas bdzie

bardziej w rozdziale traktujcym o wska(nikach.

Podstawy programowania

184

Deklarowanie wska(ników i tworzenie obiektów

Od czegó* to mielibymy zaczü, je*eli nie od jakiej zmiennej? W kocu bez zmiennych
nie ma obiektów, a bez obiektów nie ma programowania (obiektowego :D). Zadeklarujmy
wic na pocztek tak oto dziwn zmienn:

CFoo* pFoo;

Wszystko byáoby tu znajome, gdyby nie ta gwiazdka przy nazwie klasy CFoo. To wáanie
ona sprawia, *e pFoo nie jest zmienn obiektow, ale wáanie wska(nikiem na obiekt,
w tym przypadku obiekt klasy CFoo.

To wa*ne stwierdzenie - pFoo nie jest tutaj obiektem, on mo*e co najwy*ej na taki obiekt
wskazywaü. Innymi sáowy, mo*e byü jedynie odwoáaniem do obiektu, poáczeniem z
nim - ale zmienna ta nie bdzie nigdy sama przechowywaü *adnych danych, nale*cych
do owego obiektu. Bdzie raczej czym w rodzaju pozycji w spisie treci, odnoszcej si
do rozdziaáu w ksi*ce.
Niniejsza linijka kodu nie tworzy wic *adnego obiektu, a jedynie przygotowuje na
miejsce w programie. Wáaciwa kreacja musi nastpiü pó(niej i wyglda nieco inaczej ni*
to, do czego przywyklimy:

pFoo =

new

CFoo;

Sáówko

new

(„nowy”, niektórzy ka* je zwaü operatorem) sáu*y wáanie do utworzenia

obiektu. Wykonuje ono prawie wszystkie czynnoci potrzebne do realizacji tego procesu,
a wic przydziela odpowiedni iloü pamici dla naszego obiektu i wywoáuje konstruktor
jego klasy.
Czym zatem zasáuguje sobie na odrbnoü? Podstawow ró*nic jest to, *e tworzony
obiekt jest umieszczany w dowolnym miejscu pamici, a nie w której z naszych
zmiennych (a ju* na pewno nie w pFoo!). Nie oznacza to jednak*e, i* nie mamy o nim
*

adnych informacji i nie mo*emy z niego normalnie korzystaü. Otó* pFoo staje si tutaj

cznikiem z naszym odlegáym tworem; za porednictwem tego wska(nika mamy

bowiem peán swobod dostpu do stworzonego obiektu. Jak si wkrótce przekonasz,
mo*liwe jest przy jego pomocy odwoáywanie si do skáadników obiektu (pól i metod) w
niemal taki sam sposób, jak w przypadku zmiennych obiektowych.

Schemat 18. Wska(nik na obiekt jest pewnego rodzaju kluczem do niego

Jeden dla wszystkich, wszystkie do jednego

Ogromne i wa*ne ró*nice ujawniaj si dopiero podczas manipulowania kilkoma takimi
wska(nikami. Mam tu na myli przede wszystkim instrukcje przypisania, rozwa*ane ju*
dokáadnie dla zmiennych obiektowych. Teraz podobne eksperymenta bdziemy
dokonywali na wska(nikach; zobaczymy, dokd nas one zaprowadz…

Do naszych celów po raz kolejny spo*ytkujemy zdefiniowan w poprzednim paragrafie
klas CLamp. Zaczniemy jednak od zadeklarowania wska(nika na obiekt tej klasy z
jednoczesnym stworzeniem obiektu lampy:

Obiekty

185

CLamp* pLampa1 =

new

CLamp;

Przypominam, i* w ten sposób powoáalimy do *ycia obiekt, który zostaá umieszczony
gdzie w pamici, a wska(nik pLampa1 jest tylko odwoáaniem do niego.
Dalszej czci nietrudno si domyleü. Wprowadzamy sobie zatem drugi wska(nik i
przypisujemy do ten pierwszy, o tak:

CLamp* pLampa2 = pLampa1;

Mamy teraz dwa takie same wska(niki… Czy to znaczy, i* posiadamy tak*e par
identycznych obiektów?

Otó* nie! Nasza lampa nadal egzystuje samotnie, bowiem skopiowalimy jedynie samo
odwoáanie do niej. Obecnie u*ycie zarówno wska(nika pLampa1, jak i pLampa2 bdzie
uzyskaniem dostpu do jednego i tego samego obiektu.
To znaczca modyfikacja w stosunku do zmiennych obiektowych. Tam ka*da
reprezentowaáa i przechowywaáa swój wáasny obiekt, a instrukcje przypisywania midzy
nimi powodowaáy wykonywanie kopii owych obiektów.
Tutaj natomiast mamy tylko jeden obiekt, za to wiele dróg dostpu do niego, czyli
wska(ników. Przypisywanie midzy nimi dubluje jedynie te drogi, za sam obiekt
pozostaje niewzruszony.

Podsumowujc:

Wska(nik na obiekt jest jedynie odwoáaniem do niego. Wykonanie przypisania do
wska(nika mo*e wic co najwy*ej skopiowaü owo odwoáanie, pozostawiajc docelowy
obiekt caákowicie niezmienionym.

Mówic obrazowo, uzyskiwanie dodatkowego wska(nika do obiektu jest jak wyrobienie
sobie dodatkowego klucza do tego samego zamka. Choübymy mieli ich caáy brelok,
wszystkie bd otwieraáy tylko jedne i te same drzwi.

Schemat 19. Mo*emy mieü wiele wska(ników do tego samego obiektu

Dostp do skáadników

Caáy czas napomykam, *e wska(nik jest pewnego rodzaju áczem do obiektu.
Wypadaáoby wic wresznie poáczyü si z tym obiektem, czyli uzyskaü dostp do jego
skáadników.

Operacja ta nie jest zbytnio skomplikowana, gdy* by j wykonaü posáu*ymy si znan ju*
koncepcj operatora wyáuskania. W przypadku wska(ników nie jest nim jednak
kropka, ale strzaáka (->). Otrzymujemy j, wpisujc kolejno dwa znaki: mylnika oraz
symbolu wikszoci.
Aby zatem wáczyü nasz lamp, wystarczy wywoáaü jej odpowiedni metod przy
pomocy którego z dwóch wska(ników oraz poznanego wáanie operatora:

Podstawy programowania

186

pLampa1->Wlacz();

Mo*emy tak*e sprawdziü, czy drugi wska(nik istotnie odwoáuje si do tego samego
obiektu co pierwszy. Wystarczy wywoáaü za jego pomoc metod Wlaczona():

pLampa2->Wlaczona();

Nie bdzie niespodziank fakt, i* zwróci ona wartoü

true

Zbierzmy wic w jednym miejscu informacje na temat obu operatorów wyáuskania:

Operator kropki (.) pozwala uzyskaü dostp do skáadników obiektu zawartego w
zmiennej obiektowej.

Operator strzaáki (->) wykonuje analogiczn operacj dla wska(nika na obiekt.

Jak najlepiej zapamitaü i rozró*niaü te dwa operatory? Proponuj prosty sposób:

pamitamy, *e zmienna obiektowa przechowuje obiekt jako swoj wartoü. Mamy
go wic dosáownie „na wycignicie rki” i nie potrzebujemy zbytnio si wysilaü,
aby uzyskaü dostp do jego skáadników. Sáu*cy temu celowi operator mo*e wic
byü bardzo maáy, tak maáy jak… punkt :)

kiedy za u*ywamy wska(nika na obiekt, wtedy nasz byt jest daleko std.
Potrzebujemy wówczas odpowiednio dáu*szego, dwuznakowego operatora, który
dodatkowo wska*e nam (strzaáka!) wáaciw drog do poszukiwanego obiektu.

Takie wyjanienie powinno byü w miar pomocne w przyswojeniu sobie znaczenia oraz
zastosowania obu operatorów.

Niszczenie obiektów

Wszelkie obiekty kiedy nale*y zniszczyü; czynnoü ta, oprócz wyrabiania dobrego
nawyku sprztania po sobie, zwalnia pamiü operacyjn, które te obiekty zajmowaáy. Po
zniszczeniu wszystkich mo*liwe jest bezpieczne zakoczenie programu.

Podobnie jak tworzenie, tak i niszczenie obiektów dostpnych poprzez wska(niki nie jest
wykonywane automatycznie. Wymagana jest do tego odrbna instrukcja - na szczcie
nie wyglda ona na wielce skomplikowan i przedstawia si nastpujco:

delete

pFoo;

// pFoo musi tu byü wska(nikiem na istniejcy obiekt

delete

(„usu”, podobnie jak

new

jest uwa*ane za operator) dokonuje wszystkich

niezbdnych czynnoci potrzebnych do zniszczenia obiektu reprezentowanego przez
wska(nik. Wywoáuje wic jego destruktor, a nastpnie zwalnia pamiü zajt przez
obiekt, który koczy wtedy definitywnie swoje istnienie.

To tyle jeli chodzi o *yciorys obiektu. Co si jednak dzieje z samym wska(nikiem? Otó*
nadal wskazuje on na miejsce w pamici, w którym jeszcze niedawno egzystowaá nasz
obiekt. Teraz jednak ju* go tam nie ma; wszelkie próby odwoáania si do tego obszaru
skocz si wic báedem, zwanym naruszeniem zasad dostpu (ang. access violation).
Pamitajmy zatem, i*:

Nie nale*y próbowaü uzyskaü dostpu do zniszczonego (lub niestworzonego) obiektu
poprzez wska(nik na niego. Spowoduje to bowiem bád wykonania programu i jego
awaryjne zakoczenie.

Musimy byü tak*e wiadomi, *e w momencie usuwania obiektu traci wa*noü nie tylko
ten wska(nik, którego u*ylimy do dokonania aktu zniszczenia, ale te* wszystkie inne

Obiekty

187

wska(niki odnoszce si do tego obiektu! To zreszt naturalne, skoro co do jednego
wskazuj one na t sam, nieaktualn ju* lokacj w pamici.

Stosowanie wska(ników na obiekty

Wczytujc si w powy*szy opis i spogldajc na krytycznym okiem mo*na uznaü, *e
stosowanie wska(ników na obiekty jest tylko niepotrzebnym zawracaniam sobie gáowy i
utrudnianiem *ycia. Nie doü, *e trzeba samemu dbaü o tworzenie i niszczenie obiektów,
to jeszcze nasz program mo*e si niechybnie „wysypaü”, jeli spróbujemy odwoáaü si do
nieistniejcego obiektu. I gdzie s te obiecane korzyci?…
Taka ocena jest naturalnie mocno niesprawiedliwa, a moim zadaniem jest przekonanie
ci, i* wska(niki s nie tylko przydatne w programowaniu obiektowym, ale wydaj si
wrcz niezbdne.

Przypomnijmy sobie najpierw, có* ciekawego powiedzielimy o obiektach na samych
pocztku rozdziaáu. Mianowicie wyjanilimy sobie, *e s to drobne cegieáki, z których
programista buduje swoj aplikacj.
To caákiem dobre porównanie, gdy* kryje w sobie jeszcze jeden ukryty sens: niewiele
mo*na zrobiü z zestawem cegieá, je*eli nie bdziemy dysponowali jakim spoiwem,
á

czcym je w caloü. Rol áczników speániaj wáanie wska(niki.

Ka*dy obiekt, aby byü u*ytecznym, powinien byü jako poáczony z innym obiektem. To
w zasadzie dosyü oczywista prawda, jednak na pocztku mo*na sobie nie caákiem zdawaü
z niej spraw.
Takie relacje najprociej realizowaü za pomoc wska(ników. Sposób, w jaki ácz one
obiekty, jest bardzo prosty: otó* jeden z nich powinien posiadaü pole, bdce
wska(nikiem na drugi obiekt. Ów drugi koniec ácza mo*e, jak wiemy, istnieü w
dowolnym miejscu pamici, co wicej - mo*liwe jest, by „dochodziá” do niego wicej ni*
jeden wska(nik! W ten sposób obiekty mog braü udziaá w dowolnej liczbie wzajemnych
relacji.

Schemat 20. Dziaáanie aplikacji opiera si na zale*nociach midzy obiektami

Tak to wyglda w teorii, ale poniewa* jeden przykáad wart jest tysica sáów, najlepiej
bdzie, je*eli przyjrzysz si takowemu przykáadowi. Przypuümy wic, *e jestemy w
trakcie pisania gry podobnej do sáawnego Lode Runnera: nale*y w niej zebraü wszystkie
przedmioty znajdujce si na planszy (zazwyczaj s to monety albo inne bogactwa), aby
awansowaü do kolejnego etapu. Jakie obiekty i jakie zale*noci nale*aáoby w tym
przypadku stworzyü?
Najlepiej zaczü od tego najwikszego i najwa*niejszego, grupujcego wszystkie inne -
na przykáad samego etapu. Podrzdnym w stosunku do niego bdzie obiekt gracza oraz,
rzecz jasna, pewna iloü obiektów monet (zapewne umieszczonych w tablicy albo innym
tego rodzaju pojemniku). Do tego dodamy pewnie jeszcze kilku wrogów; ostatecznie
nasz prosty model przedstawiaü si bdzie nastpujco:

Podstawy programowania

188

Schemat 21. Fragment przykáadowego diagramu powiza obiektów w grze

Dziki temu, *e obiekt etapu posiad dostp (naturalnie poprzez wska(nik) do obiektów
gracza czy te* wrogów, mo*e chocia*by uaktualniaü ich pozycj na ekranie w odpowiedzi
na wciskanie klawiszy na klawiaturze lub upáyw czasu. Odpowiednie rozkazy bdzie
zapewne otrzymywaá „z góry”, tj. od obiektu nadrzdnego wobec niego -
najprawdopodobniej jest to gáówny obiekt gry.

W podobny sposób, o wiele naturalniejszy ni* w programowaniu strukturalnym,
projektujemy model obiektowy ka*dego w zasadzie programu. Nie musimy ju* rozdzielaü
swoich koncepcji na dane i kod, wystarczy *e stworzymy odpowiednie klasy oraz obiekty i
zapewnimy powizania midzy nimi. Rzecz jasna, z wykorzystaniem wska(ników na
obiekty :)

Podsumowanie

Koczcy si rozdziaá byá nieco krótszy ni* par poprzednich. Podejrzewam jednak, *e
przebrnicie przez niego zajáo ci mo*e nawet wicej czasu i byáo o wiele trudniejsze.
Wszystko dlatego *e poznawalimy tutaj zupeánie now koncepcj programowania, która
wprawdzie ideowo jest o wiele bli*sza czáowiekowi ni* techniki strukturalne, ale w zamian
wymaga od razu przyswojenia sobie sporej porcji nowych wiadomoci i pojü. Nie martw
si zatem, jeli nie byáy one dla ciebie caákiem jasne; zawsze przecie* mo*esz wróciü do
trudniejszych fragmentów tekstu w przyszáoci (ponowne przeczytanie caáego rozdziaáu
jest naturalnie równie* dopuszczalne :D).

Nasze spotkanie z programowaniem obiektowym bdziemy zreszt kontynuowali w
nastpnym rozdziale, w którym to ostatecznie wyjani si, dlaczego jest ono takie
wspaniaáe ;)

Pytania i zadania

Nowopoznane, arcywa*ne zagadnienie wymaga oczywicie odpowiedniego powtórzenia.
Nie krpuj si wic i odpowiedz na poni*sze pytania :)

Pytania

Czym s obiekty i jaka jest ich rola w programowaniu z u*yciem technik OOP?

Jakie etapy obejmuje wprowadzenie do programu nowej klasy?

Obiekty

189

Jakie skáadniki mo*emy umieciü w definicji klasy?

(Trudne) Które skáadowe klasa posiada zawsze, niezale*nie od tego czy je
zdefiniujemy, czy nie?

W jaki sposób mo*emy z wntrza metody uzyskaü dostp do obiektu, na rzecz
którego zostaáa ona wywoáana?

Czym ró*ni si u*ycie wska(nika na obiekt od zmiennej obiektowej?

Jak odrbne obiekty w programie mog „wiedzieü” o sobie nawzajem i
przekazywaü midzy sob informacje?

wiczenia

Zdefiniuj prost klas reprezentujc ksi*k.

Napisz program podobny do przykáadu

DegreesCalc

, ale przeliczajcy midzy

jednostkami informacji (bajtami, kilobajtami itd.).

PROGRAMOWANIE

OBIEKTOWE

Gdyby murarze budowali domy tak,

jak programici pisz programy,

to jeden dzicioá zniszczyáby caá cywilizacj.

ze zbioru prawd o oprogramowaniu

Witam ci serdecznie, drogi Czytelniku! Powitanie to jest tutaj jak najbardziej wskazane.
Twoja obecnoü wskazuje bowiem, *e nadzwyczaj szybko wydostaáe si spod sterty
nowych wiadomoci, którymi obarczyáem ci w poprzednim rozdziale :) A nie byáo to
wcale takie proste, zwa*ywszy *e poznaáe tam zupeánie now technik programowania,
opierajc si na caákiem innych zasadach ni* te dotychczas ci znane.

Mimo to mogáe uczuü pewien niedosyt. Owszem, idea OOPu byáa tam przedstawiona
jako w miar naturalna, a nawet intuicyjna (w ka*dym razie bardziej ni* programowanie
strukturalne). Potrzeba jednak sporej dozy optymizmu, aby uznaü j na tym etapie za
co rewolucyjnego, co faktycznie zmienia sposób mylenia o programowaniu (a
jednoczenie znacznie je uáatwia).
By w peáni przekonaü si do tej koncepcji, trzeba o niej wiedzieü nieco wicej; kluczowe
informacje na ten temat s zawarte w tym oto rozdziale. Sdz wic, *e choüby z tego
powodu bdzie on dla ciebie bardzo interesujcy :D

Zajmiemy si w nim dwoma niezwykle wa*nymi zagadnieniami programowania
obiektowego: dziedziczeniem oraz metodami wirtualnymi. Na nich wáanie opiera si caáa
jego potga, pozwalajca tworzyü efektowne i efektywne programy.
Zobaczymy zreszt, jak owo tworzenie wyglda w rzeczywistoci. Kocow czü
rozdziaáu powiciáem bowiem na zestaw rad i wskazówek, które, jak sdz, oka* si
pomocne w projektowaniu aplikacji opartych na modelu OOP.

Kontynuujmy zatem poznawanie wspaniaáego wiata programowania obiektowego :)

Dziedziczenie

Drugim powodem, dla którego techniki obiektowe zyskaáy tak popularnoü

, jest

znaczcy postp w kwestii ponownego wykorzystywania raz napisanego kodu oraz
rozszerzania i dostosywania go do wáasnych potrzeb.
Cecha ta le*y u samych podstaw OOPu: program konstruowany jako zbiór
wspóádziaáajcych obiektów nie jest ju* bowiem monolitem, cisáym poáczeniem danych i
wykonywanych na operacji. „Rozdrobniona” struktura zapewnia mu zatem
modularnoü: nie jest trudno dodaü do gotowej aplikacji now funkcj czy te*

Pierwszym jest wspominana nie raz „naturalnoü” programowania, bez koniecznoci podziaáu na dane i kod.

Podstawy programowania

192

wyodrbniü z niej jeden podsystem i u*yü go w kolejnej produkcji. Uáatwia to i
przyspiesza realizacj kolejnych projektów.

Wszystko zale*y jednak od umiejtnoci i dowiadczenia programisty. Nawet stosujc
techniki obiektowe mo*na stworzyü program, którego elementy bd ze sob tak cile
zespolone, *e próba ich u*ycia w nastpnej aplikacji bdzie przypominaáa wciskanie
sáonia do szklanej butelki.

Istnieje jeszcze jedna przyczyna, dla której kod oparty na programowaniu obiektowym
á

atwiej poddaje si „recyklingowi”, majcemu przygotowaü go do ponownego u*ycia. Jest

nim wáanie tytuáowy mechanizm dziedziczenia.
Korzyci páynce z jego stosowania nie ograniczaj si jednak*e tylko do wtórnego
„przerobu” ju* istniejcego kodu. Przeciwnie, jest to fundamentalny aspekt OOPu
niezmiernie uáatwiajcy i uprzyjemniajcy projektowanie ka*dej w zasadzie aplikacji. W
poáczeniu z technologi funkcji wirtualnych oraz polimorfizmu daje on niezwykle
szerokie mo*liwoci, o których szczegóáowo traktuje praktycznie caáy niniejszy rozdziaá.

Rozpoczniemy zatem od dokáadnego opisu tego bardzo po*ytecznego mechanizmu
programistycznego.

O powstawaniu klas drog doboru naturalnego

Czáowiek jest tak dziwn istot, która bardzo lubi posiadaü uporzdkowany i
usystematyzowany obraz wiata. Wprowadzanie porzdku i pewnej hierarchii co do
postrzeganych zjawisk i przedmiotów jest dla nas niemal naturaln potrzeb.

Chyba najlepiej przejawia si to w klasyfikacji biologicznej. Widzc na przykáad psa
wiemy przecie*, *e nie tylko nale*y on do gatunku zwanego psem domowym, lecz tak*e
do gromady znanej jako ssaki (wraz z komi, sáoniami, lwami, maápami, lud(mi i caá
reszt tej mena*erii). Te z kolei, razem z gadami, ptakami czy rybami nale* do kolejnej,
znacznie wikszej grupy organizmów zwanych po prostu zwierztami.
Nasz pies jest zatem jednoczenie psem domowym, ssakiem i zwierzciem:

Schemat 22. Klasyfikacja zwierzt jako przykáad hierarchii typów obiektów

Programowanie obiektowe

193

Gdyby byá obiektem w programie, wtedy musiaáby nale*eü a* do trzech klas naraz

Byáoby to oczywicie niemo*liwe, je*eli wszystkie miaáyby byü wobec siebie równorzdne.
Tutaj jednak tak nie jest: wystpuje midzy nimi hierarchia, jedna klasa pochodzi od
drugiej. Zjawisko to nazywamy wáanie dziedziczeniem.

Dziedziczenie (ang. inheritance) to tworzenie nowej klasy na podstawie jednej lub kilku
istniejcych wczeniej klas bazowych.

Wszystkie klasy, które powstaj w ten sposób (nazywamy je pochodnymi), posiadaj
pewne elementy wspólne. Czci te s dziedziczone z klas bazowych, gdy* tam wáanie
zostaáy zdefiniowane.
Ich zbiór mo*e jednak zostaü poszerzony o pola i metody specyficzne dla klas
pochodnych. Bd one wtedy wspóáistnieü z „dorobkiem” pochodzcym od klas
bazowych, ale mog oferowaü dodatkow funkcjonalnoü.

Tak w teorii wyglda system dziedziczenia w programowaniu obiektowym. Najlepiej
bdzie, je*eli teraz przyjrzymy si, jak w praktyce mo*e wygldaü jego zastosowanie.

Od prostoty do komplikacji, czyli ewolucja

Powróümy wic do naszego przykáadu ze zwierztami. Chcc stworzyü programowy
odpowiednik zaproponowanej hierarchii, musielibymy zdefiniowaü najpierw odpowiednie
klasy bazowe. Nastpnie odziedziczylibymy ich pola i metody w klasach
pochodnych i dodali nowe, wáaciwe tylko im. Powstaáe klasy same mogáyby byü potem
bazami dla kolejnych, jeszcze bardziej wyspecjalizowanych typów.
Idc dalej t drog dotarlibymy wreszcie do takich klas, z których sensowne byáoby ju*
tworzenie normalnych obiektów.

Pojcie klas bazowych i klas pochodnych jest zatem wzgldne: dana klasa mo*e
wprawdzie pochodziü od innych, ale jednoczenie byü baz dla kolejnych klas. W ten
sposób ustala si wielopoziomowa hierarchia, podobna zwykle do drzewka.

Ilustracj tego procesu mo*e byü poni*szy diagram:

Schemat 23. Hierarchia klas zwierzt

A raczej do siedmiu lub omiu, gdy* dla prostoty pomináem tu wikszoü poziomów systematyki.

Podstawy programowania

194

Wszystkie przedstawione na nim klasy wywodz si z jednej, nadrzdnej wobec
wszystkich: jest ni naturalnie klasa Zwierz. Dziedziczy z niej ka*da z pozostaáych klas -
bezporednio, jak Ryba, Ssak oraz Ptak, lub porednio - jak Pies domowy.
Tak oto tworzy si kilkupoziomowa klasyfikacja oparta na mechanizmie dziedziczenia.

Z klasy bazowej do pochodnej, czyli dziedzictwo przodków

O podstawowej konsekwencji takiego rozwizania zd*yáem ju* wczeniej wspomnieü.
Jest ni mianowicie przekazywanie pól oraz metod pochodzcych z klasy bazowej do
wszystkich klas pochodnych, które si z niej wywodz. Zatem:

Klasa pochodna zawiera pola i metody odziedziczone po klasach bazowych. Mo*e tak*e
posiadaü dodatkowe, unikalne dla siebie skáadowe - nie jest to jednak obowizkiem.

Przeled(my teraz sposób, w jaki odbywa si odziedziczanie skáadowych na przykáadzie
naszej prostej hierarchii klas zwierzt.

U jej podstawy le*y „najbardziej bazowa” klasa Zwierz. Zawiera ona dwa pola,
okrelajce mas i wiek zwierzcia, oraz metody odpowiadajce za takie czynnoci jak
widzenie i oddychanie. Skáadowe te mogáy zostaü umieszczone tutaj, gdy* dotycz one
wszystkich interesujcych nas zwierzt i bd miaáy sens w ka*dej z klas pochodnych.
Tymi klasami, bezporednio dziedziczcymi od klasy Zwierz, s Ryba, Ssak oraz Ptak.
Ka*da z nich niejako „z miejsca” otrzymuje zestaw pól i metod, którymi legitymowaáo
si bazowe Zwierz. Klasy te wprowadzaj jednak tak*e dodatkowe, wáasne metody: i
tak Ryba mo*e páywaü, Ssak biegaü

, za Ptak lataü. Nie ma w tym nic dziwnego,

nieprawda*? :)
Wreszcie, z klasy Ssak dziedziczy najbardziej interesujca nas klasa, czyli Pies domowy.
Przejmuje ona wszystkie pola i metody z klasy Ssak, a wic porednio tak*e z klasy
Zwierz. Uzupeánia je przy tym o kolejne skáadowe, wáaciwe tylko sobie.

Ostatecznie wic klasa Pies domowy zawiera znacznie wicej pól i metod ni* mogáoby si
z pocztku wydawaü:

Schemat 24. Skáadowe klasy Pies domowy

Delfiny musz mi wybaczyü nieuwzgldnienie ich w tym przykáadzie :D

Programowanie obiektowe

195

Wykazuje poza tym pewn budow wewntrzn: niektóre jej pola i metody mo*emy
bowiem okreliü jako wáasne i unikalne, za inne s odziedziczone po klasie bazowej i
mog byü wspólne dla wielu klas. Nie sprawia to jednak *adnej ró*nicy w korzystaniu z
nich: funkcjonuj one identycznie, jakby byáy zawarte bezporednio wewntrz klasy.

Obiekt o kilku klasach, czyli zmiennoü gatunkowa

Oczywicie klas nie definiuje si dla samej przyjemnoci ich definiowania, lecz dla
tworzenia z nich obiektów. Je*eli wic posiadalibymy przedstawion wy*ej hierarchi w
jakim prawdziwym programie, to z pewnoci pojawiáyby si w nim tak*e instancje
zaprezentowanych klas, czyli odpowiednie obiekty.

W ten sposób wracamy do problemu postawionego na samym pocztku: jak obiekt mo*e
nale*eü do kilku klas naraz? Ró*nica polega wszak na tym, *e mamy ju* jego gotowe
rozwizanie :) Otó* nasz obiekt psa nale*aáby przede wszystkim do klasy Pies
domowy; to wáanie tej nazwy u*ylibymy, by zadeklarowaü reprezentujc go zmienn
czy te* pokazujcy na wska(nik. Jednoczenie jednak byáby on typu Ssak oraz typu
Zwierz, i mógáby wystpowaü w tych miejscach programu, w których byáby wymagany
jeden z owych typów.
Fakt ten jest przyczyn istnienia w programowaniu obiektowym zjawiska zwanego
polimorfizmem. Poznamy je dokáadnie jeszcze w tym rozdziale.

Dziedziczenie w C++

Pozyskawszy ogólne informacje o dziedziczeniu jako takim, mo*emy zobaczyü, jak idea
ta zostaáa przeáo*ona na nasz nieoceniony jzyk C++ :) Dowiemy si wic, w jaki sposób
definiujemy nowe klasy w oparciu o ju* istniejce oraz jakie dodatkowe efekty s z tym
zwizane.

Podstawy

Mechanizm dziedziczenia jest w C++ bardzo rozbudowany, o wiele bardziej ni* w
wikszoci pozostalych jzyków zorientowanych obiektowo

. Udostpnia on kilka

szczególnych mo*liwoci, które byü mo*e nie s zawsze niezbdne, ale pozwalaj na du*
swobod w definiowaniu hierarchii klas. Poznanie ich wszystkich nie jest konieczne, aby
sprawnie korzystaü z dobrodziejstw programowania obiektowego, jednak wiemy
doskonale, *e wiedza jeszcze nikomu nie zaszkodziáa :D

Zaczniemy oczywicie od najbardziej elementarnych zasad dziedziczenia klas oraz
przyjrzymy si przykáadom ilustrujcym ich wykorzystanie.

Definicja klasy bazowej i specyfikator

protected

Jak pamitamy, definicja klasy skáada si przede wszystkim z listy deklaracji jej pól oraz
metod, podzielonych na kilka czci wedle specyfikatorów praw dostpu. Najczciej
ka*dy z tych specyfikatorów wystpuje co najwy*ej w jednym egzemplarzu, przez co
skáadnia definicji klasy wyglda nastpujco:

class

nazwa_klasy

{

[

private

[deklaracje_prywatne]

[

protected

[deklaracje_chronione]

[

public

Dorównuj mu chyba tylko rozwizania znane z Javy.

Podstawy programowania

196

[deklaracje_publiczne]

};

Nieprzypadkowo pojawiá si tu nowy specyfikator,

protected

. Jego wprowadzenie

zwizane jest cile z pojciem dziedziczenia. Pojcie to wpáywa zreszt na dwa pozostaáe
rodzaje praw dostpu do skáadowych klasy.
Zbierzmy wic je wszystkie w jednym miejscu, wyjaniajc definitywnie znaczenie ka*dej
z etykiet:

private

: poprzedza deklaracje skáadowych, które maj byü dostpne jedynie dla

metod definiowanej klasy. Oznacza to, i* nie mo*na si do nich dostaü, u*ywajc
obiektu lub wska(nika na niego oraz operatorów wyáuskania . lub ->.
Ta wyácznoü znaczy równie*, *e prywatne skáadowe nie s dziedziczone i nie
ma do nich dostpu w klasach pochodnych, gdy* nie wchodz w ich skáad.

specyfikator

protected

(„chronione”) tak*e nie pozwala, by u*ytkownicy obiektów

naszej klasy „grzebali” w opatrzonych nimi polach i metodach. Jak sama nazwa
wskazuje, s one chronione przed takim dostpem z zewntrz.
Jednak w przeciwiestwie do deklaracji

private

, skáadowe zaznaczone przez

protected

s dziedziczone i wystpuj w klasach pochodnych, bdc

dostpnymi dla ich wáasnych metod.

Pamitajmy zatem, *e zarówno

private

, jak i

protected

nie pozwala, aby oznaczone

nimi skáadowe klasy byáy dostpne na zewntrz. Ten drugi specyfikator zezwala jednak
na dziedziczenie pól i metod.

public

jest najbardziej liberalnym specyfikatorem. Nie tylko pozwala na

odziedziczanie swych skáadowych, ale tak*e na udostpnianie ich szerokiej rzeszy
obiektów poprzez operatory wyáuskania.

Powy*sze opisy brzmi mo*e nieco sucho i niestrawnie, dlatego przyjrzymy si jakiemu
przykáadowi, który bdzie bardziej przemawiaá do wyobra(ni. Mamy wic tak oto klas
prostokta:

class

CRectangle

{

private

// wymiary prostokta

float

m_fSzerokosc, m_fWysokosc;

protected

// pozycja na ekranie

float

m_fX, m_fY;

public

konstruktor

CRectangle()

{ m_fX = m_fY =

0.0

;

m_fSzerokosc = m_fWysokosc =

10.0

; }

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

metody

float

Pole()

const

{

return

m_fSzerokosc * m_fWysokosc; }

float

Obwod()

const

{

return

* (m_fSzerokosc+m_fWysokosc); }

};

Opisuj go cztery liczby, wyznaczajce jego pozycj oraz wymiary. Wspóárzdne X oraz Y
uczyniáem tutaj polami chronionymi, za szerokoü oraz wysokoü - prywatnymi.
Dlaczego wáanie tak?…
Otó* powy*sza klasa bdzie równie* baz dla nastpnej. Pamitamy z geometrii, *e
szczególnym rodzajem prostokta jest kwadrat. Ma on wszystkie boki o tej samej
dáugoci, zatem nielogiczne jest stosowa do nich pojcia szerokoci i wysokoci.

Programowanie obiektowe

197

Wielkoü kwadratu okrela bowiem tylko jedna liczba, wic defincja odpowiadajcej mu
klasy mo*e wygldaü nastpujco:

class

CSquare :

public

CRectangle

// dziedziczenie z CRectangle

{

private

// zamiast szerokoci i wysokoci mamy tylko dáugoü boku

float

m_fDlugoscBoku;

// pola m_fX i m_fY s dziedziczone z klasy bazowej, wic nie ma

// potrzeby ich powtórnego deklarowania

public

konstruktor

CSquare { m_fDlugoscBoku =

10.0

; }

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

// nowe metody

float

Pole()

const

{

return

m_fDlugoscBoku * m_fDlugoscBoku; }

float

Obwod()

const

{

return

* m_fDlugoscBoku; }

};

Dziedziczy ona z CRectangle, co zostaáo zaznaczone w pierwszej linijce, ale postaü tej
frazy chwilowo nas nie interesuje :) Skoncentrujmy si raczej na konsekwencjach owego
dziedziczenia.
Porozmawiajmy najpierw o nieobecnych. Pola m_fSzerokosc oraz m_fWysokosc byáy w
klasie bazowej oznaczone jako prywatne, zatem ich zasig ogranicza si jedynie do tej
klasy. W pochodnej CSquare nie ma ju* po nich ladu; zamiast tego pojawia si bardziej
naturalne pole m_fDlugoscBoku z sensown dla kwadratu wielkoci.
Zwizane s z ni tak*e dwie nowe-stare metody, zastpujce te z CRectangle. Do
obliczania pola i obwodu wykorzystujemy bowiem sam dáugoü boku kwadratu, nie za
„jego” szerokoc i wysokoü, których w klasie w ogóle nie ma.

W definicji CSquare nie ma tak*e deklaracji m_fX oraz m_fY. Nie znaczy to jednak, *e
klasa tych pól nie posiada, gdy* zostaáy one po prostu odziedziczone z bazowej
CRectangle. Staáo si tak oczywicie za spraw specyfikatora

protected

Co wic powinnimy o nim pamitaü? Otó*:

Nale*y u*ywaü specyfikatora

protected

, kiedy chcemy uchroniü skáadowe przed

dostpem z zewntrz, ale jednoczenie mieü je do dyspozycji w klasach pochodnych.

Definicja klasy pochodnej

Dopiero posiadajc zdefiniowan klas bazow mo*emy przystpiü do okrelania
dziedziczcej z niej klasy pochodnej. Jest to konieczne, bo w przeciwnym wypadku
kazalibymy kompilatorowi korzystaü z czego, o czym nie miaáby wystarczajcych
informacji.

Skáadni definicji klasy pochodnej mo*emy pogldowo przedstawiü w ten sposób:

class

nazwa_klasy [: [specyfikatory] [nazwa_klasy_bazowej] [, ...]]

{

deklaracje_skáadowych

};

Poniewa* z sekwencj deklaracji_skáadowych spotkalimy si ju* nie raz i nie dwa
razy, skupimy si jedynie na pierwszej linijce podanego schematu.

Podstawy programowania

198

To w niej wáanie podajemy klasy bazowe, z których chcemy dziedziczyü. Czynimy to,
wpisujc dwukropek po nazwie definiowanej wáanie klasy i podajc dalej list jej klas
bazowych, oddzielonych przecinkami. Zwykle nie bdzie ona zbyt dáuga, gdy* w
wikszoci przypadków wystarczajce jest pojedyncze dziedziczenie, zakáadajce tylko
jedn klas bazow.

Istotne s natomiast kolejne specyfikatory, które opcjonalnie mo*emy umieciü przed
ka*d nazw_klasy_bazowej. Wpáywaj one na proces dziedziczenia, a dokáadniej na
prawa dostpu, na jakich klasa pochodna otrzymuje skáadowe klasy bazowej.
Kiedy za mowa o tych*e prawach, natychmiast przypominamy sobie o sáówkach

private

protected

public

, nieprawda*? ;) Rzeczywicie, specyfikatory

dziedziczenia wystpuj zasadniczo w liczbie trzech sztuk i s identyczne z tymi
wystpujcymi wewntrz bloku klasy. O ile jednak tamte pojawiaj si w prawie ka*dej
sytuacji i klasie, o tyle tutaj specyfikator

public

ma niemal caákowity monopol, a u*ycie

pozostaáych dwóch nale*y do niezmiernie rzadkich wyjtków.
Dlaczego tak jest? Otó* w 99.9% przypadków nie ma najmniejszej potrzeby zmiany praw
dostpu do skáadowych odziedziczonych po klasie bazowej. Je*eli wic które z nich
zostaáy tam zadeklarowane jako

protected

, a inne jako

public

, to prawie zawsze

yczymy sobie, aby w klasie pochodnej zachowaáy te same prawa. Zastosowanie

dziedziczenia

public

czyni zadoü tym *daniom, dlatego wáanie jest ono tak czsto

stosowane.

O pozostaáych dwóch specyfikatorach mo*esz przeczytaü w

MSDN

. Generalnie ich

dziaáanie nie jest specjalnie skomplikowane, gdy* nadaj skáadowym klasy bazowej

prawa dostpu wáaciwe swoim „etykietowym” odpowiednikom. Tak wic dziedziczenie

protected

czyni wszystkie skáadowe klasy bazowej chronionymi w klasie pochodnej, za

private

sprowadza je do dostpu prywatnego.

Formalnie rzecz ujmujc, stosowanie specyfikatorów dziedziczenia jest nieobowizkowe.
W praktyce jednak trudno korzystaü z tego faktu, poniewa* pominicie ich jest
równoznacznie z zastosowaniem specyfikatora

private

- nie za naturalnego

public

Niestety, ale tak wáanie jest i trzeba si z tym pogodziü.

Nie zapominaj wic o specyfikatorze

public

, gdy* jego brak przed nazw klasy bazowej

jest niemal na pewno bádem.

Dziedziczenie pojedyncze

Najprostsz i jednoczenie najczciej wystpujc w dziedziczeniu sytuacj jest ta, w
której mamy do czynienia tylko z jedn klasa bazow. Wszystkie dotychczas pokazane
przykáady reprezentowaáy to zagadnienie; nazywamy je dziedziczeniem pojedynczym
lub jednokrotnym (ang. single inheritance).

Proste przypadki

Najprostsze sytuacje, w których mamy do czynienia z tym rodzajem dziedziczenia, s
czsto spotykane w programach. Polegaj one na tym, i* jedna klasa jest tworzona na
podstawie drugiej poprzez zwyczajne rozszerzenie zbioru pól i metod.
Ilustracj bdzie tu kolejny przykáad geometryczny :)

class

CEllipse

// elipsa, klasa bazowa

{

Zakáadajc, *e mówimy o klasach deklaroanych poprzez sáowo

class

. W przypadku struktur (sáowo

struct

które s w C++ niemal to*same z klasami, to

public

jest domylnym specyfikatorem - zarówno dziedziczenia,

jak i dostpu do skáadowych.

Programowanie obiektowe

199

private

wikszy i mniejszy promie elipsy

float

m_fWiekszyPromien;

float

m_fMniejszyPromien;

protected

wspóárzdne na ekranie

float

m_fX, m_fY;

public

konstruktor

CEllipse() { m_fX = m_fY =

0.0

;

m_fWiekszyPromien = m_fMniejszyPromien =

10.0

; }

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

metody

float

Pole()

const

{

return

PI * m_fWiekszyPromien * m_fMniejszyPromien; }

};

class

CCircle :

public

CEllipse

// koáo, klasa pochodna

{

private

promie koáa

float

m_fPromien;

public

konstruktor

CCircle()

( m_fPromien =

10.0

; }

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

metody

float

Pole()

const

{

return

PI * m_fPromien * m_fPromien; }

float

Obwod()

const

{

return

* PI * m_fPromien; }

};

Jest on podobny do wariantu z prostoktem i kwadratem. Tutaj klasa CCircle jest
pochodn od CEllipse, zatem dziedziczy wszystkie jej skáadowe, które nie s prywatne.
Uzupeánia ponadto ich zbiór o dodatkow metod Obwod(), obliczajc dáugoü okrgu
okalajcego nasze koáo.

Sztafeta pokole

Hierarchia klas nierzadko nie koczy si na jednej klasie pochodnej, lecz siga nawet
bardziej wgáb. Nowo stworzona klasa mo*e byü bowiem bazow dla kolejnych, te za -
dla nastpnych, itd.

Na samym pocztku spotkalimy si zreszt z takim przypadkiem, gdzie klasami byáy
rodzaje zwierzt. Spróbujemy teraz przeáo*yü tamten ukáad na jzyk C++.
Zaczynamy oczywicie od klasy, z której wszystkie inne bior swój pocztek - CAnimal:

class

CAnimal

// Zwierz

{

protected

// pola klasy

float

m_fMasa;

unsigned

m_uWiek;

public

konstruktor

CAnimal()

{ m_uWiek =

; }

Podstawy programowania

200

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

metody

void

Patrz();

void

Oddychaj();

// metody dostpowe do pól

float

Masa()

const

{

return

m_fMasa; }

void

Masa(

float

fMasa) { m_fMasa = fMasa; }

unsigned

Wiek()

const

{

return

m_uWiek; }

};

Jej postaü nie jest chyba niespodziank: mamy tutaj wszystkie ustalone wczeniej,
publiczne metody oraz pola, które oznaczylimy jako

protected

. Zrobilimy tak, bo

chcemy, by byáy one przekazywane do klas pochodnych od CAnimal.

A skoro ju* wspomnialimy o klasach pochodnych, pomylmy o ich definicjach.
Zwa*ywszy, *e ka*da z nich wprowadza tylko jedn now metod, powinny one byü
raczej proste - i istotnie takie s:

class

CFish :

public

CAnimal

// Ryba

{

public

void

Plyn();

};

class

CMammal :

public

CAnimal

// Ssak

{

public

void

Biegnij();

};

class

CBird :

public

CAnimal

// Ptak

{

public

void

Lec();

};

Nie zapominamy rzecz jasna, *e oprócz widocznych powy*ej deklaracji zawieraj one
tak*e wszystkie skáadowe wzite od klasy CAnimal. Powtarzam to tak czsto, *e chyba
nie masz ju* co do tego *adnych wtpliwoci :D

Ostatni klas z naszego drzewa gatunkowego byá, jak pamitamy, Pies domowy.
Definicja jego klasy tak*e jest dosyü prosta:

class

CHomeDog :

public

CMammal

// Pies domowy

{

protected

// nowe pola

RACE

m_Rasa;

COLOR

m_KolorSiersci;

public

metody

void

Aportuj();

void

Szczekaj();

// metody dostpowe do pól

RACE

Rasa()

const

{

return

m_Rasa; }

COLOR

KolorSiersci()

const

{

return

m_KolorSiersci; }

};

Wyszukiwarka

Podobne podstrony:
Od zera do gier kodera6
Od zera do gier kodera6
Od zera do gier kodera8
Od zera do gier kodera7
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