www • programistamag • pl

Magazyn programistów i liderów zespołów IT

1 / 2012 (0 1) Cena 19.90 zł (w tym VAT 8%)

Programowanie gier pod iOS

Biblioteka Cocos2D

Wybrane Erlang - język C++11 - część I. Wykorzystanie

elementy języka inny niż C++ czy Nowy standard Kinect w sys­te­
Objective-C Java języka C++ mie Windows
Bardzo praktyczne porady Fascynująca podróż do kra- Kilka słów o tym, jakie (miłe!) Pierwszy krok do stworze-
dotyczące używania języka iny programowania w logice niespodzianki niesie ze sobą nia interfejsu użytkownika
Objective-C przy tworzeniu oraz programowania funk- nowa odsłona standardu rodem z filmu Minority
aplikacji pod iOS cyjnego języka C++ Report
 REDAKCJA/EDYTORIAL

Szanowni twórcy oprogramowania i specjaliści branży IT

Przed Wami pierwsze wydanie magazynu „Pro-
gramista”, które ukazało się również w postaci dru-
kowanej. Od niniejszego numeru magazyn staje się
miesięcznikiem. Przychy­liliśmy się też do Waszych
próśb i przygotowaliśmy magazyn w wersji elektro-
nicznej w plikach ePub i .mobi oraz .pdf.
Rośnie ilość i złożoność otaczających nas syste-
mów informatycznych. Rynek tabletów i smartfo- C++ oraz prezentujemy ciekawe tematy z zakresu
nów ciągle odnotowuje wzrosty i naturalną koleją
rzeczy powstają tysiące nowych aplikacji na te urzą-
dzenia: od gier po programy użytkowe. Rozwijają
się języki programowania, powstają kolejne wersje
„mobilnych” systemów operacyjnych. W tej sytuacji
nie ma wyjścia: chcąc pozostać konkurencyjnym
w zawodzie Programisty, trzeba się na bieżąco roz-
wijać, dokształcać. Naszym celem jest Wam to zada-
nie ułatwić.
W bieżącym numerze przedstawiamy bibliotekę
Cocos2D: jeden z najpopularniejszych silników do
tworzenia gier na platformę iOS. Ponadto poleca-
my praktyczny artykuł na temat języka Objective-C,
w którym autor omawia przydatne jego właściwości,
pozwalające znacznie usprawnić proces tworze-
nia aplikacji na urządzenia mobilne ze stajni Apple.
Znajdziecie u nas również ciekawy artykuł traktują-
cy o popularnym ostatnio podejściu Domain Driven
Design. Ponadto kontynuujemy tematykę poruszo-
ną w premierowym wydaniu naszego miesięcznika:
omawiamy możliwości nowego standardu języka
inżynierii oprogramowania.
Na koniec pragniemy serdecznie podziękować
za konstruktywne opinie dotyczące pierwszej, elek-
tronicznej edycji magazynu. Wydanie to udostępni-
liśmy bezpłatnie, by każdy mógł wyrobić sobie opi-
nię o projekcie. Olbrzymie zaintereso­wanie, jakim
cieszył się premierowy egzemplarz, utwierdza nas
w przekonaniu, że tego typu wy­dawnictwa brakowa-
ła na polskim rynku i dopinguje do jeszcze bardziej
wytężonej pracy nad magazy­nem.
Cieszy nas, że zdecydowana większość z Was po-
zytywnie oceni­ła inicjatywę! Dziękujemy za wsparcie
i życzymy przyjemnej lektury!

Z wyrazami szacunku,
Redakcja

Magazyn Programista wydawany jest

przez firmę Anna Adamczyk

Wydawca: Kierownik produkcji: Współpraca:

Anna Adamczyk Krzysztof Kopciowski Michał Bartyzel
annaadamczyk@programistamag.pl bok@keylight.com.pl Mariusz Sieraczkiewicz
Sławomir Sobótka
DTP: Artur Machura
Redaktor naczelny: Marek Sawerwain
Łukasz Łopuszański Krzysztof Kopciowski
Łukasz Mazur
lukaszlopuszanski@programistamag.pl Rafał Kułaga
Dział reklamy:
reklama@programistamag.pl
Redaktor prowadzący: tel. +48 663 220 102 Adres wydawcy:
Rafał Kocisz Dereniowa 4/47
tel. +48 604 312 716
rafal.kocisz@gmail.com 02-776 Warszawa
Prenumerata: Druk:
Korekta: prenumerata@ Zamów wydanie w wersji papierowej
Tomasz Łopuszański programistamag.pl przez www.programistamag.pl
4 / 1 . 2012 . (1)  /
SPIS TREŚCI

BIBLIOTEKI I NARZĘDZIA
Biblioteka Cocos2D: wprowadzenie............................................................................................. 6
Rafał Kocisz

JĘZYKI PROGRAMOWANIA
C++11 część I...................................................................................................................................... 22
Bartosz Szurgot, Mariusz Uchroński, Wojciech Waga

Wybrane elementy języka Objective-C i ich wykorzystanie................................................... 30

Łukasz Mazur

Erlang - język inny niż C++ czy Java.............................................................................................. 40

Marek Sawerwain

PROGRAMOWANIE GRAFIKI
Direct3D – podstawy........................................................................................................................ 50
Wojciech Sura

PROGRAMOWANIE URZĄDZEŃ
Wykorzystanie sensora Kinect w systemie Windows .............................................................. 56
Łukasz Górski

INŻYNIERIA OPROGRAMOWANIA
Domain Driven Design krok po kroku część II: Zaawansowane modelowanie DDD
– techniki strategiczne: konteksty i architektura zdarzeniowa............................................. 64
Sławomir Sobótka

KLUB LIDERA IT
Dokumentowanie architektury. Jak zorganizować proces rozwoju architektury?........... 72
Michał Bartyzel, Mariusz Sieraczkiewicz

WDROŻENIA
Projekt, oprogramowanie i wdrożenie pla­tformy inwestycyjnej highsky.com.................. 76
Wojciech Holisz

KOMIKS........................................................................................................................................................ 49
Maciej Mazurek

O ile nie zaznaczono inaczej, wszelkie prawa do wszystkich materiałów zamieszczanych na łamach magazynu
Programista są zastrzeżone. Kopiowanie i rozpowszechnianie ich bez zezwolenia jest wzbronione. Naruszenie
praw autorskich może skutkować odpowiedzialnością prawną, określoną w szczególności w przepisach ustawy
o prawie autorskim i prawach pokrewnych, ustawy o zwalczaniu nieuczciwej konkurencji i przepisach kodeksu
cywilnego oraz przepisach prawa prasowego.

Redakcja magazynu Programista nie ponosi odpowiedzialności za szkody bezpośrednie i pośrednie, jak również
za inne straty i wydatki poniesione w związku z wykorzystaniem informacji prezentowanych na łamach magazy­
nu Programista. Wszelkie nazwy i znaki towarowe lub firmowe występujące na łamach magazynu są zastrzeżone
przez odpowiednie firmy.

/ www.programistamag.pl / 5
 BIBLIOTEKI I NARZĘDZIA
Biblioteka Cocos2D: wprowadzenie
iOS to platforma, która rozbudza wyobraźnię wielu programistów. Któż z nas nie
marzy o karierze niezależnego twórcy gier i setkach tysięcy dolarów zarobionych
dzięki sprzedaży aplikacji na AppStore? W niniejszym artykule przedstawiona jest
biblioteka, która może być kluczem do spełnienia tych marzeń.
G
łównym celem niniejszego artykułu jest zapozna-
nie Czytelnika z podstawowymi blokami budulco-
wymi, które oferuje biblioteka Cocos2D. Po jego
przeczytaniu będziesz wiedział, czego możesz spodziewać
się po tym silniku i na ile przydatny będzie on w Twoich
projektach. Cocos2D to potężna biblioteka i szczegółowe
jej opisanie to temat, który kwalifikuje się bardziej na
książkę niż na artykuł. Z tego względu niniejszy tytuł kła-
dzie nacisk na ogólne zrozumienie koncepcji, na których
opiera się biblioteka Cocos2D, oraz przedstawienie relacji
między nimi. W jednym z ostatnich sekcji artykułu wska-
zane są materiały, z których zainteresowani Czytelnicy
będą mogli skorzystać w celu poszerzenia swojej wiedzy
na temat prezentowanej tu biblioteki.
DLACZEGO COCOS2D?
Zanim przejdziemy do omówienia możliwości biblioteki
Cocos2D, spróbujmy odpowiedzieć sobie na podstawowe
pytanie: co sprawia, że warto zainteresować się właśnie
tym konkretnym rozwiązaniem?
Pierwszy ważny powód, dla którego warto rozważyć
używanie Cocos2D, to fakt, iż biblioteka ta jest całkowicie
darmowa, zaś jej licencja pozwala tworzyć zarówno apli-
kacje komercyjne, jak i niekomercyjne. Licencja Cocos2D
jest otwarta, silnik rozpowszechniany jest razem z kodem
źródłowym. Oznacza to, że nic nie stoi na przeszkodzie,
aby w razie potrzeby zajrzeć do kodu źródłowego biblio-
teki czy wręcz wprowadzić do niej własne modyfikacje.
Cocos2D napisany jest w języku Objective-C. Biorąc
pod uwagę, że Cocos2D obsługuje urządzenia z rodziny
iOS oraz OS X, wybór ten wydaje się bardzo trafny: Ob-
jective-C to natywny język programowania w wymienio-
nych systemach. Dla osób, które znają inny język obiekto-
wy (np. C++, Java, C#), nauka Objective-C nie powinna
sprawić większych trudności. Osobom rozpoczynającym
przygodę z programowaniem sugerowałbym poświęce-
nie nieco czasu na solidne zapoznanie się z Objective-C,
zanim na poważnie zaczną zajmować się programowanie
gier pod iOS przy użyciu biblioteki Cocos2D.
Jak sugeruje nazwa biblioteki, Cocos2D wspomaga pro-
gramowanie gier 2D. Warto podkreślić jednak, że mowa
tutaj o nowoczesnych grach 2D, w których na porządku
dziennym są wykonywane w czasie rzeczywistym trans-
formacje obrazów (np. rotacja czy skalowanie), obsługa
przeźroczystości czy post-processing (wszystko to oczy-
6 / 1 . 2012 . (1)  /
Rafał Kocisz
wiście wspomagane akceleracją sprzętową). Jeśli jesteś
początkującym programistą gier, to zabawa z dwuwymia-
rem jest wręcz zalecana (chociażby dlatego, że algorytmy
stosowane w tego typu grach są o wiele łatwiejsze w im-
plementacji w stosunku do ich odpowiedników stosowa-
nych w grach 3D).
Dodatkowo, za Cocosem stoi bardzo liczna, prężna
i otwarta społeczność złożona w dużej mierze z niezależ-
nych programistów gier, co daje możliwość stosunkowo
łatwego uzyskania wsparcia. Ze względu na swoją popu-
larność Cocos2D może poszczycić się posiadaniem dużej
ilości wysokiej jakości materiałów edukacyjnych (samo-
uczków, książek, forów dyskusyjnych) oraz narzędzi, któ-
re wspierają i ułatwiają pracę z tą biblioteką.
Podsumowując, Cocos2D jest niewątpliwie biblioteką,
z którą warto się zapoznać. Jeśli masz ochotę zanurkować
w jego barwny świat, zapraszam do lektury dalszej części
niniejszego artykułu.
GRAF SCENY
Najważniejsza, centralna koncepcja, wokół której zbudo-
wana jest biblioteka Cocos2D to tzw. graf sceny (zwany
czasami drzewem sceny bądź hierarchią sceny). Zrozu-
mienie tej koncepcji jest kluczowe w przypadku gdy ktoś
chce efektywnie korzystać z prezentowanego tu silnika.
Wyobraź sobie, że masz zaimplementować fragment
graficznego interfejsu użytkownika w grze, coś podob-
nego do menu przedstawionego na Rysunku 1. Spróbuj
spojrzeć na ten obraz okiem programisty i zastanów
się, jak można by zorganizować model takiego interfej-
su użytkownika na poziomie kodu źródłowego. Pierwsza
myśl, która zapewne przyjdzie Ci do głowy, to przechowy-
wanie płaskiej listy obiektów reprezentujących wszystkie
widoczne elementy na ekranie (elementy tła, przyciski
i elementy tekstowe). Obiekty takie przechowywałyby in-
formacje o stanie poszczególnych elementów menu (np.
ich pozycja, stan, widoczność). Informacji tych można by
użyć do rysowania całej sceny, obsługi zdarzeń użytkow-
nika itp.
Podejście takie można by oczywiście z powodzeniem
zastosować, ale... zanim zaczniesz kodować, zastanów
się, czy nie można by było zorganizować tego lepiej?
Powiedzmy, że chciałbyś zaimplementować prosty efekt
polegający na tym, że druga warstwa tła z umieszczony-
mi na niej kontrolkami płynnie wsuwa się przy rozpoczę-

Rysunek 1. Proste menu gry (źródło: opracowanie własne)
ciu gry, zaś przy jej zakończeniu wysuwa się poza ekran
(patrz: Rysunek 2).
Sprawa niby prosta, jednakże przy zastosowaniu pła-
skiej listy jako struktury danych reprezentującej kolekcję
kontrolek, implementacja takiego efektu staje się nieco
uciążliwa: trzeba ręcznie wybrać wszystkie obiekty, które
chcemy wsuwać\wysuwać, i dla każdego z nich odpowied-
nio modyfikować ich pozycje. W tej sytuacji aż się prosi,
aby potraktować drugą warstwę tła jako płaszczyznę, na
której leżą wszystkie pozostałe kontrolki, i przesunąć ją,
razem ze wszystkim elementami, które są na niej umiesz-
czone. W tym celu możemy zastosować właśnie graf sceny.
Graf sceny to drzewiasta struktura danych pozwalająca
reprezentować obrazy (zarówno 2D i 3D) tak, aby zacho-
wać informację o hierarchii obiektów na nich występują-
cych. Kluczowym elementem grafu sceny jest węzeł (ang.
node), który spełnia dwojaką rolę: po pierwsze, repre-
zentuje wybrany element sceny; po drugie, jest kontene-
rem, który może przechowywać inne węzły, stanowiące
jego dzieci (ang. children). Węzeł posiadający dzieci na-
zywany jest rodzicem (ang. parent). W grafie sceny wy-
stępuje jeden węzeł, który nie posiada rodzica; nazywa-
my go korzeniem (ang. root). Znamienne dla grafu sceny
jest to, że każdy rodzic definiuje dla swoich dzieci swoisty
lokalny układ współrzędnych. Oznacza to, iż współrzęd-
ne dzieci (a także inne ich właściwości) rozpatrywane są
w odniesieniu do układu rodzica. Np. jeśli węzeł rodzic
(korzeń) ma pozycję (50, 50), zaś jego potomek znaj-
duje się w punkcie (10, 15), to rzeczywista (ekranowa)
pozycja tego drugiego wyniesie (60, 75). W takim ujęciu,
gdy zmienimy pozycję danego węzła, to automatycznie
przemieszczone zostaną jego dzieci.
Każdy węzeł w grafie sceny posiada identyczny inter-
fejs, opisany zazwyczaj przez abstrakcyjną klasę bazową.
Po tej klasie dziedziczą inne klasy, reprezentujące kon-
kretne węzły. Czytelnicy, którzy mieli styczność z tzw.
wzorcami projektowymi (ang. design patterns), słusznie
skojarzą przedstawiony tutaj opis ze wzorcem kompozyt
(ang. composite); de facto graf sceny jest niemalże wzor-
cowym przykładem takiego podejścia projektowego.
BIBLIOTEKA COCOS2D: WPROWADZENIE
Rysunek 2. Efekt wsuwania się menu (źródło: opracowanie
własne)
Rysunek 3. Hierarchia sceny dla prostego menu w grze (źródło:
opracowanie własne)
Spróbujmy odnieść przedstawione wyżej rozważania
do naszej przykładowej sceny. Na Rysunku 3 przedsta-
wiona jest wspomniana scena z oznaczeniem elementów
hierarchii w grafie. Korzeniem grafu jest pierwsza war-
stwa tła (czerwony prostokąt otaczający). Korzeń ma
jednego potomka: drugą warstwę tła (niebieski prostokąt
otaczający). Ten z kolei posiada czwórkę dzieci: przyci-
ski (żółte prostokąty otaczające). Każdy przycisk posia-
da jednego potomka, którym jest umieszczony pod nim
napis. Do reprezentacji takiej sceny potrzebowalibyśmy
dwóch konkretnych klas-węzłów reprezentujących sta-
tyczny obrazek (elementy tła i przyciski) oraz tekst (napi-
sy pod przyciskami).
Mając do dyspozycji tak zorganizowaną scenę, za-
programowanie efektu wsuwania się drugiej warstwy tła
z umieszczonymi na niej kontrolkami staje się bardzo pro-
ste; wystarczy jedynie odpowiednio zmodyfikować pozy-
cję węzła reprezentującego tę warstwę, a o właściwe po-
zycjonowanie pozostałych elementów zadba graf sceny.
Graf sceny to nieocenione narzędzie przy tworzeniu
aplikacji wyświetlających złożone obrazy zbudowane
z grup powiązanych ze sobą obiektów (pod tę kategorię
/ www.programistamag.pl / 7
 BIBLIOTEKI I NARZĘDZIA
Rysunek 4. Hierarchia klas wywodzących się z CCNode (źródło:
http://www.cocos2d-iphone.org/ )
można z powodzeniem podciągnąć większość nowocze-
snych gier 2D oraz 3D). Jest on również bardzo przydat-
ny w innych zastosowaniach, np. określanie widoczności
obiektów czy detekcja kolizji. Na tym etapie ważne jest,
abyś zrozumiał podstawową ideę tego wzorca projekto-
wego, gdyż stanowi on serce biblioteki Cocos2D.
KLASA BAZOWA CCNODE
Tak jak wspominałem w poprzednim punkcie, kluczo-
wymi elementami w grafie sceny są węzły. Każdy wę-
zeł dziedziczy po klasie bazowej, która definiuje spój-
ny interfejs dla wszystkich obiektów umieszczanych
w hierarchii. W przypadku biblioteki Cocos2D klasa
ta nazywa się CCNode. Po tej klasie dziedziczą kolejne
klasy, reprezentujące konkretne obiekty, które można
umieszczać w grafie sceny. Na Rysunku 4 przedstawio-
na jest hierarchia klas wywodzących się z klasy bazo-
wej CCNode.
Jak widać, klas tych jest całkiem sporo. Cocos2D to
bardzo aktywnie rozwijana biblioteka, więc w momen-
cie kiedy czytasz niniejszy artykuł, hierarchia ta może
8 / 1 . 2012 . (1)  /
wyglądać nieco inaczej od tej, która jest tutaj przedsta-
wiona (dotyczy ona Cocos2D w wersji 1.0.1), jednak-
że szereg koncepcji reprezentowanych przez wybrane
klasy niewątpliwie pozostaną niezmienne. Klasy te będą
szczegółowo omówione w kolejnych podpunktach niniej-
szego artykułu.
Zanim jednak do tego przejdziemy, przyjrzyjmy się
bardziej szczegółowo interfejsowi klasy CCNode. Jak już
wcześniej wspominałem, jest to klasa abstrakcyjna i nie
ma bezpośredniej reprezentacji wizualnej, jednakże pełni
bardzo istotną rolę, gdyż zawiera pola i metody wspólne
dla wszystkich węzłów przechowywanych w grafie sceny.
Oto lista najważniejszych z nich:
■■ tworzenie nowego węzła:
CCNode* childNode = [CCNode node];
■■ dodawanie węzła-dziecka:
[node addChild:child z:0 tag:73];

■■ wyłuskiwanie węzła-dziecka:
CCNode* child = [node getChildByTag:73];
■■ usuwanie węzła-dziecka określonego za pomocą iden-
tyfikatora: (z opcjonalnym czyszczeniem, polegającym
na zastopowaniu wszystkich akcji przypisanych do
usuwanego węzła):
[node removeChildByTag:73 cleanup:YES];
■■ usuwanie węzła-dziecka za pośrednictwem wskaźnika:
[node removeChild:child];
■■ usuwanie wszystkich dzieci z węzła:
[node removeAllChildrenWithCleanup:YES];
■■ usuwanie siebie samego z węzła-rodzica:
[node removeFromParentAndCleanup:YES];
Jak łatwo się można domyśleć, parametr z przekazywany
w metodzie addChild określa głębokość (ang. depth) wę-
zła w scenie i pozwala kontrolować kolejność rysowania
elementów przechowywanych w grafie. Zasada jest pro-
sta: elementy z małymi wartościami z rysowane są jako
pierwsze, zaś te, które mają największą głębokość – jako
ostatnie. Jeśli część węzłów posiada taką samą wartość
parametru z, to porządek ich rysowania określony jest
kolejnością ich dodawania do węzła-rodzica.
Z kolei parametr tag to rodzaj identyfikatora, za po-
mocą którego możemy szybko wyłuskiwać czy usuwać
węzły za pomocą takich metod jak getChildByTag czy
removeChildByTag. Korzystając z tagów, należy pa-
miętać o tym, że Cocos2D nie rozwiązuje problemu ich
unikalności, tj. jeśli umieścisz w scenie dwa, lub wię-
cej węzłów o identycznych identyfikatorach, to będziesz
w stanie dostać się tylko do pierwszego z nich; pozostałe
będą niedostępne. Cocos2D wykorzystuje tagi również do
identyfikacji tzw. akcji (co to są akcje, dowiesz się już
za moment); w tym miejscu chciałbym tylko wspomnieć,
że identyfikatory węzłów i akcji nie kolidują ze sobą, tak
więc dopuszczalna jest sytuacja, gdy zarówno węzeł, jak
i przypisana do niego akcja mają ten sam tag.
Jak już kilka razy wspomniałem, węzły mogą mieć
przypisane akcje (ang. actions). Koncepcję akcji opi-
szę szczegółowo w oddzielnym podpunkcie niniejszego
artykułu; tutaj przedstawię je tylko pokrótce, tak abyś
mógł zrozumieć relację pomiędzy nimi a węzłami. Pisząc
w największym skrócie, akcje to obiekty reprezentujące
działania wykonywane na obiektach sceny. Wyobraź so-
bie chcesz zaimplementować graficzny element na ekra-
nie (np. przycisk), który miarowo pulsuje (na przemian
powiększa się i zmniejsza) albo miarowo miga (na prze-
mian pojawia się i znika) bądź po prostu przemieszcza się
pomiędzy dwoma punktami. Wszystkie te operacje mo-
BIBLIOTEKA COCOS2D: WPROWADZENIE
żesz zrealizować przypisując do węzła reprezentującego
wspomniany element odpowiednie akcje. O tym, jakie są
kategorie akcji, porozmawiamy za moment; teraz kilka
słów na temat tego, jak można obsługiwać je z poziomu
interfejsu klasy CCNode. Na początek stwórzmy prostą
akcję reprezentującą proces migania węzła i przypiszmy
jej identyfikator:
CCAction* action =
[CCBlink actionWithDuration:5
blinks:10];
action.tag = 37;
Akcja ta przypisana do określonego węzła sprawi, że za-
miga on 10 razy w przeciągu 5 sekund. Klasa CCNode po-
zwala kontrolować akcje w następujący sposób:
■■ uruchomienie akcji:
[node runAction:action];
■■ wyłuskanie akcji określonej za pomocą identyfikatora:
CCAction* retrievedAction = [node
getActionByTag:37];
■■ zastopowanie akcji określonej za pomocą identyfikatora:
[node stopActionByTag:37];
■■ zastopowanie akcji określonej za pomocą wskaźnika:
[node stopAction:action];
■■ zastopowanie wszystkich akcji przypisanych do danego
węzła:
[node stopAllActions];
Ostatnią właściwością klasy CCNode, o której chciałbym
opowiedzieć, to możliwość tzw. harmonogramowania
wiadomości (ang. message scheduling). Brzmi to nieco
tajemniczo, jednakże w praktyce rzecz jest bardzo pro-
sta. Przede wszystkim należy wyjaśnić, że w nomenkla-
turze języka Objective-C wysłanie wiadomości do obiektu
oznacza po prostu wywołanie metody na tym obiekcie.
W takim ujęciu harmonogramowanie wiadomości ozna-
cza cykliczne wywoływanie określonej metody. Wyobraź
sobie, że chciałbyś mieć możliwość oprogramowania ja-
kiejś dedykowanej logiki dla danego typu węzłów (np.
detekcja kolizji bądź sprawdzanie warunku zakończenia
gry). Tego typu logikę umieszcza się zazwyczaj w meto-
dzie update bądź process, która wywoływana jest po
narysowaniu kolejnej ramki gry, przyjmującej jako pa-
rametr przyrost czasu od poprzedniego jej wywołania
(ang. time delta). Jeśli potrzebujesz takiej funkcjonalno-
ści w węźle, to musisz odpowiednio przeładować metodę
scheduleUpdateMethod (patrz: Listing 1).
/ www.programistamag.pl / 9
 BIBLIOTEKI I NARZĘDZIA
Listing 1. Harmonogramowanie prostej funkcji obsługującej
logikę węzła
-(void) scheduleUpdateMethod
{ ■■ kCCDirectorTypeDisplayLink: gwarantuje najlepszą
[self scheduleUpdate];
} sowaniu mechanizmu synchronizacji procesu uak-
-(void) update:(ccTime)delta
{ niestety – mechanizm ten dostępny jest od wersji 3.1
// Ta metoda będzie wywoływana po narysowaniu
// kolejnej ramki gry.
}
REŻYSER, SCENA, WARSTWA
Chciałbym przedstawić teraz trzy klasy, które pełnią w bi-
bliotece Cocos2D bardzo ważne role. Mowa tu o klasach
CCDirector, CCScene oraz CCLayer. Dwie ostatnie z wy-
mienionych dziedziczą z CCNode i podobnie jak ona, nie mają
wizualnej reprezentacji. CCScene to kontener dla wszyst-
kich obiektów znajdujących się na scenie. Obiekty tej klasy
reprezentują zazwyczaj ekrany gry: menu główne, tabelę
wyników czy wreszcie – właściwą rozgrywkę. Z kolei klasa
CCLayer (warstwa) służy do grupowania obiektów, głównie
w celu zapewnienia właściwej kolejności ich renderowania.
Można sobie np. wyobrazić, że ekran rozgrywki składa się
z trzech warstw: statycznego tła, części dynamicznej (ru-
chome obiekty gry) oraz paska statusu przedstawiające-
go liczbę zdobytych punktów oraz żyć. Ważną cechą klasy
CCLayer jest to, że potrafi ona przechwytywać zdarzenia
generowane przez użytkownika za pośrednictwem takich
kontrolerów jak ekran dotykowy czy akcelerometr. Szcze-
gólną rolę w tej układance pełni klasa CCDirector; pełni
ona rolę reżysera – decyduje o tym, która scena (CCScene)
będzie w danym momencie aktywna.
Na początek przyjrzyjmy się, co oferuje klasa CCDirec-
tor. Po pierwsze, klasa ta jest tzw. singletonem (singleton
jest to wzorzec projektowy, który zapewnia, że dana klasa
posiada tylko jedną instancję). Fakt ten wydaje się być
dość oczywisty (czy widziałeś kiedyś film lub przedsta-
wienie, za które odpowiadało dwóch reżyserów?). Głów-
ne zadanie reżysera w bibliotece Cocos2D to zarządzanie
scenami oraz przechowywanie danych konfiguracyjnych.
W szczególności klasa CCDirector odpowiada za:
■■ startowanie sceny,
■■ zamianę bieżącej sceny,
■■ wkładanie (ang. pushing) nowej sceny na bieżącą,
■■ zdejmowanie (ang. popping) bieżącej sceny,
■■ gwarantowanie dostępu do bieżącej sceny,
■■ pauzowanie, kontynuowanie oraz kończenie gry,
■■ przechowywanie i gwarantowanie dostępu do global-
nych danych konfiguracyjnych biblioteki Cocos2D,
■■ gwarantowanie dostępu do okna oraz widoku OpenGL,
■■ konwertowanie współrzędnych UIKit i OpenGL,
■■ kontrolowanie procesu uaktualniania stanu gry.
Pracując z biblioteką Cocos2D, mamy do wyboru cztery
typy reżyserów. Typy te implikują sposób kontrolowania
10 / 1 . 2012 . (1)  /
procesu uaktualniania stanu gry i w rezultacie mają bar-
dzo istotny wpływ na wydajność aplikacji:
wydajność oraz płynność renderowania, dzięki zasto-
tualniania ekranu z jego sprzętowym odświeżeniem;
systemu iOS wzwyż,
■■ kCCDirectorTypeNSTimer: gwarantuje największą
prze­nośność (będzie działać w każdej wersji systemu
iOS), ale jest za to najwolniejszy,
■■ kCCDirectorTypeThreadMainLoop: szybki, ale spra-
wia problemy w sytuacji, kiedy chcemy używać z po-
ziomu aplikacji Cocos2D widoków UIKit,
■■ KCCDirectorTypeMainLoop: jak wyżej.
Domyślnie biblioteka Cocos2D korzysta z reżysera typu
kCCDirectorTypeDisplayLink, zaś w sytuacji gdy nie jest
on dostępny (na dzień dzisiejszy bardzo mało prawdopodob-
na sytuacja), przełącza się na typ kCCDirectorTypeNSTimer.
Jeśli chciałbyś sam określić typ reżysera, to musisz zmo-
dyfikować następujący fragment kodu źródłowego w klasie
reprezentującej delegata aplikacji:
if ( ! [CCDirector
setDirectorType:
kCCDirectorTypeDisplayLink] )
[CCDirector
setDirectorType:
kCCDirectorTypeDefault];
Kolejną klasą z inwentarza biblioteki Cocos2D, z którą
warto się szczegółowo zapoznać, jest CCScene. Obiekty
tej klasy są zawsze korzeniami w grafie sceny. Rozwią-
zanie to wydaje się momentami odrobinę sztuczne (klasa
CCScene w zasadzie nie rozszerza w żaden sposób funk-
cjonalności CCNode), jednakże metody runWithScene,
replaceScene czy pushScene z klasy CCDirector potra-
fią współpracować tylko z obiektami tego typu. Poza tym,
sceny można opakować obiektami klas dziedziczących po
klasie bazowej CCSceneTransition, co pozwala uzyskać
miłe dla oka efekty przejść między scenami gry.
Pracując z biblioteką Cocos2D, zazwyczaj przyjmuje
się konwencję, że dziećmi sceny są jedynie warstwy (tj.
obiekty wywodzące się z klasy CCLayer), zaś one dopiero
zawierają w sobie węzły reprezentujące konkretne obiek-
ty występujące w grze.
Bardzo przydatnym mechanizmem jest wkładanie (ang.
pushing) oraz zdejmowanie (ang. popping) bieżącej sceny
z poziomu reżysera. Operacje te niewątpliwie kojarzą się
ze strukturą danych zwaną stosem. I rzeczywiście, myśląc
o tym, w jaki sposób klasa CCDirector zarządza scenami,
można posłużyć się modelem stosu. Oczywiście, wkładając
nową scenę na stos, bieżąca nadal pozostaje widoczna.
Mechanizm ten jest bardzo przydatny np. w sytuacji kie-
dy w trakcie gry chcemy wyświetlić okno dialogowe, bądź
podręczne menu. W tej sytuacji wkładamy nową scenę

Rysunek 5. Hierarchia klas wywodzących się z CCSceneTransition
(źródło: http://www.cocos2d-iphone.org/ )
na bieżącą, czekamy na działanie użytkownika, a w koń-
cu zdejmujemy bieżącą scenę ze stosu i automatycznie
wracamy do przerwanej rozgrywki. Manipulując scenami,
trzeba jednak uważać, aby nie przesadzić, gdyż za każdym
razem kiedy Cocos2D podmienia sceny, nowa scena jest
tworzona w pamięci, zaś stara zostaje usuwana.
Jak przed momentem wspominałem, używanie scen
pozwala uzyskiwać bardzo ciekawe efekty przejść (ang.
transition) pomiędzy ekranami gry reprezentowanymi
przez różne obiekty klasy CCScene. Służą ku temu kla-
sy wywodzące się z klasy bazowej CCSceneTransition.
Hierarchia tych klas przedstawiona jest na Rysunku 5. Na
Listingu 2 pokazany jest przykład zastosowania jednego
z przejść, tzw. zanikania (ang. fade).
Listing 2. Przykład zastosowania efektu CCTransitionFade
// Inicjalizacja obiektu reprezentującego efekt
// przejścia.
CCTransitionFade* transition =
[CCTransitionFade
BIBLIOTEKA COCOS2D: WPROWADZENIE
transitionWithDuration:1
scene:[MyScene scene]
withColor:ccBLACK];
// Zamiana scen z użyciem efektu przejścia.
[[CCDirector sharedDirector]
replaceScene:transition];
Wspomniany efekt polega na tym, że aktualna scena
powoli blaknie, aż do momentu kiedy cały ekran stanie
się czarny (lub inny; docelowy kolor można sobie do-
wolnie zdefiniować), po czym dzieje się efekt odwrot-
ny, tyle że pojawia się nowa scena. Zaimplementowanie
takiego efektu jest bardzo proste. W pierwszym kroku
należy stworzyć obiekt reprezentujący efekt przejścia;
w naszym przypadku będzie on typu CCTransitionFade.
W konstruktorze możemy określić długość efektu (w se-
kundach), kolor oraz docelową scenę. Potem wystarczy
tylko przekazać obiekt przejścia (na Listingu reprezento-
wany przez zmienną transition) do odpowiedniej me-
tody w klasie CCDirector. W tym przypadku należy pa-
/ www.programistamag.pl / 11
 BIBLIOTEKI I NARZĘDZIA
miętać, iż przejścia będą działać ze wszystkimi metodami
reżysera przewidzianymi do manipulacji scenami z jed-
nym wyjątkiem, który stanowi funkcja popScene. Dlacze-
go? Powód jest prosty: popScene nie przyjmuje żadnych
argumentów, po prostu zdejmuje ze stosu bieżącą scenę
i nie ma możliwości opakowania tej sceny obiektem re-
prezentującym efekt przejścia.
Cocos2D oferuje cały szereg efektów przechodzenia
między scenami, informacje na ich temat można znaleźć
w dokumentacji biblioteki.
Korzystając z efektów przejść, warto pamiętać o jed-
nej zasadzie, która brzmi: lepsze jest wrogiem dobrego.
Przejścia między scenami wyglądają bardzo efektownie,
jednakże jeśli przesadzimy z ich stosowaniem, to użyt-
kownicy naszej gry dostaną białej gorączki (szczególną
uwagę należy zwrócić na to, by czasy przejść między sce-
nami nie były zbyt długie).
Często zdarza się sytuacja kiedy warto podzielić scenę
na warstwy. Wtedy można skorzystać z klasy CCLayer. Na
Listingu 3 pokazane jest, jak można dodać kilka warstw
do sceny.
Listing 3. Dodawanie warstw do sceny
CCScene* scene = [CCScene node];
CCLayer* backgroundLayer = [Background node];
[scene addChild: backgroundLayer];
CCLayer* spritesLayer = [Sprites node];
[scene addChild:spritesLayer];
CCLayer* hudLayer = [Hud node];
[scene addChild: hudLayer];
Tak zainicjowana scena posiada trzy warstwy, które będą
(razem ze swoimi dziećmi) renderowane w kolejności ich
dodawania do sceny. Zaraz, zaraz! Ale czy podobnego
efektu nie można by uzyskać za pomocą zwykłych wę-
złów? Odpowiedź brzmi: owszem, można by. Co w takim
razie odróżnia warstwy (CCLayer) od zwykłych węzłów
(CCNode)? Zasadnicza różnica polega na tym, że warstwy
potrafią przechwytywać zdarzenia generowane przez
ekran dotykowy. Ponieważ takie przechwytywanie wiąże
się ze sporym narzutem wydajnościowym, domyślnie me-
chanizm ten jest wyłączony. Aby go włączyć, wystarczy
odpowiednio ustawić właściwość isTouchEnabled do-
stępną w klasie CCLayer:
self.isTouchEnabled = YES;
Kiedy tylko do właściwości isTouchEnabled zostanie
przypisana wartość YES, Cocos2D zacznie wywoływać na
obiekcie reprezentującym warstwę cały szereg funkcji
zwrotnych służących do obsługi zdarzeń generowanych
przez ekran dotykowy:
■■ -(void) ccTouchesBegan:(NSSet *)touches
withEvent:(UIEvent *)event – ta funkcja jest wy-
woływana, kiedy palec dotknie ekranu dotykowego,
12 / 1 . 2012 . (1)  /
■■ -(void) ccTouchesMoved:(NSSet *)touches
withEvent:(UIEvent *)event – ta funkcja jest wy-
woływana, kiedy palec przesuwa się po ekranie,
■■ -(void) ccTouchesEnded:(NSSet *)touches
withEvent:(UIEvent *)event – ta funkcja jest wy-
woływana, kiedy palec odrywa się od ekranu,
■■ -(void) ccTouchesCancelled:(NSSet *)touches
withEvent:(UIEvent *)event – ta funkcja jest wy-
woływana, kiedy proces przesuwania palca na ekranie
zostaje przerwany (zdarzenie to występuje bardzo
rzadko, powinno się je obsługiwać podobnie jak zda-
rzenie ccTouchesEnded).
DUSZKI
Jak dotąd omawialiśmy niemalże same abstrakcyjne kon-
cepcje: reżyser, graf sceny, warstwy, węzły... Wszystkie
to jest oczywiście potrzebne, jednakże trudno byłoby
zrealizować ciekawą gry składającą się jedynie z obiek-
tów nie posiadających reprezentacji graficznej. Jak więc
za pomocą Cocos2D wyświetlić zwykły obrazek? Odpo-
wiedzią na to jest klasa CCSprite. Klasa ta reprezentuje
tzw. duszka (ang. sprite). Duszek w nomenklaturze na-
zewnictwa używanego przez adeptów dziedziny wiedzy
określanej jako grafika komputerowa oznacza obraz (tek-
sturę) renderowaną bezpośrednio na ekran, w określonej
pozycji. Termin ten pojawił się już w latach 70 zeszłego
stulecia. Wiele systemów komputerowych z tamtych oraz
późniejszych lat używało duszków (których rysowanie
często bywało wspierane sprzętowo) do tworzenia dwu-
wymiarowych gier. Nowoczesne duszki (chociażby takie,
jakie oferuje Cocos2D) oprócz pozycji na ekranie pozwa-
lają określać skalę (ang. scale) ich wielkości, kąt obrotu
(ang. rotation angle), punkt zaczepienia (ang. anchor po-
int), poziom przeźroczystości (ang. opacity level), efekt
obrotu wokół osi (ang. flipping effect) czy ton koloru
(ang. color tint). Wszystkie te właściwości duszków sta-
nowią bazę dla uzyskiwania szeregów efektów, które na
co dzień oglądamy w nowoczesnych grach 2D.
Stworzenie duszka za pomocą biblioteki Cocos2D jest
bardzo proste. Najłatwiej można to zrobić przez załado-
wanie obrazka do tekstury (CCTexture2D), która z kolei
będzie przypisana do obiektu typu CCSprite. Z poziomu
kodu źródłowego wygląda to następująco:
CCSprite* heroSprite =
[CCSprite spriteWithFile:@”hero.png”];
W tym momencie warto napisać kilka
słów o tym, w jaki sposób Cocos2D po-
zycjonuje duszki. Tutaj mała zagadka:
jak według Ciebie będzie wyglądał ekran
po narysowaniu duszka załadowanego
za pomocą przedstawionego wyżej frag-
Rysunek 6. Przykładowa tekstura używana do wyświetlenia
duszka (źródło: http://www.lostgarden.com)

Rysunek 7. Duszek wyświetlony na ekranie (pozycja domyślna)
mentu kodu (obrazek hero.png przedstawiony jest na Ry-
sunku 6)? W ramach podpowiedzi dodam, że obiekty kla-
sy CCSprite mają domyślnie ustawioną pozycję (0, 0).
Jeśli chcesz poznać odpowiedź na to pytanie, spójrz
proszę na Rysunek 7. Jak widać, duszek został wyświe-
tlony tylko fragmentarycznie i na dodatek w lewym dol-
nym rogu ekranu. Czy aby wszystko jest w porządku?
Jak najbardziej! Kwestia wyświetlenia duszka w lewym
dolnym rogu wiąże się z tym, jak Cocos2D postrzega
układ współrzędnych. Według konwencji przyjętej w tej
bibliotece, punkt (0, 0) tego układu znajduje się właśnie
w lewym dolnym rogu ekranu. Problem przycięcia dusz-
ka jest troszkę bardziej skomplikowany. Wiąże się on
z tzw. punktem zaczepienia, o którym wspominałem kilka
akapitów wyżej. Punkt zaczepienia jest punktem zdefi-
niowanym w układzie współrzędnych tekstury. Układ ten
jest zorganizowany w dość specyficzny sposób. Punkty
umieszczane w tym układzie mogą przyjmować warto-
ści ze zmiennoprzecinkowego zakresu [0.0, 1.0]. Wartość
BIBLIOTEKA COCOS2D: WPROWADZENIE
1.0 oznacza odpowiednio szerokość bądź
wysokość tekstury. Punkt zaczepienia w bi-
bliotece Cocos2D ustawiony jest domyślnie
na wartość (0.5, 0.5), czyli środek tekstury.
Gdybyśmy ustawili go na wartość (0.0, 0.0),
to wskazywałby on na lewy-górny róg tek-
stury itd. Wracając do problemu przycięcia,
cały haczyk polega na tym, że pozycja dusz-
ka na ekranie zawsze odnosi się do tego pun-
tu zaczepiania. Innymi słowy, gdy ustawimy
ekranową pozycję duszka na punkt (0, 0),
zaś jego punkt zaczepienia określony będzie
jako (0.5, 0.5), to zostanie on narysowany
w taki sposób, iż punkt centralny tekstury re-
prezentującej duszka pojawi się na układzie
współrzędnych ekranu w punkcie (0, 0), czyli
– jak wyżej pisałem, w lewym-dolnym rogu.
Jeśli chcielibyśmy zmodyfikować pozycję na-
szego duszka na ekranie w taki sposób, aby
był w całości wyświetlony w lewym-dolnym
rogu, można ustawić jego punkt zaczepie-
nia na wartość (0.0, 0.0), bądź zmodyfiko-
wać jego pozycję, przesuwając go w prawo
i w górę o wartości odpowiadające połowie
szerokości i wysokości reprezentującej go
tekstury.
Z efektywnym korzystaniem z duszków
wiąże się szereg technicznych ograniczeń,
wynikających przede wszystkim z charak-
terystyki nowoczesnych układów wspoma-
gających sprzętowo renderowanie grafiki.
Cocos2D w miarę swoich możliwości ukrywa
przed programistą techniczne detale, jed-
nakże znajomość i świadomość istnienia ww.
ograniczeń jest kluczem do tworzenia efek-
tywnych i płynnie działających gier pod iOS.
Niestety, od pewnych kwestii nie da się uciec.
Pierwszy problem, którego należy być świadomym, to
wymiarowość tekstur. Układy graficzne, z których korzy-
sta system iOS, potrafią współpracować jedynie z tekstu-
rami o wielkościach będących potęgami dwójki z zakresu
[2, 2048]. Ograniczenie to, połączone z niefrasobliwym
podejściem do kwestii korzystania z tekstur może prowa-
dzić do poważnych problemów związanych ze zużyciem
pamięci. Dla przykładu, jeśli stworzymy za pomocą bi-
blioteki Cocos2D duszka reprezentowanego przez obraz
o rozmiarach 257 na 257 pikseli, to w celu jego załado-
wania silnik wygeneruje teksturę o rozmiarach 512 na
512 pikseli. Taka tekstura, przy założeniu, że korzystamy
z 32-bitowego formatu piksela, może zająć około 1MB
w pamięci karty graficznej. Dla nieświadomego tego pro-
blemu programisty może stanowić to niemały szok...
Inny ważny problem związany z korzystaniem z duszków
wiąże się z przełączaniem tekstur. Rzecz polega na tym, że
nowoczesne układy graficzne zaprojektowane zostały w taki
sposób, iż nie potrafią współdziałać z dużą ilością tekstur
w tym samym czasie. Typowy schemat współpracy ukła-
du graficznego z teksturami wygląda następująco: załaduj
/ www.programistamag.pl / 13
 BIBLIOTEKI I NARZĘDZIA
teksturę; rysuj korzystając z danych zawartych w aktualnie
załadowanej teksturze; załaduj kolejną teksturę; itd. Ha-
czyk w całej tej zabawie polega na tym, że operacja przeła-
dowania tekstury jest bardzo czasochłonna. Tak bardzo, że
niefrasobliwe jej używanie może literalnie zabić wydajność
gry. Wyobraź sobie, że tworzysz dwuwymiarową grę typu
shoot'em up, czyli klasyczną strzelaninę, w której Twój bo-
hater pędząc w uzbrojonym pojeździe kosmicznym niszczy
hordy Obcych próbujących podbić Ziemię. Gra oczywiście
składa się z całego szeregu animacji opartych na duszkach.
Pół biedy, jeśli wpadniesz na pomysł, aby klatki animacji
pojazdu gracza i poszczególnych przeciwników umieścić
w oddzielnych plikach. Gorzej, jeśli każdą klatkę zechcesz
trzymać w osobnym obrazku. Jeśli tak zrobisz, gwarantuję
Ci, że Twoja gra będzie (może) działać w granicach 2-3
FPS'ów, nawet na urządzeniach nowej generacji.
14 / 1 . 2012 . (1)  /
Rysunek 8. Przykładowy atlas tekstur
(źródło: http://pocketgod.wikia.com)
Lekarstwem na opisane wyżej problemy jest stosowa-
nie tzw. atlasów tekstur (ang. texture atlases). Są to po
prostu obrazki o wymiarach kompatybilnych z wymia-
rami tekstur, do których upakowane są wszystkie ele-
menty graficzne wykorzystywane w grze. Oprócz tego,
w oddzielnym pliku umieszcza się informacje o położeniu
oryginalnych obrazków na atlasie, dzięki czemu można
się do nich odwoływać w trakcie działania gry. Na Ry-
sunku 8 pokazany jest przykładowy atlas tekstur. Pro-
ces tworzenia takich atlasów jest zazwyczaj zautoma-
tyzowany. Istnieją dedykowane narzędzia, korzystające
w zaawansowanych algorytmów optymalizacyjnych słu-
żące po to aby składać dużą liczbę małych plików gra-
ficznych w jeden duży. Część z tych narzędzi przysto-
sowana jest do współpracy z biblioteką Cocos2D. Jedną
z ciekawszych opcji w tym zakresie jest TexturePacker

(http://www.texturepacker.com/), który w podstawowej
wersji dostępny jest za darmo.
Cocos2D oczywiście oferuje wsparcie dla atla-
sów tekstur, które obsługiwane są za pomocą klas
CCSpriteFrameCache oraz CCSpriteFrame. Przedstawie-
nie procesu tworzenia atlasu i obsługiwania go z poziomu
silnika wykracza poza ramy niniejszego artykułu. Ważne
jest, abyś był świadom istnienia tych klas, aczkolwiek jeśli
planujesz pracować z Cocosem na poważnie, to prędzej czy
później będziesz musiał zapoznać się z tym zagadnieniem.
W razie czego ciekawy samouczek opisujący ten temat mo-
żesz znaleźć tutaj: http://www.raywenderlich.com/1271/
how-to-use-animations-and-sprite-sheets-in-cocos2d.
RENDEROWANIE TEKSTU
Renderowanie napisów jest jednym z nieodzownych ele-
mentów każdej niemalże gry. W tej sytuacji nie do pomy-
ślenia jest, aby Cocos2D nie oferował żadnych usprawnień
w tym zakresie. Jak się zapewne domyślasz, uspraw-
nienia takie istnieją i zamierzam je w tym podpunkcie
zaprezentować.
Najprostszym sposobem wyświetlenia tekstu przy
pomocy biblioteki Cocos2D jest użycie obiektu klasy
CCLabelTTF. Klasa ta, jak się łatwo domyśleć po jej na-
zwie, służy do wyświetlania napisów w oparciu o czcionki
TrueType. Podstawowe użycie tej klasy pokazane jest na
Listingu 4.
Listing 4. Proste użycie klasy CCLabelTTF
CCLabelTTF* label =
[CCLabelTTF labelWithString:@"Hello, Cocos2D!"
fontName:@"Arial"
fontSize:32];
Jak widać, rzecz jest bardzo prosta. Inna sprawa, że pro-
sto nie zawsze oznacza wydajnie. Zanim zaczniesz uży-
wać klasy CCLabelTTF, musisz być świadom, że pod ma-
ską działa ona w ten sposób, iż w locie generuje teksturę
i renderuje do niej żądany tekst, korzystając z odpowied-
niej definicji czcionki TrueType. Takie renderowanie do
pośredniej tekstury jest operacją dość zasobożerną i jeśli
planujesz na bieżąco modyfikować zawartość tekstu re-
prezentowanego przez CCLabelTTF to licz się z potencjal-
nym spadkiem wydajności Twojej aplikacji.
Drugi problem związany z używaniem czcionek
TrueType jest tego rodzaju, że czasami trudno jest dobrać
krój liter odpowiedni do Twojej gry. W praktyce często
robi się tak, że grafik przygotowuje dedykowany zestaw
znaków dla danej gry w postaci tzw. czcionki bitmapowej
(ang. bitmap font). Czcionka taka zazwyczaj dostarczana
jest w postaci dwóch plików: tekstury, na której umiesz-
czone są poszczególne znaki, oraz metadanych (np. pliku
w formacie XML, JSON czy plist), które definiują pozycje
i atrybuty poszczególnych znaków na teksturze. Prakty-
ka pokazuje, że czcionki bitmapowe są o wiele częściej
używane w grach niż czcionki TrueType. Napis oparty na
czcionce bitmapowej można też łatwiej i wydajniej rende-
BIBLIOTEKA COCOS2D: WPROWADZENIE
rować „w locie”, bez posiłkowania się oddzielną teksturą.
Z tej racji, obiektów klasy CCLabelTTF w praktyce używa
się głównie do wyświetlania informacji użytecznych przy
debugowaniu aplikacji czy do szybkiego prototypownia.
Cocos2D oczywiście wspiera czcionki bitmapowe. Do
ich obsługi wykorzystuje się klasę CCLabelBMFont. Ko-
rzystanie z tej klasy jest równie proste jak korzystanie
z CCLabelTTF (patrz Listing 5), ale... Analizując ten Li-
sting, można zauważyć dwie istotne kwestie. Po pierwsze,
aby wczytać pożądany font, musimy wskazać konkretny
plik .fnt. Od razu pojawia się pytanie: skąd go wziąć? Po
drugie, przy wczytywaniu fonta nie podajemy jego wiel-
kości, co wydaje się zrozumiałe: przecież wymiar fonta
bitmapowego zależy od tego, jak go sobie narysujemy. Te
dwa spostrzeżenia wiążą się z podstawowymi problemami
dotyczącymi stosowania fontów bitmapowych. Pierwsza
kwestia w zasadzie nie jest problemem sensu stricto. To
raczej konsekwencja decyzji używania takiego a nie inne-
go formatu fonta. Po prostu w celu stworzenia pliku .fnt
(a także towarzyszącego mu pliku .png) musimy skorzy-
stać z narzędzia. Opcji jest kilka:
■■ Hiero (http://slick.cokeandcode.com/demos/hiero.jnlp):
aplikacja webowa napisana w Javie; jej główną zaletą
jest fakt, iż jest ona darmowa; niestety, poza tym stwa-
rza sporo problemów związanych z błędami istniejącymi
w tym narzędziu,
■■ Glyph Designer (http://glyphdesigner.71squared.com/):
natywna aplikacja przeznaczona dla systemów z ro-
dziny OS X; wysoce stabilna i oferująca szereg przy-
datnych funkcji, aczkolwiek płatna (aktualna cena:
29.99$); jeśli planujesz na poważnie zająć się progra-
mowaniem gier pod iOS z wykorzystaniem Cocos'a, to
bezwzględnie polecam zakup tego narzędzia,
■■ BMFont (www.angelcode.com/products/bmfont/): na-
tywna aplikacja przeznaczona pod systemy z rodziny...
Windows. Darmowa i stabilna, jednakże – jeśli Twoim
podstawowym środowiskiem pracy jest OS X – to jej
używanie może być nieco kłoptliwe.
Przedstawienie mechanizmu generowania fonta bitmapo-
wego przekracza ramy niniejszego artykułu; zaintereso-
wanych odsyłam do dokumentacji wymienionych wyżej
narzędzi.
Drugi problem związanym z używaniem fontów bitma-
powych to stały rozmiar czcionki. Oczywiście węzły typu
CCLabelBMFont można normalnie skalować (jak każdy
inny węzeł w grafie sceny), jednakże w takim przypadku
traci się jakość (co akurat w przypadku fontów jest dość
istotne). Rozwiązaniem jest przygotowanie fontów bitma-
powych w różnych wielkościach.
Listing 5. Proste użycie klasy CCLabelBMFont
CCLabelBMFont* label =
[CCLabelBMFont
labelWithString:@"Hello, Cocos2D!"
fntFile:@"bitmapfont.fnt"];
/ www.programistamag.pl / 15
 BIBLIOTEKI I NARZĘDZIA
SYSTEMY CZĄSTECZEK
Nieodłącznym elementem nowoczesnych gier 2D są
efekty oparte na systemach cząsteczek. Pisząc w dużym
uproszczeniu, system taki złożony jest ze zbioru wielu
cząstek emitowanych przez źródło. Każda cząstka ma
określone parametry, między innymi: czas życia, rozmiar,
kolor, położenie czy prędkość. Kluczowym elementem
systemu jest tzw. emiter, którego głównym zadaniem jest
tworzenie cząstek, sterowanie ich ruchem i modyfikacja
ich parametrów. Po upływie czasu życia cząstki są usu-
wane. Za pomocą systemów cząsteczek można wizualizo-
wać szereg ciekawych efektów, np.: deszcz, śnieg, dym,
ogień, wybuchy, opary itp.
Cocos2D oferuje bazową klasę abstrakcyjną CCParti-
cleSystem oraz dwie klasy konkretne: CCParticleSys-
temPoint oraz CCParticleSystemQuad. Klasy te repre-
zentują uniwersalny system cząsteczkowy zdefiniowany
przez szereg właściwości definiujące różnorakie aspekty
jego działania. W celu stworzenia własnego systemu czą-
steczek musimy stworzyć klasę dziedziczącą CCParticle-
SystemPoint bądź CCParticleSystemQuad, a następnie
odpowiednio skonfigurować odziedziczone właściwości
(różnice pomiędzy tymi klasami mają charakter czysto im-
plementacyjny; pierwsza z nich jest zoptymalizowana pod
starsze urządzenia z rodziny iOS, druga – pod nowsze).
Jak można się domyśleć, takie „ręczne” dostrajanie syste-
mu z poziomu kodu źródłowego nie jest łatwym zadaniem.
Na szczęście istnieje druga, łatwiejsza droga, polegają-
ca na skorzystaniu z narzędzia Particle Designer (http://
particledesigner.71squared.com/). Narzędzie to pozwala
za pomocą szeregu kontrolek graficznego interfejsu użyt-
kownika dostroić system cząsteczek, przy czym w okienku
podglądu możemy w czasie rzeczywistym oglądać rezulta-
ty wprowadzanych przez nas zmian. Kiedy uzyskamy już
zadowalający nas efekt, wystarczy wyeksportować konfi-
gurację systemu w formacie Cocosa (plik .plist) i stworzyć
obiekt CCParticleSystemQuad w następujący sposób:
CCParticleSystem* system =
[CCParticleSystemQuad
particleWithFile:@"ps.plist"];
po czy możemy cieszyć się pięknym efektem cząsteczko-
wym w naszej grze.
Particle Designer jest narzędziem płatnym (aktualna
cena: 7.99$), jednakże warto się w niego zaopatrzyć,
szczególnie jeśli planujesz używać w swojej grze dużo
efektów opartych na cząsteczkach.
AKCJE
Obiekty klas wywodzących się z CCAction, o których
opowiadałem bardzo ogólnie na początku niniejszego ar-
tykułu, reprezentują akcje, które można wykonywać na
węzłach. Za ich pomocą można przesuwać, skalować, ob-
racać i wykonywać wiele innych ciekawych operacji na
elementach grafu sceny. Obiektu reprezentującego akcję
16 / 1 . 2012 . (1)  /
nic a nic nie obchodzi, czy działa na prostym węźle typu
CCSprite, czy na złożonej scenie. Dzięki kompozytowej
strukturze węzłów obracanie pojedynczego duszka czy
warstwy reprezentującej złożoną grupę obiektów odbywa
się w ten sam sposób. Akcje są kluczowym elementem
biblioteki Cocos2D; można wręcz pokusić się o stwierdze-
nie, że obok koncepcji grafu sceny stanowią jeden z trzo-
nów filozofii na której opiera się ten silnik. W niniejszym
podpunkcie zapoznamy się z nimi bardziej szczegółowo.
Klasą bazową dla wszystkich akcji jest CCAction. Jest
to klasa abstrakcyjna, z której dziedziczą cztery inne
klasy:
■■ CCFiniteTimeAction: klasa abstrakcyjna reprezen-
tująca kategorię akcji wykonywalnych w skończonym
czasie; z niej z kolei wywodzą się dwie kolejne kate-
gorie akcji: CCActionInstant oraz CCActionInterval
(więcej szczegółów na ich temat podam za chwilę),
■■ CCFollow: akcja, która pozwala, aby określony węzeł
podążał za innym węzłem,
■■ CCRepeatForever: akcja, która powtarza inną akcję
w nieskończoność,
■■ CCSpeed: akcja, która zmienia częstotliwość wywoły-
wania metody uaktualniającej logikę innej akcji.
Na Listingu 6 przedstawiony jest fragment kodu, który
tworzy akcję obracającą w nieskończoność węzeł, do któ-
rego będzie przypisana.
Listing 6. Definicja akcji obracającej w nieskończoność wę-
zeł, do którego będzie przypisana
// Stwórz akcję, która wykonuje pełny obrót węzła
// (360 stopni).
CCRotateBy* rotateBy360 =
[CCRotateBy actionWithDuration:2 angle:360];
// Stwórz akcję, która powtarza w nieskończoność
// akcję rotateBy360.
CCRepeatForever* rotateForever =
[CCRepeatForever actionWithAction:rotateBy360];
// Przypisz akcję do węzła.
[spriteNode runAction:rotateForever];
Większość akcji, z którymi mamy do czynienia, dzie-
je się w określonym przedziale czasu. Wszystkie ta-
kie akcje reprezentowane są przez abstrakcyjną klasę
CCActionInterval. Najbardziej podstawową z tych akcji
jest niewątpliwie CCMoveTo. Akcja ta odpowiada za prze-
sunięcie węzła do określonej pozycji w zadanym interwale
czasu. Na przykład tak skonfigurowana akcja:
CCMoveTo* moveTo =
[CCMoveTo actionWithDuration:1
position:CGPointMake(100, 100)];
spowoduje, że węzeł, do którego będzie ona przypisana
przesunie się do punktu (100, 100) w przeciągu jednej
sekundy. Zamienne dla akcji wywodzących się z klasy ba-

zowej CCActionInterval jest to, że po ich zakończeniu
nie ma potrzeby odłączania ich od węzła. Kiedy taka akcja
się zakończy, to sama usunie się z węzła i zwolni zaj-
mowaną pamięć. Biblioteka Cocos2D oferuje cały zestaw
użytecznych akcji interwałowych. Za ich pomocą można
niemalże w dowolny sposób manipulować węzłami. Peł-
ną listę tych akcji można znaleźć w dokumentacji silni-
ka, np. tutaj: http://www.cocos2d-iphone.org/api-ref/
latest-stable/interface_c_c_action_interval.html.
Domyślnie akcje przypisane do węzła działają w spo-
sób równoległy. To znaczy, gdybyś przypisał do węzła
dwie akcje z identycznym interwałem: skalowanie i obrót,
to obydwie operacje wykonałyby się równocześnie. Cza-
sami jednak pożądane jest, aby pewne akcje wykonywały
się w trybie sekwencyjnym. W takiej sytuacji można sko-
rzystać z akcji CCSequence. Wyobraź sobie, że chciałbyś
zrealizować ruch duszka po kwadracie (punkty (50, 50),
(100, 50), (100, 100), (50, 100)), przy założeniu, że każ-
dy bok kwadratu będzie pokonany w przeciągu sekundy.
Zadanie to można zrealizować za pomocą akcji CCMoveTo
oraz CCSequence (patrz: Listing 7).
Listing 7. Ruch węzła po kwadracie zrealizowany za pomocą
akcji CCSequence
CCMoveTo* moveToP2 =
[CCMoveTo actionWithDuration:1
position:CGPointMake(100, 50)];
CCMoveTo* moveToP3 =
[CCMoveTo actionWithDuration:1
position:CGPointMake(100, 100)];
CCMoveTo* moveToP4 =
[CCMoveTo actionWithDuration:1
position:CGPointMake(50, 100)];
Rysunek 9. Hierarchia klas wywodzących się z CCEaseAction
(źródło: http://www.cocos2d-iphone.org/ )
BIBLIOTEKA COCOS2D: WPROWADZENIE
CCMoveTo* moveToP1 =
[CCMoveTo actionWithDuration:1
position:CGPointMake(50, 50)];
CCSequence* sequence =
[CCSequence actions:moveToP2,
moveToP3,
moveToP4,
moveToP1,
nil];
[sprite runAction:sequence];
Proste, nieprawdaż? Sekwencję taką możemy łatwo za-
pętlić, korzystając z akcji CCRepeatForever:
CCRepeatForever* repeatSequence =
[CCRepeatForever actionWithAction:sequence];
Równie łatwo możemy kontrolować szybkość całej se-
kwencji. W tym celu wykorzystamy akcję CCSpeed:
CCSpeed* speed =
[CCSpeed
actionWithAction: repeatSequence
speed:0.5f];
Mam nadzieję, że w tym momencie zaczynasz już zdawać
sobie sprawę, jak potężnym, użytecznym, a jednocześnie
łatwym w obsłudze mechanizmem są akcje. Ale to wcale
nie koniec ich możliwości!
Inna, ciekawa kategoria akcji to akcje wywodzące się
z klasy bazowej CCActionEase. Są to tzw. akcje łagodzące
(ang. easing actions). Mówiąc ogólnikowo, ich zadaniem
jest modyfikacja danego efektu w czasie. Jak to wygląda
w praktyce? Wyobraź sobie, że przesuwasz duszka za po-
/ www.programistamag.pl / 17
 BIBLIOTEKI I NARZĘDZIA

Rysunek 10. Hierarchia klas wywodzących się z CCGridAction

(źródło: http://www.cocos2d-iphone.org/ )

Rysunek 10. Hierarchia klas wywodzących się z CCGridAction

(źródło: http://www.cocos2d-iphone.org/ )

mocą akcji CCMoveTo. Zauważ, że ruch duszka jest rów- Listing 8. Modyfikacja charakterystyki ruchu węzła za pomo-
nomierny. Korzystając z akcji łagodzących, możesz wpły- cą akcji łagodzącej
wać na charakterystykę tego ruchu, np. możesz sprawić,
CCMoveTo* moveTo =
że na początku i na końcu ruchu duszek będzie poruszał [CCMoveTo actionWithDuration:5
się wolniej, tak aby sprawić wrażenie, że powoli nabiera position:CGPointMake(200, 200)];
prędkości ruszając z miejsca, a później wytraca ją, ha-
CCEaseInOut* ease =
mując. Korzystając z tego narzędzia, możesz sprawić, że
[CCEaseInOut
Twoje animacje będą bardziej dynamiczne i wygładzone. actionWithAction:move
Na Listingu 8 pokazane jest, w jaki sposób można użyć rate:4];
akcji łagodzącej w celu zmodyfikowania charakterystyki
[sprite runAction:ease];
ruchu węzła.

18 / 1 . 2012 . (1)  /

 BIBLIOTEKA COCOS2D: WPROWADZENIE

Zastosowanie akcji typu CCEaseInOut sprawi, że węzeł Listing 9. Ruch węzła po kwadracie zrealizowany za pomocą
będzie na początku ruchu powoli przyśpieszał, zaś przy akcji CCSequence, z wywoływaniem funkcji zwrotnej
jego końcu – łagodnie zwalniał. Oczywiście Cocos2D po-
CCMoveTo* moveToP2 =
siada w swoim arsenale cały szereg klas reprezentujących [CCMoveTo actionWithDuration:1
inne funkcje łagodzące. Hierarchia tych klas przedstawio- position:CGPointMake(100, 50)];
na jest na Rysunku 9. Szczegółowe informacje na temat
CCMoveTo* moveToP3 =
ich działania znajdują się w dokumentacji biblioteki:
[CCMoveTo actionWithDuration:1
http://www.cocos2d-iphone.org/wiki/doku.php/ position:CGPointMake(100, 100)];
prog_guide:actions_ease.
CCMoveTo* moveToP4 =
Kolejną kategorią akcji oferowaną przez prezentowany
[CCMoveTo actionWithDuration:1
silnik są tzw. akcje bazujące na siatce (ang. grid actions). position:CGPointMake(50, 100)];
Głównym zadaniem tych akcji jest dostarczenie miłych
dla oka efektów wizualnych o quasi-trójwymiarowym CCMoveTo* moveToP1 =
[CCMoveTo actionWithDuration:1
charakterze. Wszystkie akcje tego typu dziedziczą po kla- position:CGPointMake(50, 50)];
sie bazowej CCGridAction. Hierarchia tych klas pokaza-
na jest na Rysunku 10. Efekty te mają charakter pseudo CCCallFunc* callback =
[CCCallFunc actionWithTarget:self
3D, w ramach przykładu można tu wymienić efekt prze-
selector:@selector(onSequenceFinished)];
wrócenia kratki (CCPageTurn3D), efekt fali (CCWaves) czy
efekt płynu (CCLiquid). To, na co warto zwrócić uwagę, CCSequence* sequence =
[CCSequence actions:moveToP2,
to fakt, że efekty oparte na siatce będą działać jedynie
moveToP3,
wtedy, gdy nasza aplikacja będzie miała dostęp do bufora moveToP4,
głębokości (ang. depth buffer). W celu tego zapewnienia moveToP1,
należy ręcznie zmodyfikować kod odpowiadający za ini- nil];

cjację widoku OpenGL i zamienić w nim wartość parame- [sprite runAction:sequence];

tru depthFormat z 0 na GL_DEPTH_COMPONENT16_OES (bu-
for 16-bitowy) lub GL_DEPTH_COMPONENT24_OES (bufor
24-bitowy). Ceną za te efekty wizualne reprezentowane
przez akcje z rodziny CCGridAction jest oczywiście wy-
dajność (a co za tym idzie, również przenośność, bo gry
wykorzystujące intensywnie quasi-trójwymiarowe efekty
mogą nie działać poprawnie na starszych urządzeniach
z rodziny iOS).
Ostatnią kategorią akcji, którą chciałbym zaprezento-
wać, są tzw. akcje natychmiastowe (ang. instant actions).
Dziedziczą one po klasie bazowej CCActionInstant (na
Rysunku 11 przedstawiona jest hierarchia tych klas).
Akcje te pozwalają wykonywać na węzłach działania na-
tychmiastowe, np. ustawić pozycję, ukryć bądź odwrócić
według wybranej osi. Uważni Czytelnicy zadają sobie za-
pewne w tym momencie pytanie: po co nam tego typu
akcje? Przecież ten sam efekt można by uzyskać poprzez
zwyczajne zmodyfikowanie właściwości danego węzła. To
prawda, jednakże akcje natychmiastowe bywają bardzo
przydatne w sytuacji, kiedy używamy sekwencji. Łatwo
wyobrazić sobie sytuację, gdy chcielibyśmy użyć tego
typu akacji, jako część łańcuchu zdarzeń reprezentowane-
go przez obiekty typu CCSequence. W tej sytuacji ręczne
ustawianie właściwości węzła na nic się nam nie przyda.
Rozważając akcje natychmiastowe, warto wspomnieć
o akcji typu CCCallFunc. Akcja ta pozwala wywołać do-
wolną funkcję, przekazaną do niej za pomocą selektora.
Bywa to bardzo przydatne przy pracy z sekwencjami, cho-
ciażby po to, aby wywoływać funkcje zwrotne w kluczo-
wych momentach ich działania. Na Listingu 9 przedsta-
wiony jest zmodyfikowany przykład z Listingu 7. Różnica
polega na tym, że za każdym razem, kiedy nasz węzeł
„zatoczy” pełen kwadrat, to wywołana będzie określona
funkcja zwrotna.
// ...
-(void) onSequenceFinished
{
CCLOG(@"Sequence finished!");
}
Oprócz klasy CCCallFunc Cocos2D oferuje kilka dodatko-
wych wariantów akcji służącej do wywoływania funkcji:
CCCallFuncN, CCCallFunc0 oraz CCCallFuncND. Klasy
te mają to do siebie, iż za ich pomocą do funkcji zwrotnej
można przekazać kontekst w postaci różnego rodzaju pa-
rametrów. Szczegóły działania tych klas opisane są w do-
kumentacji biblioteki.
CO NAS OMINĘŁO?
Na akcjach zakończę opisywanie właściwości biblioteki.
Nie myśl jednak, że temat został wyczerpany. Cocos2D
oferuje dużo więcej możliwości, po prostu opisanie ich
wszystkich jest niemożliwe ze względu na ograniczoną
ilość miejsca przeznaczoną na niniejszy artykuł. Poniżej
przedstawiam listę wybranych elementów funkcjonal-
ności oferowanej przez Cocos2D, których nie udało mi
się tu opisać, a na które zdecydowanie warto zwrócić
uwagę:
■■ odgrywanie muzyki i efektów dźwiękowych: podsumo-
wując w dwóch słowach – jest i działa,
■■ obsługa map kafelków (zarówno ortogonalnych, jak
i izometrycznych) oraz integracja z narzędziem Ti-
led: bardzo interesujący, aczkolwiek obszerny temat;
sprawna obsługa map kafelków to w opinii wielu pro-
gramistów gier jedna z mocniejszych zalet Cocosa,

/ www.programistamag.pl / 19
 BIBLIOTEKI I NARZĘDZIA
■■ integracja z sinikami symulacji fizycznych (Box2D
i Chipmunk),
■■ kompleksowe narzędzia wspomagające pracę z Co-
cos2D, np. CocosBuilder (http://cocosbuilder.com/),
LevelHelper (http://www.levelhelper.org/) czy Sprite-
Helper (http://www.spritehelper.org/).
Informacje na temat wymienionych tu (a także wielu in-
nych tematów) związanych z biblioteką Cocos2D znaleźć
możesz między innymi w materiałach, które przedstawi-
łem w przedostatnim podpunkcie tego tekstu.
CO DALEJ?
Nasza wspólna podróż po świecie Cocosa powoli się koń-
czy. Mam nadzieję, że koniec niniejszego artykułu bę-
dzie dopiero początkiem Twojej przygody z biblioteką
Cocos2D! Pamiętasz, jak we wstępnie pisałem, że jed-
ną z silnych stron tego rozwiązania jest dostęp do dużej
ilości wysokiej jakości materiałów edukacyjnych? Jeśli
po przestudiowaniu niniejszego tekstu czujesz niedosyt
wiedzy (efekt jak najbardziej pożądany!), to na koniec
chciałbym wskazać Ci kilka ciekawych miejsc w sieci oraz
książek, które pomogą Ci lepiej zapoznać się z Cocosem:
■■ http://www.cocos2d-iphone.org: strona domowa bi-
blioteki; tutaj warto na bieżąco sprawdzać, co się dzieje
w świecie Cocosa; zajdziesz tu najważniejsze nowinki
na temat biblioteki oraz szereg innych ciekawych infor-
macji (szczególnie budujące są wiadomości o kolejnych
zbudowanych na bazie Cocosa tytułch, które odniosły
spektakularny sukces na AppStore); tutaj znajdziesz
również obszerną dokumetację techniczną biblioteki,
■■ http://www.raywenderlich.com/: blog techniczny, na
którym publikowane są na bieżąco samouczki adre-
sowane do programistów aplikacji na platformę iOS;
duża część z tych samouczków poświęcona jest wła-
śnie Cocosowi; zarówno ilość, jak i jakość prezentowa-
nych tam materiałów robi wrażenie,
■■ http://www.learn-cocos2d.com/: strona prowadzona
przez Steffena Itterheima, współautora książki Learn
Cocos2D; można tu znaleźć szereg interesujących ar-
tykułów na temat Cocosa; Steffen jest również auto-
rem bardzo ciekawego silnika Kobold2D, stanowiącego
rozszerzenie Cocosa,
■■ Learning Cocos2D, Addison Wesley, 2011: książka au-
torstwa Roda Strougo oraz Ray'a Wenderlicha; świetne
wprowadzenie do Cocosa, pokazane na przykładzie stwo-
Rafał Kocisz
Rafał od dziesięciu lat pracuje w branży związanej z produkcją oprogramowania. Jego za-
wodowe zainteresowania skupiają się przede wszystkim na nowoczesnych technologiach
mobilnych oraz na programowaniu gier. Rafał pracuje aktualnie jako Techniczny Koordy-
nator Projektu w firmie BLStream.
20 / 1 . 2012 . (1)  /
rzenia pełnej gry; zawiera również spory zastrzyk wiedzy
na temat bibliotek fizycznych Box2D oraz Chipmunk,
■■ Learn Cocos2D Game Development With iOS 5, Apress,
2011; książka autorstwa Steffena Itterheima oraz An-
dreasa Löwa; kolejne świetne wprowadzenie w temat
Cocosa; dużo informacji na temat narzędzi wspoma-
gających (między innymi wymienionych w niniejszym
artykule),
■■ Cocos2d for iPhone 1 Game Development Cookbook,
Packt Publishing, 2011; książka autorstwa Nathana
Burby zorganizowana jako zestaw praktycznych po-
rad i rozwiązań zadań związanych z programowaniem
gier w oparciu o silnik Cocos2D; mocną stroną tej po-
zycji jest fakt, iż zahacza ona również o zagadnienia
zaawansowane,
■■ http://cocoadevcentral.com/d/learn_objectivec/: bar-
dzo przystępny (a zarazem krótki) samouczek pre-
zentujący najważniejsze aspekty języka Objective-C;
jeśli nie miałeś wcześniej do czynienia z tym językiem,
a masz już doświadczenia z innymi językami obiekto-
wymi, zacznij naukę od przeczytania tego dokumentu,
■■ Programming in Objective-C, 4th Edition, Addison-We-
sley, 2011: książka autorstwa Stephena G. Kochana
traktująca o języku Objective-C; jeśli zajdzie potrzeba,
abyś poznał tajniki natywnego języka systemu iOS, ta
książka będzie świetnym przewodnikiem.
Miej świadomość, że powyższa lista przedstawia moje ulu-
bione materiały edukacyjne związane z Cocosem i Objec-
tive-C. Nie poprzestawaj na niej. Cocos2D to biblioteka,
która żyje. Nowe samouczki powstają z dnia na dzień;
nowe książki się piszą. Nie bój się zatem korzystać z wy-
szukiwarki; jest szansa, że jeśli nie dziś, to jutro znajdziesz
interesujące Cię informacje. Zachęcam również do ak-
tywnego korzystania z forum dyskusyjnego biblioteki do-
stępnego pod adresem http://www.cocos2d-iphone.org/
forum/. Na pewno też możesz się spodziewać kolejnych
artykułów traktujących o Cocosie na łamach Programisty.
PODSUMOWANIE
Czytając niniejszy artykuł, zaznajomiłeś się z podstawo-
wymi koncepcjami, na których opiera się Cocos2D, po-
znałeś również zakres jego możliwości, mam nadzieję,
że co najmniej na tyle, aby odpowiedzieć sobie na py-
tanie o przydatność tej biblioteki przy realizacji Twoich
własnych przedsięwzięć. Realizacji tych ostatnich życzę
Ci z całego serca!
rafal.kocisz@gmail.com
 ZONE

NOWY WYMIAR E-EDUKACJI

TEMATY SZKOLEŃ DLA PROGRAMISTÓW!
STACJONARNYCH

Ł A C A J
TRENERZY SZKOLEŃ
STACJONARNYCH NIE PRZEP N I A
Z K O L E
ZA S Z N E!
A M IS T Y C
PR O G R

95% CENY SZKOLEŃ

STACJONARNYCH

OFERTA SZKOLEŃ

Język Objective-C 2.0 i tworzenie aplikacji dla iPhone'a

Refaktoryzacja kodu w języku PHP
Tworzenie aplikacji internetowych z użyciem platformy .NET
Tworzenie aplikacji internetowych z wykorzystaniem Ruby on Rails
Tworzenie aplikacji z użyciem biblioteki Hibernate
Tworzenie aplikacji z użyciem EJB3
Wprowadzenie do C# i platformy .NET
Wprowadzenie do technologii Flex
Zaawansowane wykorzystanie typów generycznych w języku Java

CO MIESIĄC DWA NOWE SZKOLENIA!

w w w. d e v c a s t z o n e . c o m
 JĘZYKI PROGRAMOWANIA
C++11 - część I
C++11 to nowy standard języka C++, zatwierdzony przez komitet ISO 12 sierpnia
2011 roku. Ponieważ zawiera on dużo zmian i nowości, zarówno po stronie samego
języka, jak i biblioteki standardowej, warto się z nimi zapoznać już teraz.
J
ęzyk C++ od lat zajmuje czołowe pozycje na listach
popularności języków programowania. Trudno się
temu dziwić, gdyż łączy on możliwości tworzenia roz-
budowanych abstrakcji, charakterystycznych dla języków
wysokiego poziomu, z wydajnością języków niskopozio-
mowych. Ponad pół roku temu w końcu miało miejsce
wydarzenie, na które programiści C++ czekali od wielu
lat - został ogłoszony nowy standard języka, nazywany
potocznie C++11. Nowy standard niesie ze sobą dużo
zmian. Wprowadzono wiele nowych mechanizmów, takich
jak na przykład wątki czy wyrażenia lambda. Poszerza
także zakres stosowalności i ogólności znanych już me-
chanizmów, takich jak na przykład szablony czy tworze-
nie skróconych nazw dla typów.
Duża część mechanizmów C++11 została przedstawio-
na w cyklu artykułów C++0x (w chwili pisania części z nich
standard nie był jeszcze zatwierdzony), opublikowanych
na łamach czasopisma Software Developer`s Journal, w
drugiej połowie 2011 r. oraz na początku 2012 r. Niniejszy
cykl jest kontynuacją prezentacji Nowej Twarzy C++. Au-
torzy zalecają zapoznanie się z materiałami dotyczącymi
C++11, w szczególności referencjami do r-wartości (ang.
rvalue reference), odwołania do których pojawiają się
w niniejszym tekście. Ułatwi to zrozumienie tekstu i od-
krycie nowych możliwości zastosowań prezentowanych
mechanizmów.
Z założenia cykl ten ma prezentować praktyczne zasto-
sowania, nie zaś suchą teorię. Dlatego, spośród licznych
rozszerzeń, zarówno samego języka, jak i jego biblioteki
standardowej, wybór autorów pada na elementy dostęp-
ne i wspierane przez istniejące kompilatory. W chwili pi-
sania tych słów zdecydowanie najlepsze wsparcie, wśród
kompilatorów, z jakimi autorzy mieli styczność, ma GCC.
Kompilowanie przykładów
Do kompilowania przykładów należy użyć kompilato­
ra GCC w wersji 4.6, ustawiając standard języka na C++0x:
g++-4.6 -Wall -std=c++0x src.cpp
Większość prezentowanych fragmentów kodu NIE będzie
działać na starszych wersjach, które miały minimalne lub
żadne wsparcie dla C++0x. W przypadku nowszych wersji
GCC niektóre przykłady mogą wymagać drobnych modyfi­
kacji. Pamiętajmy, że w chwili wydania GCC 4.6 C++0x nie
był zatwierdzonym standardem. Oprócz tego GCC nie jest
jeszcze w pełni zgodny z propozycją standardu języka.
22 / 1 . 2012 . (1)  /
Bartosz Szurgot, Mariusz Uchroński, Wojciech Waga
Dodatkowo fakt jego dostępności, zarówno dla platformy
Linux, jak i Windows oraz możliwość darmowego stoso-
wania, czyni z niego niemal idealnego kandydata do two-
rzenia przykładów.
Po ostatniej konferencji C++ and Beyond, podczas wy-
wiadu Herb Sutter został zapytany, kiedy, jego zdaniem,
większość kompilatorów będzie wspierać nowy standard.
Odpowiedział, że prawdopodobnie za około rok. Dla mniej
popularnych platform - około dwóch lat. By nie czekać tak
długo, zapraszamy do poznawania elementów C++11,
oferowanych przez GCC, już dziś. Zatem do dzieła...
GENERACJA LICZB
PSEUDOLOSOWYCH
Na początku należy uświadomić czytelnikowi, że progra-
mowe generatory liczb losowych tak naprawdę nie gene-
rują prawdziwych liczb losowych, dlatego nazywane są
generatorami liczb pseudolosowych (ang. PRNG - Pseu-
do Random Number Generator). Generatory programo-
we oparte są na formułach matematycznych, które dają
wrażenie losowości. Oprócz generatorów programowych
istnieją także sprzętowe generatory liczb losowych (ang.
TRNG - True Random Number Generator), których dzia-
łanie jest oparte na zasadzie obrazowania właściwości
i parametrów fizycznego procesu stochastycznego, naj-
częściej szumu elektrycznego. Programowe generowanie
liczb pseudolosowych, o wysokich parametrach, jest więc
dość skomplikowanym problemem.
Przed pojawieniem się standardu C++11 istniał tylko
jeden sposób na generację liczb pseudolosowych w C++.
Mowa tutaj o użyciu funkcji srand() oraz rand(), z bi-
blioteki C. W celu inicjalizacji generatora liczb pseudolo-
sowych należało jednarazowo wywołać funkcję srand().
Jako parametr do tej funkcji należy przekazać liczbę typu
unsigned int tzw. seed. Należy zwrócić szczególną uwa-
gę na wartość seeda, ponieważ w przypadku, gdy wartość
ta będzie stałą, to przy każdym uruchomieniu programu
ciąg wygenerowanych liczb pseudolosowych będzie taki
sam. Z tego powodu jako wartość seed podawany jest
bieżący czas systemowy. Po zainicjalizowaniu generatora
liczby pseudolosowe można generować przy użyciu funk-
cji rand(). Na Listingu 1a zostało przedstawione użycie
funkcji srand() do inicjalizacji generatora liczb pseudo-
losowych wartością bieżącego czasu systemowego oraz
użycie funkcji rand() do generacji liczb pseudolosowych.
Wywołanie funkcji time(nullptr) pozwala na uzyskanie
bieżącego czasu systemowego.

Listing 1a. Przykład inicjalizacji i użycia generatora liczb
losowych w starym stylu
int randBetween(const int &min, const int &max)
{ jest w postaci pojedynczej liczby całkowitej, zawierają-
return (rand() % (static_cast<int>(max - min +
1)) + min);
}
const int min = 1;
const int max = 10;
srand(static_cast<unsigned int>(time(nullptr)));
cout << rand() << endl;
cout << randBetween(min, max) << end
Funkcja rand() pozwala na generację liczb pseudoloso-
wych z zakresu od 0 do RAND_MAX. Standard określa war-
tość RAND_MAX na wartość co najmniej 32767. Niestety
często wartości najmłodszych bitów dla liczb generowa-
nych przez funkcję rand() są mało losowe. Oznacza to,
że użycie funkcji randBetween(...) do generacji liczb
z małego zakresu (np. [1,5]) skutkuje niezbyt wysoką
losowością wygenerowanych liczb. Warto zwrócić uwagę
na fakt, że funkcje srand() oraz rand() nie pozwalają
na zmianę rozkładu prawdopodobieństwa generowanych
liczb pseudolosowych.
Dlatego standard C++11 został wzbogacony o rozbu-
dowaną bibliotekę do generacji liczb pseudolosowych, o
różnych rozkładach prawdopodobieństwa, z wykorzysta-
niem różnych algorytmów. Biblioteka ta została zdefinio-
wana w pliku nagłówkowym random.
Standard C++11 definiuje następujące klasy i szablo-
ny generatorów liczb pseudolosowych:
■■ random_device,
■■ linear_congruential_engine,
■■ mersenne_twister_engine,
■■ subtract_with_carry_engine.
Klasa random_device nie jest programowym generato-
rem liczb pseudolosowych, wymaga on specjalnego sprzę-
tu pozwalającego wygenerować niedeterministyczne licz-
by losowe. Zgodnie z definicją szablonu random_device,
jeżeli komputer nie jest wyposażony w sprzętowy ge-
nerator liczb losowych, to biblioteka wykorzysta jeden
z generatorów programowych (wykorzystanie konkret-
nego generatora zależy od implementacji biblioteki). Ja-
kość liczb pseudolosowych wygenerowanych z użyciem
szablonu random_device związana jest z jego entropią,
której wartość można uzyskać poprzez wywołanie funkcji
entropy(). Jeśli funkcja entropy() zwróci wartość 0, to
oznacza to, że do generacji liczb pseudolosowych został
wygenerowany generator programowy. Użycie szablonu
random_device został przedstawiony na Listingu 1b.
Listing 1b. Genaracja liczb pseudolosowych przy użyciu
srand( )/rand( )
random_device rnd;
cout << "Entropia: " << rnd.entropy() << endl;
cout << "Wartość minimalna: " << rnd.min()
<< " wartość maksymalna: " << rnd.max() << endl;
cout << "Liczba pseudolosowa: " << rnd() << endl;
C++11 CZĘŚĆ I
Szablon linear_congruential_engine wymaga mini-
malnej ilości pamięci do przechowywania swojego stanu.
Stan generatora opartego o ten szablon przechowywany
cej poprzednio wygenerowaną liczbę pseudolosową, lub
początkowy seed, jeżeli żadna liczba pseudolosowa nie
została jeszcze wygenerowana. Okres takiego generatora
zależy od użytych parametrów algorytmu i może wynosić
do 264, ale najczęściej jest mniejszy. Z tego powodu ge-
neratory oparte o szablon linear_congruential_engine
nie generują liczb pseudolosowych o dużej losowości.
Szablon mersenne_twister_engine pozwala na ge-
nerację liczb pseudolosowych o największej losowości,
a okres generowanych liczb jest dużo większy niż dla sza-
blonu linear_congruential_engine. Rozmiar pamięci
potrzebny do przechowywania stanu generatora opartego
o szablon mersenne_twister_engine zależy od wartości
użytych parametrów i jest dużo większy niż w przypad-
ku szablonu linear_congruential_engine. Na przykład
predefiniowany generator mt19937, oparty o szablon
mersenne_twister_engine, ma okres generowanych
liczb pseudolosowych równy 219937-1, podczas gdy jego
stan przechowywany jest na 624 liczbach całkowitych,
czyli w około 2.5kB pamięci.
Szablon subtract_with_carry_engine przechowu-
je stan generatora na 25 liczbach całkowitych (na oko-
ło 100B pamięci). Jakość liczb pseudolosowych genero-
wanych przez generator, oparty na tym szablonie, jest
jednak gorsza, niż dla generatora opartego o szablon
mersenne_twister_engine.
Klasa random_device jest prosta w użyciu i nie wy-
maga żadnych parametrów. Natomiast utworzenie ge-
neratora liczb pseudolosowych w oparciu o pozosta-
łe szablony wymaga podania wielu parametrów, które
mogą być skomplikowane. Dobór parametrów ma
wpływ na jakość generowanych liczb pseudolosowych.
Na przykład szablon mersenne_twister_engine wy-
maga zdefiniowania 14 parametrów. Podobnie szablony
linear_congruential_engine oraz subtract_with_
carry_engine wymagają podania dużej liczby parame-
trów w celu zdefiniowania konkretnego generatora. Dla-
tego standard zawiera predefiniowane generatory liczb
pseudolosowych. Są to:
■■ minstd_rand0,
■■ minstd_rand,
■■ mt19937,
■■ mt19937_64,
■■ ranlux24_base,
■■ ranlux48_base.
Aby wygenerować liczbę pseudolosową w C++11, należy
utworzyć instancję generatora liczb pseudolosowych oraz
dla generatorów programowych określić rozkład prawdo-
podobieństwa. Najprostszą metodą utworzenia generatora
liczb pseudolosowych jest wykorzystanie jednego z pre-
definiowanych generatorów. W Listingu 1c został wyko-
rzystany predefiniowany generator liczb pseudolosowych
/ www.programistamag.pl / 23
 JĘZYKI PROGRAMOWANIA

mt19937, oparty o szablon mersenne_twister_engine. Lista zawiera najczęściej spotykane w statystyce rozkła-
Podobnie, jak w przypadku generacji liczb pseudolosowych dy. Programista otrzymuje więc zestaw gotowych narzę-
z wykorzystaniem funkcji srand() i rand(), należy za- dzi do pracy z liczbami losowymi!
inicjalizować generator. W przykładzie generator mt19937 Jako przykład niech posłuży kod z Listingu 1e, służący
został zainicjalizowany wartością bieżącego czasu syste- do generacji miliona liczb losowych o rozkładzie normal-
mowego. Następnie został zdefiniowany rozkład prawdopo- nym, wartości oczekiwanej równej 50 oraz wariancji rów-
dobieństwa, w tym przypadku jest to rozkład jednostajny o nej 6. Jako generator liczb pseudolosowych użyty został
zakresie od 1 do 99. W celu wygenerowania liczby pseudo- typ mt19937. Wektor mn przechowuje liczbę wystąpień
losowej należy wywołać obiekt funkcyjny, zdefiniowanego liczb z zakresu od 1 do 100. Następnie na ekran wypisy-
wcześniej rozkładu prawdopodobieństwa, jako argument wana jest zawartość owego wektora.
podając instancję generatora liczb pseudolosowych.
Listing 1e. Przykład generowania liczb pseudolosowych o
Listing 1c. Przykład generowania liczby pseudolosowej, o rozkładzie normalnym
rozkładzie jednostajnym
#include <random>
mt19937 eng(static_cast<unsigned #include <functional>
long>(time(nullptr))); #include <iostream>
uniform_int_distribution<int> dist(1, 99); using namespace std;
cout << dist(eng) << endl; int main(void)
{
const int max = 100;
Istnieje możliwość wyeliminowania konieczności określa- // liczba losowań
const int it = 1000000;
nia generatora liczb pseudolosowych i rozkładu prawdopo-
// określenie rozkładu prawdopodobieństwa
dobieństwa w momencie generacji liczby pseudolosowej. normal_distribution<double> normal(50.0, 6.0);
Efekt taki można uzyskać poprzez użycie szablonu bind(), // utworzenie instancji generatora liczb
zdefiniowanego w pliku nagłówkowym functional. Przy- // pseudolosowych
mt19937 enginei(static_cast<unsigned
kład użycia funkcji bind(), w kontekście generacji liczb long>(time(nullptr)));
pseudolosowych, został przedstawiony na Listingu 1d. // 'zbindowanie' generatora z rozkładem
// prawdopodobieństwa
auto rndi = bind(normal, enginei);
Listing 1d. Użycie funkcji bind(...) w kontekście generowania
// wektor przechowujący informację o częstości
liczb pseudolosowych
// występowania losowanych liczb
vector<int> mn(max+1);
mt19937 eng(static_cast<unsigned // generacja liczb pseudolosowych
long>(time(nullptr))); for (unsigned int i = 0; i<it; ++i)
uniform_int_distribution<int> dist(1, 99); ++mn.at(rndi());
auto gen = bind(dist, eng); //
cout << gen << endl; for (int i = 1; i<mn.size(); ++i)
cout << i << " " << mn[i] << endl;
return 0;
W standarcie C++11 zostały zdefiniowane różne rozkłady }
prawdopodobieństwa:
Aby lepiej unaocznić rozkłady prawdopodobieństwa, war-
■■ uniform_int_distribution, to się przyjrzeć jego graficznej reprezentacji, dla różnych
■■ uniform_real_distribution, zestawów parametrów. Na Rysunku 1a przedstawiony zo-
■■ bernoulli_distribution, stał przykład rozkładu jednostajnego. Rysunek 1b przed-
■■ binomial_distribution, stawia rozkład normalny, znany także pod nazwą rozkła-
■■ geometric_distribution, du Gaussa. Wykładniczy rozkład prawdopodobieństwa
■■ negative_binomial_distribution, ilustruje Rysunek 1c.
■■ poisson_distribution, Wartym uwagi jest fakt, iż C++11, wymuszając jawne
■■ exponential_distribution, tworzenie generatorów liczb pseudolosowych, rozwiązu-
■■ gamma_distribution, je jednocześnie dwa problemy, spotykane w wielu ge-
■■ weibull_distribution, neratorach (także niektórych z biblioteki C). Pierwszym,
■■ extreme_value_distribution, dość oczywistym, jest rozdzielenie samego generatora
■■ normal_distribution, (rozumianego jako ,,źródło pseudolosowości'') od kodu
■■ lognormal_distribution, generującego pożądany rozkład generowanych liczb. Ta-
■■ chi_squared_distribution, kie podejście jest znaczącą poprawą architektury, zwięk-
■■ cauchy_distribution, szającym elastyczność i umożliwiającym proste tworze-
■■ fisher_f_distribution, nie własnych rozkładów, w miarę potrzeb. Drugą istotną
■■ student_t_distribution, korzyścią jest możliwość tworzenia osobnych (tj. nieza-
■■ discrete_distributio, leżnych) generatorów w różnych wątkach. Programiści
■■ piecewise_constant_distribution, tworzący aplikacje obliczeniowe, korzystające z PRNG
■■ piecewise_linear_distribution. i wątkowania, często spotykali się z problemem niejawnej

24 / 1 . 2012 . (1)  /

 C++11 CZĘŚĆ I

Rysunek 1a. Jednostajny rozkład prawdopodobieństwa Rysunek 1b. Normalny rozkład prawdopodobieństwa

serializacji wykonania, na funkcjach zwracających liczby

pseudolosowe. Działo się tak, ponieważ niektóre z gene-
ratorów posiadały wewnętrzne blokady, zabezpieczające
przed wyścigiem podczas odczytu/zapisu stanu generato-
ra. Podczas częstego dostępu z wielu wątków, okazywało
się to być wąskim gardłem dla czasu wykonania, zabija-
jąc tym samym równoległość. W C++11 problem ten nie
istnieje - każdy wątek może posiadać własny generator,
nie blokujący pozostałych.
Kończąc wywód o generacji liczb pseudolosowych, nie
sposób pominąć kwestii doboru początkowej wartości
seed, dla generatorów. W powyższych przykładach, dla
uproszczenia, użyty był bieżący czas systemowy. Jest to
jak najbardziej poprawne, jednak trzeba mieć świado-
mość konsekwencji takiego postępowania. Weźmy przy-
kład z dziedziny bezpieczeństwa systemów IT. Załóżmy,
że mamy potrzebę wygenerowania jednorazowego, loso- Rysunek 1c. Wykładniczy rozkład prawdopodobieństwa
wego numeru sesji, przypisanego do konkretnego użyt-
kownika WWW, zaraz po zalogowaniu. Tworzymy więc się powtarzać, a ludzie są tylko ludźmi, podobne błędy
program, używamy najlepszego generatora liczb pseudo- nadal nie należą do rzadkości. Warto więc być świado-
losowych, inicjujemy go czasem systemowym, wybieramy mym, jak ogromny wpływ na jakość ciągu wyjściowego
rozkład jednostajny... Program jest gotowy, a my cieszy- ma wartość początkowa. Robert R. Coveyou (matematyk)
my się poziomem bezpieczeństwa... Ale czy na pewno? powiedział kiedyś: generowanie liczb losowych jest zbyt
Pamiętajmy, że ciągi pseudolosowe są w 100% determi- ważne, by pozostawić je przypadkowi. Dobrze o tym pa-
nistyczne. Jeśli więc ktoś będzie miał taki sam generator, miętać, kiedy i nam przyjdzie taka potrzeba.
zainicjowany taką samą wartością początkową, uzyska
identyczny ciąg wartości z generatora. Teraz wystarczy, ALTERNATYWNA SKŁADNIA FUNKCJI
że wiemy, około której godziny użytkownik zainicjował
sesję, by odgadnąć jego numer sesji! Jak? Jeśli wiemy, Standard C++11 definiuje nową, dodatkową składnię
że zalogowanie miało miejsce w przeciągu ostatniej go- funkcji. Przykładowa funkcja zapisana w tym formacie
dziny, mamy raptem 3600 możliwych kluczy sesyjnych znajduje się na Listingu 2a.
do sprawdzenia. Co więcej, jeśli 2 użytkowników zaloguje
się w tej samej sekundzie, dostaną identyczny numer! Listing 2a. Alternatywna składnia funkcji
Powyższy przykład nie jest bynajmniej akademicki.
Pod koniec lat '90 dokładnie taką podatność miał silnik auto sum(int x, int y) -> int
{
kryptograficzny, używany do generowania kluczy do szy-
return x+y;
frowania transmisji, w przeglądarce Mozilla. Nie pomógł
}
nawet fakt, że czas był pobierany z dokładnością milise-
kundową. Odnosząc się do naszego przypadku, zamiast
3600 prób potrzeba 3600000, co nie stanowi najmniej- Warto zwrócić uwagę, że słowo kluczowe auto nie ma
szego problemu dla komputerów. Ponieważ historia lubi tu nic wspólnego z automatycznym określaniem typu

/ www.programistamag.pl / 25
 JĘZYKI PROGRAMOWANIA
zwracanego. Typ ten jest jawnie podany jako tak zwa-
ny trailing-return-type. Listing 2b pokazuje bardziej
użyteczne zastosowanie nowej składni, którego nie dało-
by się zapisać inaczej.
Listing 2b. Alternatywna składnia funkcji
template<class A, class B>
auto sum(const A &a, const B &b) -> decltype(a+b)
{ 2 wydaje się być pozbawione tych problemów, jest jednak
return x+y;
} cji nie zadeklaruje value_type jako typu elementu swo-
Tutaj wartość zwracana ustalana jest za pomocą opera-
tora decltype opisanego w kolejnym punkcie. Operator
ten nie może stać przed nazwą funkcji, gdzie znajduje się
typ w klasycznej deklaracji, gdyż tam zmienne a i b nie
są jeszcze znane.
Mimo swojej zwięzłości, przykład z Listingu 2b nie ob-
razuje wcale trywialnej sytuacji. Typy szablonowe A oraz
B mogą być różne, co wyklucza podanie jednego z nich
jako wartości zwracanej. Dodatkowo może być zdefinio-
wany operator dodawania dla tychże dwóch typów, zwra-
cający wartość zupełnie innego typu niż A lub B.
DECLTYPE
Wraz z upowszechnieniem się programowania generycz-
nego w latach dziewięćdziesiątych pojawił się problem
określania typu podanych wyrażeń. Typ z kolei jest nie-
zbędny do deklarowania zmiennych oraz funkcji. Jest to
dość intuicyjne wymaganie, jeżeli popatrzymy z perspek-
tywy kompilatora, który chce obliczyć, ile pamięci potrze-
ba na obiekt danego typu. Liczba typu int, double czy
obiekt klasy reprezentującej produkt magazynowany wy-
magają różnych ilości pamięci.
Przykładowy kod prezentujący powyższy problem jest
zlokalizowany w Listingu 3a. Funkcja swap ma za zadanie
zamienić pierwszy element podanej kolekcji z ostatnim.
Nie jest to jak widać szczególnie wyszukany problem, ale
jego rozwiązanie jest już na pewno kłopotliwe, ponie-
waż musimy zadeklarować typ zmiennej temp, który jest
oczywiście taki sam, jak typ elementu danej kolekcji, ale
tego nie znamy.
Listing 3a. Zamiana dwóch zmiennych dowolnego typu
template <class T>
void swap(const T& v)
{ wyższym przykładzie można również wykorzystać nowe
TYPE temp=*v.begin();
*v.begin()=*v.rbegin();
*v.rbegin()=temp;
}
Problem ten można jednak obejść, nie wykorzystując
mechanizmów C++11 na kilka różnych sposobów, każdy
jednak jest daleki od ideału. Kilka rozwiązań Czytelnik
znajdzie na Listingu 3b. Funkcja swap1 wykorzystuje po-
mocniczy szablon real_swap. Podczas konkretyzowania
tego szablonu tworzona jest funkcja, która bierze kon-
26 / 1 . 2012 . (1)  /
kretny już typ argumentów ustalony w czasie kompilacji.
Rozwiązanie to jest bardzo elastyczne, gdyż pozwala na
stworzenie pomocniczego szablonu, który „wyekstrahuje“
np. typ argumentu podanej funkcji. Wadą tego rozwią-
zania jest to, że jest mało czytelne, nie ma możliwości
przekazania ustalonego typu poza pomocniczą funkcję
szablonową, a do tego wywołanie wymusza ewaluację
wyrażenia, co nie zawsze jest pożądane. Rozwiązanie nr
uzależnione od konwencji kodowania. I jeżeli autor kolek-
jej kolekcji, metoda ta nie zadziała. Rozwiązanie nr 3 jest
mniej elastyczne niż pierwsze, bo nie pozwoli już określić
typu argumentu funkcji. Jest ono również nieprzenośne,
ponieważ korzysta z rozszerzenia kompilatora. Wymaga
także napisania wyrażenia dwa razy, co z kolei utrudnia
utrzymywanie kodu.
Listing 3b. Operacje na kolekcji elementów dowolnego typu
template<class T>
void real_swap(T &x, T &y)
{
T temp=x;
x=y;
y=temp;
}
template <class T>
void swap1(T& v)
{
real_swap(*v.begin(),*v.rbegin());
}
template <class T>
void swap2(T& v)
{
typename T::value_type temp=*v.begin();
*v.begin()=*v.rbegin();
*v.rbegin()=temp;
}
template <class T>
void swap3(T& v)
{
typeof(*v.begin()) temp=*v.begin();
*v.begin()=*v.rbegin();
*v.rbegin()=temp;
}
C++11 przyniósł nowy mechanizm pozwalający na unik-
nięcie tego typu problemów - operator decltype (w po-
słowo kluczowe auto). Powodem, dla którego operator
został nazwany decltype, a nie typeof, było uniknięcie
pewnych nieścisłości w przypadku referencji. Decltype
znaczy tyle co "declared type", czyli typ zadeklarowany.
Listing 3c przedstawia dwie funkcje foo() i bar() zwra-
cające odpowiednio int i referencję do int. Typ wyraże-
nia foo() to oczywiście int, ale typ wyrażenia bar() to
też int, który przypisywany jest do zmiennej w dokład-
nie taki sam sposób. Decltype ma za zadanie rozróżnić
typ tych wyrażeń.

Listing 3c. Wyrażenia różnych typów
int foo();
int &bar();
int x=foo();
int y=bar();
Reguły określania decltype są następujące:
1. Jeżeli e jest zmienną lub nazwą pola klasy, decltype(e)
zwraca typ, z którym e zostało zadeklarowane. Jeżeli
e jest referencją do typu, decltype(e) jest również
referencją do typu.
2. Jeżeli e jest złożonym wyrażeniem, decltype(e) zwróci
typ, który zwróciłoby wyliczenie tego wyrażenia. Dodat-
kowo jeżeli wyrażenie zwróciłoby lvalue decltype(e)
zwraca referencję do typu.
Listing 3d pokazuje kilka przykładów.
Listing 3d. Przykłady decltype
const int&& foo();
int i;
double x;
decltype(foo()) x1; // const int&&
decltype(i) x2; // int
decltype(x) x3; // double
decltype((x)) x4; // const double&
To, co może wydawać się mało intuicyjne, to różnica w ty-
pie zmiennych x3 i x4. Wynika ona bezpośrednio z reguł
decltype: x jest nazwą zmiennej, zatem zastosowanie
ma pkt. 1, lecz (x) jest wyrażeniem złożonym zwracają-
cym lvalue, zatem zastosowanie ma pkt. 2.
Czyżby to było jedyne miejsce w C++, gdzie podwójne
nawiasy działają inaczej niż pojedyncze? Nie. Dołożenie
dodatkowych nawiasów przy wywołaniu funkcji wieloar-
gumentowej robi jeszcze więcej zamieszania, bo zmienia
znaczenie przecinka rozdzielającego argumenty od siebie.
Śledząc kolejne propozycje definicji decltype'a, roz-
patrywane przez członków komitetu standaryzacyjne-
go, możemy zauważyć, że autorzy rozszerzenia też
mieli wątpliwości. Na przykład dokument N1607 nie
określa jasno tego przypadku, z kolei N1705 podaje,
że decltype((e))==decltype(e) co, jak wiemy, nie
jest już prawdą.
By pokazać elastyczność decltype, Listing 3e przedsta-
wia zmienioną wersję kodu, z Listingu 3a, wywołującą ope-
rator + dla dwóch argumentów, która wykorzystuje mecha-
nizm idealnego przekazywania (ang. perfect forwarding).
Listing 3e. Przekazywanie parametrów wywołania w połą-
czeniu z decltype
template<typename F1, typename F2>
auto add(F1&& f1, F2&& f2) -> decltype
(forward<F1>(f1) + forward<F2>(f2))
{
return forward<F1>(f1) + forward<F2>(f2);
} ra, musimy to zapisać jawnie. Można to zrobić na dwa
C++11 CZĘŚĆ I
RANGE-BASED FOR
Nie ma chyba programisty, który w swoim życiu nie na-
pisałby pętli iterującej po tablicy. Jeżeli zamiast tablicy
użyjemy vectora z biblioteki standardowej, zwykłe wypi-
sanie jego zawartości robi się mało czytelne; prezentuje
to Listing 4a.
Listing 4a. Pętla po wektorze stringów, w stylu C++03
std::vector<std::string> v;
v.push_back("ala");
v.push_back("ma");
v.push_back("kota");
for(std::vector<std::string>::const_iterator it=v.
begin(); it!=v.end(); ++it)
std::cout << *it << std::endl;
To, że potrzeba uproszczenia tej składni istniała, widać po
tym, że w bibliotece standardowej wprowadzono funkcję
szablonową for_each mającą naśladować obecną w wie-
lu językach pętlę foreach. Odpowiednik tej pętli został
wprowadzony w C++11 i jest pokazany na Listingu 4b.
Listing 4b. Pętla po tablicy, w stylu C++11
int my_array[5] = {1, 2, 3, 4, 5};
for (int &x: my_array)
x *= 2;
for (int x: my_array)
std::cout << x << ' ';
Pętla taka pozwala iterować nie tylko po tablicy, ale rów-
nież po liście inicjalizacyjnej (ang. initializer list) oraz
po wszystkich kontenerach udostępniających funkcje
begin() oraz end(), zwracające sekwencyjne iteratory
na początek i koniec kolekcji.
Dalsze uproszczenie zapisu jest możliwe dzięki wyko-
rzystaniu nowego wcielenia słowa kluczowego auto. Zo-
stało ono pokazane na Listingu 4c.
Listing 4c. Pętla po wektorze stringów w stylu "C++11"
std::vector<std::string> v;
v.push_back("ala");
v.push_back("ma");
v.push_back("kota");
for(auto &s: v)
std::cout << s << std::endl;
Zapis pętli z Listingu 4c jest wyraźnie krótszy niż jego
odpowiednik z Listingu 4a. Pytanie tylko, czy znaczy do-
kładnie to samo? Okazuje się, że nie do końca, gdyż w
przypadku auto nie mamy możliwości jawnego określe-
nia, czy chcemy dostać iterator czy też const_itera-
tor. W tym wypadku zależy to od kontekstu. Jeżeli vector
jest stały, to s będzie referencją const. Jeżeli chcemy
wymusić takie zachowanie, dla modyfikowalnego vecto-
/ www.programistamag.pl / 27
 JĘZYKI PROGRAMOWANIA

sposoby: stosując jawne podanie typu (Listing 4b) lub
używając nowych metod kontenerów standardowych:
cbegin() oraz cend().
PODSUMOWANIE
W niniejszym artykule przedstawione zostały nowe elemen-
ty języka C++11. Bardzo dużą i ważną zmianą jest doda-
nie generatorów liczb pseudolosowych do biblioteki stan-
dardowej. Uczynienie tak ważnego elementu elastycznym
i standardowym z pewnością przyczyni się do powstawania
wyższej jakości kodu oraz, na co autorzy mają nadzieję,
mniejszej liczby luk bezpieczeństwa z nimi związanych.
Niemałym plusem, dla osób tworzących metaprogramy,
jest pojawienie się konstrukcji decltype, pozwalającej
na ,,sprawdzanie'' typu wyrażenia w czasie kompilacji. W
połączeniu z alternatywną składnią funkcji, programista
otrzymuje potężne narzędzie, umożliwiające pisanie bar-
dziej generycznego kodu, który stanie się jeszcze prost-
szy w utrzymaniu.
Ciekawym rozszerzeniem składni C++11 jest też do-
danie pętli for, automatycznie iterującej po elementach
tablic i kontenerów. Taki zwięzły zapis nie tylko pozwoli
na skrócenie zapisu standardowych konstrukcji języka,
ale także fenomenalnie uprości tworzenie uogólnionego
kodu. Od tej pory szablony nie będą musiały już spraw-
dzać, czy dany element jest tablicą czy też kontenerem.
Do iterowania wystarczy nazwa samego obiektu!
CIĄG DALSZY
W następnym odcinku niniejszego cyklu opisany zosta-
nie mechanizm cech typów. Jest to kolejny ukłon w stro-
nę tworzących metaprogramy, mający ułatwić spraw-
dzanie własności parametrów. Omówione zostaną także
rozszerzenia składni dotyczące typów wyliczeniowych
oraz reprezentacji i mierzenia czasu. Na koniec pojawi
się także kilka drobnych, lecz bardzo przydatnych roz-
szerzeń: jawne operatory konwersji oraz nowe modyfi-
katory metod.

bartek.szurgot@baszerr.eu
Bartosz Szurgot http://www.baszerr.eu

Absolwent Informatyki wydziału Informatyki i Zarządzania Politechniki Wrocławskiej.

Główne zainteresowania techniczne to: programowanie, Linux, urządzenia wbudowane oraz
elektronika. W wolnym czasie tworzy oprogramowanie open-source oraz układy elektroni­
czne. W C++ programuje od 10 lat.

Mariusz Uchroński mariusz.uchronski@gmail.com

Absolwent Elektroniki i Telekomunikacji wydziału Elektroniki Politechniki Wrocławskiej

oraz pracownik Wrocławskiego Centrum Sieciowo-Superkomputerowego. Główne nurty
zainteresowań technicznych to: programowanie oraz obliczenia HPC, a w szczególności pro-
gramowanie GPU w CUDA i OpenCL. W C++ programuje od 6 lat.

Wojciech Waga wojciech.waga@gmail.com

Absolwent Informatyki na wydziale Matematyki i Informatyki Uniwersytetu Wrocławskiego,

obecnie słuchacz studiów doktoranckich biologii molekularnej UWr oraz pracownik
Wrocławskiego Centrum Sieciowo-Superkomputerowego. Programuje w C++ od 12 lat.

28 / 1 . 2012 . (1)  /

 JĘZYKI PROGRAMOWANIA
Wybrane elementy języka
Objective-C i ich wykorzystanie
Obecnie język Objective-C bardzo szybko zyskuje na popularności. Rośnie jego wy-
korzystanie za sprawą dużej popularności aplikacji na iPhone'a. Warto więc znać kil-
ka przydatnych mechanizmów, które usprawnią nasze rozwiązania implementacyjne
w wykonywanych projektach.
W
obecnym okresie język Objective-C bardzo szyb-
ko zyskuje na popularności. Spowodowane jest
to głównie ekspansją na rynku produktów firmy
Apple, jak iPhone, iPad czy iTouch. Po wykupieniu progra-
mu developerskiego Apple'a, możemy dystrybuować wła-
sną aplikację i zarabiać na tym niemałe pieniądze. Jako
programista natywnych aplikacji warto znać kilka waż-
nych i przydatnych elementów języka, które mogą bardzo
ułatwić nam przyszłą pracę przy rozwijaniu naszych sys-
temów. Elementy te mogą także zaciekawić osoby dopie-
ro zaczynające przygodę z platformą iOS. W niniejszym
artykule postaram się zaprezentować elementy języka,
które są bardzo istotne podczas rozwijania oraz utrzymy-
wania projektów na mobilne platformy. W szczególności
będą to:
■■ programowanie z użyciem bloków,
■■ kategorie i ich wykorzystanie,
■■ protokoły oraz selektory w Objective-C,
■■ zarządzanie pamięcią w Objective-C,
■■ użyteczne makra w Objective-C.
Na początku warto krótko wspomnieć, czym jest język
Objective-C. Jest to rozszerzenie języka C o możliwo-
ści obiektowe, wzorowane na Smalltalku. Język obrał
odmienną drogę od C++. Jest używany głównie w fra-
mework'u Cocoa w systemie Mac OS X oraz w iOS. Ob-
jective-C jest głównym językiem programowania na
iPhone'a. Jest on rozszerzeniem języka ANSI C o moż-
liwości programowania obiektowego. Zatem dostajemy
dziedziczenie, enkapsulacje czy polimorfizm. Elemen-
ty składniowe, o jakie rozszerzono w tym celu język C,
używają dwóch symboli: [] oraz @ (rozszerzeń składni
jest dużo więcej, ale tylko te wchodzą w jakiekolwiek
interakcje ze składnią języka C). Nawiasy kwadratowe
są używane do wywoływania metod, natomiast @ do de-
finicji specyficznych dla języka Objective-C. Istnieją też
specjalnie dla Objective-C wprowadzone typy, istnieją-
ce już według reguł języka C, z których najważniejszym
jest id. Typ ten jest uniwersalną "referencją do obiektu"
(dokładnie to wskaźnikiem, z punktu widzenia języka
C). Ponieważ nie jest to artykuł traktujący o zmianach
(i o samym języku), które wprowadza język, lecz o przy-
datnych elementach, nie będę więc zgłębiał wszystkich
30 / 1 . 2012 . (1)  /
Łukasz Mazur
różnic i niuansów w porównaniu do Javy czy C (więcej
szczegółowych informacji można znaleźć w serwisie:
https://developer.apple.com).
BLOKI
Artykuł rozpoczniemy od bloków. Blok jest obiektem, któ-
ry zamyka w sobie jakąś jednostkę (część) kodu. Jest
tzw. segmentem kodu, który może być w dowolnym mo-
mencie uruchomiony ( i wykonany w kontekście imple-
mentowanej metody) lub przekazany jako argument do
funkcji. Tak przekazywany argument można dalej trakto-
wać jak każdy inny obiekt. Jest to wygodne i przydatne
rozwiązanie.
Bloki są cechą języka C, które zostały dodane do
iPhone i iPad SDK w wersji iOS 4. W języku Objective-C
„bloki” to inaczej domknięcia leksykalne (ang. closures)
lub funkcjonujące w innych językach wyrażenia lambda.
Każde takie wyrażenie posiada zasięg leksykalny zakre-
su, w którym zostało stworzone (tak więc jeśli w bloku
domknięcia użyjemy zmiennej lokalnej, będzie ona ist-
nieć do chwili destrukcji samego wyrażenia lambda).
Zamiast używać funkcji zwrotnych wymagających odpo-
wiedniej struktury danych (reprezentujących wszystkie
informacje kontekstowe potrzebne do wykonania opera-
cji), wystarczy mieć możliwość bezpośredniego dostępu
do zmiennych lokalnych. Bloki umożliwiają taki dostęp,
więc stwarza nam to wielkie możliwości na wykorzystanie
bloków.
Na Listingu 1 został przedstawiony przykład deklaracji
i użycia bloku.
Listing 1. Przykład deklaracji oraz użycia bloku kodu
// plik implementacji (*.m)
int (^sum) (int, int) = ^(int arg1, int arg2){
return arg1 + arg2;
};
int result = sum( 1, 2);
NSLog(@"suma wynosi: %d", result);
W przykładzie z Listingu 1 deklarujemy (i wykorzystuje-
my) blok przyjmujący dwa argumenty typu int i zwraca-
jący wartość typu int. Znak ^ jest wymagany do zdefi-
niowania bloku. Przykład jest generalnie poglądowy i nie
 WYBRANE ELEMENTY JĘZYKA OBJECTIVE-C I ICH WYKORZYSTANIE
ma większego sensu czy znaczenia z punktu widzenia in-
żynierii programowania.
Prawdziwą siłę bloków można doświadczyć, używając
ich jako zwrotnych (callback'owych), kiedy inna operacja
została zakończona, przekazywanych do funkcji jako ar-
gument. Mogą wiec być alternatywą dla delegacji w przy-
padku, gdy zaistnieje potrzeba, kiedy obiekt delegata ma
implementować tylko jedną metodę (Listing 2).
Listing 2. Przykład wykorzystania bloku
// istnieje możliwość zdefiniowania typu bloku za
pomocą słówka typedef
typedef int (^Multiply)(int, int);
// w takiej sytuacji możemy zdefiniować metodę
// przyjmującą blok jako argument, w ten sposób
- (void) multiplyMethod: (Multiply) mult;
// implementacja mogłaby wyglądać następująco
- (void) multiplyMethod: (Multiply) mult{
int a, b;
a = 4;
b = 6;
NSLog(@"Wynik operacji %d * %d wynosi: %d", a,
b, mult(a,b));
}
// następnie w kodzie możemy opisać blok i użyć
naszej metody
Multiply myMult = ^(int arg1, int arg2){
return arg1*arg2;
};
[self multiplyMethod:myMult];
Definicja bloku następuje po słowie kluczowym typedef,
po czym specyfikujemy strukturę bloku:
typedef int (^Multiply)(int, int);
Gdybyśmy nie zdefiniowali typu bloku za pomocą typedef,
deklaracja funkcji musiałaby wyglądać następująco (czyli
zawierać całą specyfikację dla bloku):
- (void) multiplyMethod:(int (^)( int a, int b)) mult;
Bloki są cechą języka C, które zostały dodane do iPhone
i iPad SDK w wersji iOS 4. Pozwalają na stworzenie „blo-
ku” kodu, który można dalej przekazać, jak każdy obiekt
(jest to wygodne i przydatne rozwiązanie).
Listing 3. Przekazywanie bloku
// bardzo prosty przypadek
[foo someMethod:^{
// pożądany kod w tym miejscu
}];
// blok pobierający argumenty
[foo someMethod:^(NSString *var1, BOOL var2) {
// var1 oraz var2 mogą być użyte
// jak argumenty w funkcji
}];
Listing 4. Pobieranie bloków
// pobranie bloku bez argumentów
- (void)someMethod:(void(^)())block;
// pobranie bloku z argumentami
- (void)someMethod:(void(^)(NSString *test, id
anyObject))block;
// przypadki typu zwracanego
- (void)someMethod:(BOOL(^)())block;
- (void)someMethod:(NSRange *(^)())block;
// wywołanie bloku
- (void)someMethod:(void(^)(NSString *test))block {
block(@"Przykładowy tekst w bloku");
}
Listing 5. Używanie bloków zwróconych z metod
// przypisanie do tablicy - bloku
- (void)registerCallback:(BOOL(^)())callback {
[_listeners addObject:[[callback copy]
autorelease]];
}
- (void)runCallbacks {
int i = [_listeners count];
while (i--) {
BOOL (^block)() = [_listeners
objectAtIndex:i];
BOOL state = block();
// tutaj dalsza część kodu ...
}
}
Wszystko, co możemy zrobić, wykorzystując bloki, moż-
na również zrobić w inny sposób. Stwierdzenie to jest
prawdą, bloki jednak dostarczają bardzo użytecznej
możliwości na uproszczenie kodu i uczynienia rzeczy
bardziej przejrzystymi. Warto więc poeksperymentować
na kilku przykładach, a po pewnym czasie ciekawe roz-
wiązania z pewnością się pojawią. Na przykład, załóżmy,
że mamy połączenie URL i chcemy poczekać na wynik.
Dwa popularne podejścia to: zapewnienie callback'u de-
legata lub użyć bloku. Wykorzystamy do zaprezentowa-
nia tego fikcyjną klasę URLConnection jako przykład
(Listing 6).
Listing 6. Przykład wykorzystania delegata
URLConnection* someConnection=[[[URLConnection
alloc] initWithURL:someURL] autorelease];
someConnection.delegate=self;
[someConnection start];
// następnie w danej klasie
// obsługujemy metodę delegata
- (void)connection:(URLConnection)connection
didFinishWithData:(NSData*)
{
// wykonaj działania na danych
}
Natomiast w przypadku korzystania z bloku, można osa-
dzić kod, który jest wywoływany dokładnie tam, gdzie
tworzymy połączenie (Listing 7).
/ www.programistamag.pl / 31
 JĘZYKI PROGRAMOWANIA
Listing 7. Przykład wykorzystania bloku
URLConnection* someConnection = [[[URLConnection
alloc] initWithURL:someURL] autorelease];
someConnection.successBlock = ^(NSData*)data {
// wykonaj działania na danych
};
[someConnection start];
Dodatkowo załóżmy, że mamy wiele połączeń w swojej
klasie i wszystkie potrzebujemy obsłużyć przy użyciu tego
samego delegata. Teraz więc musimy rozróżnić poszcze-
gólne połączenia w naszej metodzie delegata. To może
się komplikować, im więcej połączeń jest dostępnych (Li-
sting 8).
Listing 8. Obsługa metody w podejściu z delegatem
- (void)connection:(URLConnection)connection
didFinishWithData:(NSData*)
{
if(connection == self.connection1)
{
// wykonaj działania na danych z connection1
}
if(connection == self.connection2)
{
// wykonaj działania na danych z connection2
}
if(connection == self.connection3)
{ stąpienia / nadpisania metod, które dziedziczą z klasy
// wykonaj działania na danych z connection3
}
...
} tody przy użyciu specyfikatora super. Przypuszczalnie
Wykorzystując podejście korzystające z bloku, można użyć
unikalnego bloku na dane połączenie URL, co jest bardziej
przejrzyste w trakcie późniejszego utrzymania kodu.
Powyżej przedstawiłem krótki opis oraz przykładowe
wykorzystanie bloków, o których oczywiście można pisać
o wiele więcej, myślę jednak, że taka dawka informacji
powinna zaciekawić Czytelnika do dalszego zgłębienia
tematu. Szczegółowych informacji można wyszukać na:
https://developer.apple.com/resources/ w dziale: Blocks
Programming Topics.
KATEGORIE
Jednym z problemów, przed którym stanęli projektanci
języka Objective-C, było zadbanie o ułatwienie kontroli
nad dużymi fragmentami kodu, gdyż był to powszechny
problem w przypadku programowania strukturalnego.
Kategorie to fragmenty klasy odpowiedzialne za okre-
śloną funkcjonalność, którą realizuje klasa (przykładowo
klasa NSString może mieć część odpowiedzialną za tłu-
maczenie tekstu). Co więcej metody kategorii dodawane
są w czasie wykonania. W związku z tym metody mogą
być dodane do istniejących klas bez rekompilacji i bez
dostępu do źródła.
Przykładem jest kategoria MathUtilities, która dodaje do
klasy NSNumber metody (toRadians, toDegrees) przydatne
podczas zamiany stopni na radiany i odwrotnie (Listing 9).
32 / 1 . 2012 . (1)  /
Listing 9. Przykład kategorii MathUtilities na klasie NSNum-
ber
// plik nagłówkowy (*.h)
#import <Foundation/Foundation.h>
@interface NSNumber (MathUtilities)
- (float) toRadians;
- (float) toDegrees;
@end
// NSNumber+MathUtils.m
#import "NSNumber+MathUtils.h"
@implementation NSNumber (MathUtilities)
- (float) toRadians
{
return [self floatValue] * (M_PI/180);
}
- (float) toDegrees
{
return [self floatValue] * (180/M_PI);
}
@end
// przykład użycia nowej metody w kodzie
...
NSNumber *myDegrees = [NSNumber
numberWithFloat:180];
NSLog(@"Radiany: %.2f", [myDegrees toRadians]);
...
Kategorie mogą być również wykorzystywane do za-
bazowej (co stanowi alternatywę do tworzenia podkla-
sy). Zawsze można uzyskać dostęp do nadpisanej me-
z perspektywy kompilatora (code generation) może
prowadzić do mniejszego narzutu kodu w stosunku do
opcji tworzenia podklasy (wyłącznie po to, aby zastąpić
metodę).
Metody w kategoriach są nierozróżnialne z metodami
klasy - w szczególności mają dostęp do zmiennych pry-
watnych. Kategorie mogą również przedefiniować istnie-
jące już metody (np. mogą poprawić błędną implementa-
cję lub rozszerzyć funkcjonalność). Należy zaznaczyć, iż
w sytuacji, gdy mamy dwie kategorie, które przedefinio-
wują tę samą metodę - specyfikacja języka nie określa
dokładnie, która z metod będzie użyta.
Kategorie stanowią ciekawą możliwość rozproszenia
realizacji klasy na jednym lub kilka plików. Objective-C
Programming Guide wymienia kilka zalet tego podejścia,
w tym:
■■ możliwość grupowania metod, które wykonują podob-
ne zadania,
■■ konfiguracji klasy dla różnych zastosowań, zachowując
jednak jeden zestaw kodu.
Tworzenie kategorii jest sposobem na rozdzielenie imple-
mentacji metod na kilka części. Pozwala to na:
■■ oddzielną kompilację,
■■ grupowanie metod, które dzięki temu są jasno
rozdzielone,
 WYBRANE ELEMENTY JĘZYKA OBJECTIVE-C I ICH WYKORZYSTANIE
■■ klasy mogą być rozszerzane odmiennie w różnych apli-
kacjach bez konieczności duplikowania kodu,
■■ każda klasa może zostać rozszerzona - nawet klasy
z framework'u Cocoa.
Jako alternatywę dla tworzenia podklas, kategorie w Ob-
jective-C zapewniają możliwość dodawania nowych me-
tod w danej klasie. Interesujące jest to, iż wszelkie me-
tody, które są dodawane w danej kategorii, stają się
częścią bazowej klasy (którą kategoria rozszerza). Inny-
mi słowy, jeśli dodać metodę do klasy NSString, to każ-
da instancja lub podklasa utworzona z NSString będzie
mieć dostęp do tej metody. Definiowanie kategorii jest
identyczne do zdefiniowania interfejsu dla klasy. Niewiel-
kim wyjątkiem jest tutaj to, iż nazwę kategorii potrzeba
wyspecyfikować wewnątrz nawiasów: (nazwa) tuż po
deklaracji interfejsu. Przykładowyf format został przed-
stawiony na Listingu 10.
Listing 10. Przykład definiowania kategorii
// plik nagłówkowy (*.h)
// ogólny schemat definiowania kategorii
@interface ClassToAddMethodsTo (category)
// ... lista metod
@end
// definicja kategorii reverse dla klasy NSString
@interface NSString (reverse)
-(NSString*) reverseString;
@end
Dla przykładu, na Listingu 10 mamy zdefiniowaną kate-
gorię, która dodaje metodę do klasy NSString. Metoda
reverseString dodaje możliwość odwrócenia znaków
w łańcuchu tekstowym dla wszystkich obiektów utworzo-
nych z klasy NSString.
Podobnie jak w przypadku zmiany w deklaracji kate-
gorii (w sekcji @interface), sekcja @implementation
jest w podobny sposób zmodyfikowana. Tuż po nazwie
klasy dodajemy nazwę kategorii zawartą w nawiasach.
Na Listingu 11 znajduje się implementacja interfejsu zde-
finiowanego wcześniej na Listingu 10. Należy zauważyć,
iż w obu przypadkach została dodana nazwa kategorii
(reverse).
Zalecana konwencja nazewnicza dla plików kategorii jest
następująca:
"ClassToAddMethodsTo+CatgoryName"
Przykładowo, dla pliku interfejsu i pliku implementacji
kodu kategorii przedstawianego na listingach, zostały wy-
korzystane następujące nazwy:
NSString+Reverse.h
NSString+Reverse.m
Warto na koniec zaznaczyć, iż nie można dodać zmien-
nych do klasy w danej kategorii. Również nazwy kategorii
muszą być unikalne w całej aplikacji.
Listing 11. Przykład implementacji kategorii
// plik implementacji (*.m)
@implementation NSString (reverse)
-(NSString *) reverseString
{
NSMutableString *reversedStr;
int len = [self length];
// automatycznie zwalniany obiekt NSString
reversedStr = [NSMutableString
stringWithCapacity:len];
// mało efektywne
while (len > 0)
[reversedStr appendString:
[NSString stringWithFormat:@"%C", [self
characterAtIndex:--len]]];
return reversedStr;
}
@end
Listing 12. Przykład użycia zaimplementowanej kategorii
(reverse)
#import <Foundation/Foundation.h>
#import "NSString+Reverse.h"
int main (int argc, const char * argv[])
{
NSAutoreleasePool *pool = [[NSAutoreleasePool
alloc] init];
NSString *str = [NSString
stringWithString:@"Tekst demonstracyjny."];
NSString *rev;
NSLog(@"String: %@", str);
rev = [str reverseString];
NSLog(@"Po odwróceniu mamy: %@",rev);
[pool drain];
return 0;
}
PROTOKOŁY
Protokół to lista metod, które klasa musi zadeklarować
i zaimplementować. Od wersji Objective-C 2.0 mogą one
posiadać metody opcjonalne. Protokoły realizują idee
wielokrotnego dziedziczenia specyfikacji, ale nie imple-
mentacji. W C++ ten wzorzec osiąga się poprzez wie-
lokrotne dziedziczenie klas bazowych (abstrakcyjnych),
a w C# i w Javie poprzez interfejsy. Przykł. pewna klasa
GDButton może mieć delegata implementującego proto-
kół z opcjonalną metodą showShining. Obiekt GDButton
może sprawdzić, czy delegat implementuje showShining
poprzez refleksje, i jeśli tak, to wysyłać odpowiedni ko-
munikat do delegata, by skorzystać z tej funkcjonalności.
Warto zwrócić uwagę na różnice pomiędzy interfejsami
z Javy a protokołami z Objective-C, polegające na tym,
że w Objective-C klasa może implementować protokół,
nawet jeśli nie zostało to zadeklarowane (w szczególno-
ści, wykorzystując kategorie, możemy nawet poprawić
istniejącą już klasę tak, by zaczęła implementować ja-
kiś protokół). Można sprawdzić, czy obiekt jest zgodny
z określonym protokołem, jak pokazano poniżej:
-(BOOL) conformsToProtocol:(Protocol*)protocol
if ([myObject conformsToProtocol:@
/ www.programistamag.pl / 33
 JĘZYKI PROGRAMOWANIA

protocol(MyProtocol)]) { Listing 15a. Przykład użycia klasy implementującej protokół

// jeżeli tak to wykonaj zadane czynności - plik nagłówkowy (*.h)
}
... // aby utrzymać przykład zwięzłym,
// klasa adoptująca protokół
Klasa może implementować wszystkie metody dla dane- // to klasą appDelegata
go protokołu bez deklarowania zgodności z nim. W takim #import <UIKit/UIKit.h>
#import "ClassWithProtocol.h"
przypadku conformsToProtocol: zwróci wartość NO. @interface TestAppDelegate : NSObject
Podsumowując, należy zapamiętać to, iż protokoły są <UIApplicationDelegate, ProcessDataDelegate>
odpowiednikami interfejsów w C# i Javie. Definiują one {
UIWindow *window;
zbiór metod, które muszą być zaimplementowane przez ClassWithProtocol *protocolTest;
klasę wykorzystującą dany protokół oraz pewna klasa }
może być zgodna z dowolną liczbą protokołów (Listing @property (nonatomic, retain) UIWindow *window;
@end
13).
Listing 15b. Przykład użycia klasy implementującej protokół
Listing 13. Przykład deklaracji protokołu - plik implementacji (*.m)

// deklaracja protokołu #import "TestAppDelegate.h"

#import "ClassWithProtocol.h"
@protocol MouseListener
-(BOOL) mousePressed;
@implementation TestAppDelegate
-(BOOL) mouseClicked;
@synthesize window;
@end - (void)processSuccessful:(BOOL)success;
{
// deklaracja protokołu NSLog(@"Proces zakończony");
@protocol KeyboardListener }
-(BOOL) keyPressed; - (void)
@end applicationDidFinishLaunching:(UIApplication*)
// deklaracja (interfejsu) klasy application
wykorzystującej 2 protokoły {
@interface InputReader: NSObject <MouseListener,
KeyboardListener> // utworzenie i inicjalizacja okna (window)
@end window = [[UIWindow alloc]
initWithFrame:[[UIScreen mainScreen] bounds]];
Listing 14. Przykład definicji i implementacji protokołu protocolTest = [[ClassWithProtocol alloc] init];
[protocolTest setDelegate:self];
[protocolTest startSomeProcess];
// plik nagłówkowy (*.h)
#import <Foundation/Foundation.h> [window makeKeyAndVisible];
// definicja protokołu }
@protocol ProcessDataDelegate <NSObject> - (void)dealloc
@required {
- (void) processSuccessful: (BOOL)success; [window release];
@end [super dealloc];
}
@interface ClassWithProtocol : NSObject @end
{
id <ProcessDataDelegate> delegate;
} SELEKTORY
@property (retain) id delegate;
-(void)startSomeProcess; Selektor może być zarówno nazwą metody (lub komuni-
@end
katu do obiektu), która jest zaimplementowana w kodzie
// plik implementacji (*.m) źródłowym klasy, z której chcemy wywołać metodę (lub do
// implementacja klasy wykorzystującej protokół której chcemy wysłać komunikat). Selektora można tak-
#import "ClassWithProtocol.h"
że użyć, aby wywołać metodę na danym obiekcie. Należy
@implementation ClassWithProtocol
@synthesize delegate; również pamiętać, iż wszystkie metody o tej samej nazwie
- (void)processComplete mają ten sam selektor. W tym prostym przykładzie będzie
{ zamieniony dowolny ciąg znaków na małe litery (metoda
[[self delegate] processSuccessful:YES];
} lowercaseString) przy użyciu selektora (Listing 16).
-(void)startSomeProcess
{ Listing 16. Przykład wykorzystania selektora
[NSTimer scheduledTimerWithTimeInterval:5.0
target:self
// plik nagłówkowy (*.h)
selector:@selector(processComplete) userInfo:nil
// selectorAppDelegate.h
repeats:YES];
#import <UIKit/UIKit.h>
}
@interface SelectorAppDelegate : NSObject
@end
<UIApplicationDelegate> {
UIWindow *window;

34 / 1 . 2012 . (1)  /

 WYBRANE ELEMENTY JĘZYKA OBJECTIVE-C I ICH WYKORZYSTANIE
NSString *string;
} by systemu w trakcie swojego działania, a na mobilnych
@property (nonatomic, retain) IBOutlet UIWindow
*window;
@property (nonatomic, retain) NSString *string;
@end
// plik implementacji (*.m)
// SelectorAppDelegate.m
#import "SelectorAppDelegate.h"
@implementation SelectorAppDelegate
@synthesize window, string;
- (void) applicationDidFinishLaunching:(UIApplication
*) application {
[window makeKeyAndVisible];
NSString *str = @"WITAM, TO JEST PRZYKŁAD TEKSTU";
SEL sel = @selector(lowercaseString);
NSString *lower = (([str leźć wspaniałą dokumentację na stronie Apple'a do tego
respondsToSelector:sel]) ? @"YES" : @"NO");
NSLog(@"Odpowiada na selektor: %@", lower);
// sprawdzenie czy można wysłać komunikat
if([str respondsToSelector:sel]) //selektor pamięcią na iOS.
(lower == @"YES")
NSLog(@"lowercaseString: %@" , [str
lowercaseString]);
} alokowane przy zastosowaniu alloc. Każda alokacja po-
(void)dealloc {
[window release];
[super dealloc];
} można obserwować właściwość retainCount w zwalnia-
@end
Jak można zauważyć w kodzie, specyfikator SEL jest
krótszą formą instrukcji @selector(). Selektor można
zapisać jako:
SEL sel = @selector(lowercaseString);
Metoda wywołana za pomocą komunikatu lowercase-
String zmieni dany ciąg znaków na małe litery. Po uru-
chomieniu aplikacji, na wyjściu z konsoli będzie to wyglą-
dać następująco:
Odpowiada na selektor: YES
lowercaseString: witam, to jest przykład tekstu
Sprawdzenie poprzez respondsToSelector jest bardzo
istotne, gdy nasza aplikacja ma pracować jednocześnie
na różnych wersjach systemów iOS 3.x, 4.x, 5.x. Poszcze-
gólne wersje nie są kompatybilne, tzn. obiekty w wersji
wyższej mogą zawierać metody, których nie było na wer-
sji niższej. W takim przypadku wysłanie komunikatu bez
sprawdzenia, czy istnieje dany selektor, spowoduje crash
aplikacji.
ZARZĄDZANIE PAMIĘCIĄ
Jeżeli Czytelnik nie miał okazji bliżej przyjrzeć się języ-
kowi Objective-C (pod kątem programowania na iOS),
a jego doświadczenie pochodzi z innych środowisk pro-
gramistycznych, takich jak Java czy .NET, to w tym mo-
mencie należy oswoić się ze złą wiadomością. Pomimo
tego, iż GC (garbage collector) jest dostępny na MacOS
(od wersji 10.5), nie jest on obsługiwany i wspierany na
systemie iOS.
Jest znanym faktem, iż GC pobiera dodatkowe zaso-
platformach (w porównaniu do maszyn desktopowych)
są one szczególnie ograniczone. Prawdopodobnie dlatego
decyzja o obsłudze zarządzania pamięcią poprzez manu-
alne liczenie referencji i zwalnianie obiektów ma sens.
Chociaż GC jest możliwy do zaimplementowania na
mobilnych platformach (Android ma go zaimplementowa-
nego!), zużywa to baterię o wiele bardziej. Co gorsze, zu-
życie pamięci jest także większe i aplikacje mogą czasami
tracić zdolność reakcji, podczas gdy GC wykonuje swoją
pracę. Nie zamierzam zagłębiać się w szczegóły niskich
poziomów zarządzania pamięcią, ponieważ można zna-
tematu, ale zamiast tego chcę pokazać kilka najbardziej
typowych przypadków oraz ogólne zasady zarządzania
Najważniejszą zasadą jest to, iż trzeba zwolnić tylko te
obiekty, które „twój kod posiada”, to znaczy te, które są
winna mieć odpowiednie zwolnienie (release), inaczej pa-
mięć będzie wyciekać (leak). Aby być bardziej pewnym,
nym obiekcie.
Listing 17a. Przykład alokacji i zwolnienia obiektu
NSString *text = [[NSString alloc] init];
// wykonaj działania na zmiennej text
[text release];
Jeśli nie tworzymy obiektu poprzez alokowanie pamięci
za pomocą alloc, oznacza to, iż ten obiekt jest automa-
tycznie zwalniany w następnym etapie (na niższym po-
ziomie). Musi to być zapewnione w kodzie obiektu, który
pobieramy. Nie powinno się go zwalniać manualnie (bę-
dzie to zwolnienie podwójne i wyrzuci błąd), co zostało
pokazane na Listingu 17b.
Listing 17b. Przykład niepoprawnego zwolnienia pamięci
NSString *text = [[NSString
stringWithString:@"Sample text"];
// wykonaj działania na zmiennej text
// obiekt będzie automatycznie zwolniony później
...
// instrukcja spowoduje wyrzucenie błędu!
[text release];
Potrzeba przechować (retain) obiekty, których nie posia-
damy poprzez alokację, inaczej mogą być one zwalniane
zewnętrznie (w kodzie, z którego pochodzą), gdy jeszcze
potrzebujemy wykonywać na nich pewne operacje. Naj-
łatwiej zrobić to przez specyfikacje retain w deklaracji
właściwości klasy (Listing 17c).
Listing 17c. Przykład właściwości klasy zachowującej przypi-
sany obiekt
// plik nagłówkowy (*.h)
/ www.programistamag.pl / 35
 JĘZYKI PROGRAMOWANIA
@property (retain) NSString *text;
// plik implementacji (*.m)
@synthesize text;
// przypisanie automatycznie zwalnianego obiektu
// do właściwości spowoduje jego zachowanie
...
self.text = [NSString
stringWithString:@"Przykładowy napis"];
...
Bardzo ważne jest, iż trzeba wykonać manualne zwolnie-
nie pamięci dla wszystkich właściwości klasy, które prze-
trzymują wartości, oraz dla wszystkich zmiennych, w któ-
rych przechowywane są referencje do innych obiektów.
Operację tę wykonujemy w metodzie dealloc, przypisu-
jąc najpierw obiektowi wartość nil, a następnie urucha-
miamy metodę release (Listing 17d). Można do tej pro-
cedury napisać stosowne makro, które zaoszczędzi nam
sporo czasu.
Listing 17d. Przykład prostej metody dealloc
// plik implementacji (*.m)
- (void)dealloc {
text = nil;
[text release];
[super dealloc];
}
Pewnym przypadkiem użycia jest dodanie obiektu do
kolekcji. Kolekcja wtenczas przejmuje prawo własno-
ści nad tym obiektem, więc nie potrzeba martwić się
o przechowywanie go samemu. Kolekcja traci prawo
własności do tego obiektu, jeżeli zostanie zwolniona
z pamięci. Na Listingu17e zostało to przedstawione za
pomocą kodu.
Listing 17e. Przykład przypisania obiektu do kolekcji i jej
zwolnienia
// plik nagłówkowy (*.h)
@property (retain) NSString *text;
// plik implementacji (*.m)
@synthesize text;
// przypisanie automatycznie zwalnianego obiektu
// do właściwości spowoduje jego zachowanie
...
self.text = [NSString
stringWithString:@"Przykładowy napis"];
...
Powyżej zostało scharakteryzowanych kilka ważniejszych
elementów dotyczących zarządzania pamięcią. Zdaję so-
bie sprawę, iż zabiera to trochę czasu, aby przyzwyczaić
się do opisanego podejścia i wykorzystywać go. Nie jest
to tak proste, jak automatyczne zarządzanie pamięcią
w środowiskach, w których działa GC. W iOS 5.0 możemy
użyć automatycznego liczenia referencji (ARC), które jest
podobne do GC. Ma to również swoje wady, jak i zalety
jak każdy niuans.
Trzeba być bardzo ostrożnym, ponieważ niepoprawna
obsługa pamięci powoduje jej wycieki (leaks) lub awa-
36 / 1 . 2012 . (1)  /
rie (crash) aplikacji, ze względu na dostęp do zdealo-
kowanych obiektów. Sytuacja taka będzie zauważalna
podczas testowania aplikacji na urządzeniu (symulator
nie jest 100% kompatybilny z urządzeniem). Możemy
również wspomóc się narzędziami instruments (jest to
zestaw narzędzi dostarczanych wraz ze środowiskiem
Xcode) do wykrycia wycieków (leaks) lub zdealokowa-
nych obiektów.
MAKRA
Na koniec artykułu chciałem wspomnieć o mechanizmie
instrukcji preprocesora do definiowania makr. Instrukcje
preprocesora są ważnym składnikiem języka Objective-C.
Przykładowe zastosowanie na Listingu 18 pokazuje, jak za
ich pomocą można zdefiniować wspólne wymiary dla po-
szczególnych kontrolek w projekcie. Jest to pewnego ro-
dzaju definiowanie stylu dla pewnego zestawu obiektów,
które powinny mieć spójny wygląd (analogia do CSS).
Bardzo istotnym elementem instrukcji preprocesora jest
możliwość definiowania za ich pomocą makr. Makra ta-
kie są pewnego rodzaju zestawem poleceń, które moż-
na wywołać w kodzie, używając nazwy makra. Następnie
kompilator zamienia je na instrukcje podane w definicji,
włączając je do kodu. Są one bardzo przydatne w sytu-
acjach, gdy kod jest powtarzalny i (jak zazwyczaj) jest
go zbyt dużo. Wtedy taka zamiana na makro ma sens.
Wyróżniamy makra podobne do postaci obiektu:
#define <identyfikator> <instrukcje>
przykład: #define PI 3.14159
oraz podobne do funkcji:
#define <identyfikator>(<lista parametrów>)
<instrukcje>
przykład: #define RADTODEG(x) ((x)*57.29578)
Definicja makra może być usunięta poleceniem:
#undef <identyfikator>
Oto kilka przydatnych makr, które można wykorzystać
w projektach. Wielu z nich używam regularnie, a warto
wiedzieć o makrach i ich wykorzystaniu, ponieważ jest to
bardzo przydatne.
Listing 18. Instrukcje preprocesora definiujące wspólne
wymiary
// przydatne marginesy
#define MARGIN 10
#define BIG_MARGIN 20
...
// deklaracje wspólnych miar
#define CONTROL_WIDTH 200
#define CONTROL_HEIGHT 36
...
#define BIG_CONTROL_WIDTH 300
 WYBRANE ELEMENTY JĘZYKA OBJECTIVE-C I ICH WYKORZYSTANIE

#define BIG_CONTROL_HEIGHT 44 //wykorzystanie makra w kodzie

...
// deklaracje wspólnych ramek w projekcie,
// tutaj zamiast liczb można wykorzystać
// wcześniej zdefiniowane rozmiary
#define TITLE_FRAME CGRectMake(0,0,300,30)
#define LABEL_FRAME CGRectMake(0,0,300,44)
Listing 19. Makro zamieniające wartość heksadecymalną na
RGB
#define HEXCOLOR(c)[UIColor colorWithRed:((c>>24)&0
xFF)/255.0 \
green:((c>>16)&0xFF)/255.0 \
blue:((c>>8)&0xFF)/255.0 \
alpha:((c)&0xFF)/255.0]
...
UIColor* color = HEXCOLOR(0xff00ff00);
...
Makro szybkiej enumeracji po kolekcji. Następujące ma-
kro pomoże w szybkim wyliczeniu / przejściu nad kolek-
cjami (Listing 20). Wyszczególniono tam dwa makra, dla
przykładu pierwsze z nich wykorzystać można do enume-
racji obiektów z kolekcjami typu NSArray, kolejne zaś do
enumeracji kluczy w kolekcjach typu NSDictionary.
Podczas pisania aplikacji na iPhone'a, prawdopodobnie
wiele czasu poświęcamy na pracę z ramkami (frame) w kla-
sie UIView (oraz pochodnych). Zmieniamy je, przesuwamy
po ekranie lub transformujemy. Często potrzeba zmienić

Listing 20. Makra definiujące enumeracje po kolekcji

#define WOEnumerate(collection, object) \

for (id enumerator = [collection objectEnumerator], \
selector = (id)@selector(nextObject), \
method = (id)[enumerator methodForSelector:(SEL)selector], \
object = enumerator ? ((IMP)method)(enumerator, (SEL)selector) : nil; \
object != nil; \
object = ((IMP)method)(enumerator, (SEL)selector))

#define WOKeyEnumerate(collection, object) \

for (id enumerator = [collection keyEnumerator], \
selector = (id)@selector(nextObject), \
method = (id)[enumerator methodForSelector:(SEL)selector], \
object = enumerator ? ((IMP)method)(enumerator, (SEL)selector) : nil; \
object != nil; \
object = ((IMP)method)(enumerator, (SEL)selector))
// użycie w kodzie
WOEnumerate(fileArray, fileName)
NSLog(@"Nazwa pliku: %@", filename);

Listing 21. Makra ułatwiające prace z ramkami

// pobranie parametrów ramki

#define width(a) a.frame.size.width
#define height(a) a.frame.size.height
#define top(a) a.frame.origin.y
#define left(a) a.frame.origin.x
// zmiana pozycji ramki
#define FrameReposition(a,x,y) a.frame=CGRectMake(x,y,width(a),height(a))
// zmiana rozmiaru ramki
#define FrameResize(a,w,h) a.frame=CGRectMake(left(a),top(a),w,h)

Listing 22. Makra do szybkiego tworzenia przydatnych kolekcji

#define $array(objs...) [NSArray arrayWithObjects: objs, nil]

#define $set(objs...) [NSSet setWithObjects: objs, nil]
#define $range(loc, len) NSMakeRange(loc, len)
#define $format(format, objs...) [NSString stringWithFormat: format, objs]

Listing 23. Makra wywołujące alert systemowy

// jak wiadomo wywołanie alertu nie jest jedną linią kodu

#define ALERT(X) {UIAlertView *alert = [[UIAlertView alloc] \
initWithTitle:@"Info" message:X delegate:self cancelButtonTitle:@"OK" \
otherButtonTitles: nil];[alert show];[alert release];}

// dzięki tym makrom potrzeba tylko jednej linii aby uruchomić alert
#define ALERT_TITLE(X,Y) {UIAlertView *alert = [[UIAlertView alloc] \
initWithTitle:X message:Y delegate:self cancelButtonTitle:@"OK" \
otherButtonTitles: nil];[alert show];[alert release];}

// wykorzystanie makra w kodzie

...
ALERT(@”Komunikat z informacją”);
...

/ www.programistamag.pl / 37
 JĘZYKI PROGRAMOWANIA

Listing 24. Skrócone operacje dla klasy NSString

#define FORMAT_SI(s,i) [@"" stringByAppendingFormat:@" %@ %i ",s,i]

#define FORMAT_SF(s,f) [@"" stringByAppendingFormat:@" %@ %f ",s,f]
#define FORMAT_AMOUNT(amount)[@""stringByAppendingFormat:@"$%.2f", amount]
// itp ...
// zabezpieczenie przed wartością nil dla NSString
#define NOTNULL(value) ((value != nil) ? value : @"")
...

Listing 25. Wybrane sposoby definiowania kolorów

// dostęp do tak zdefiniowanych kolorów jest dużo prostszy

#define YELLOW_A(aplha) [[UIColor yellowColor] colorWithAlphaComponent:aplha]
#define RED_A(aplha) [[UIColor redColor] colorWithAlphaComponent:aplha]
...
#define ORANGE RGBCOLOR(255,81,20)
#define LIGHT_GRAY RGBCOLOR(247,247,247)
...
#define WHITE [UIColor whiteColor]
#define CLEAR [UIColor clearColor]
#define BLUE [UIColor blueColor]
...

rozmiar UIView, przesunąć go w inne położenie czy do-
pasować do pewnej zawartości. W takich przypadkach za
każdym razem wystarczy wykorzystanie metody setFra-
me ustawiającej nową ramkę ze struktury CGRectMake.
Przedstawione makra na Listingu 20 pomogły mi zaoszczę-
dzić wiele cennego czasu.
Nie jest to regułą, lecz bardzo dobrym rozwiązaniem
jest utworzenie w swoim projekcie dodatkowego pliku za-
wierającego tylko makra. Plik może przyjąć nazwę przy-
kładowo: NPCommonMacros.h (gdzie: NP=pierwsze litery
od nazwy projektu). Możemy wtedy po dołączeniu go do
wybranych plików źródłowych wykorzystywać wszystkie
makra, które tylko potrzebujemy w danej sytuacji.
PODSUMOWANIE
Pisanie oprogramowania na platformy mobilne to wie-
le szczegółów i niuansów. To również obszerny temat.
Szczegóły te są zauważalne dopiero jak używa się apli-
kacji w środowisku docelowym. Prawdopodobnie dlate-
go Apple udostępnił bardzo wierny symulator zachowa-
nia iPhone'a. Korzystajmy więc ze wszystkich możliwości
środowiska i języka, jakie dostarczył nam producent, by
tworzyć jak najlepsze oprogramowanie.
W artykule zostały zaprezentowane elementy języka,
które są bardzo przydatne dla każdego developera pra-
cującego przy tworzeniu oprogramowania na platformę
iOS. W szczególności programowanie z wykorzystaniem
bloków, implementowanie kategorii, protokoły, selektory,
zarządzanie pamięcią oraz użyteczne makra. Wiadomo,
iż nie są to wysoce skomplikowane elementy języka, ale
warto o nich pamiętać i ich używać w swoich projektach.
Objective-C doczekał się w 2007 roku nowej wersji 2.0
i ciągle zyskuje na popularności dzięki sukcesom firmy Ap-
ple. Warto więc interesować się tym językiem, a szczegól-
nie pewnego jego swoistymi elementami, które mogą nam
pomóc i ułatwić pracę przy rozwijaniu naszych systemów.

W SIECI
PP https://developer.apple.com/devcenter/ios/index.action – serwis Apple'a dla developerów iOS, główne trści: iOS Application
Programming Guide, iOS Development Guide – dokumentacje i przewodniki po architekturze iOS. iOS Human Interface Guide-
lines – przewodnik opisujący wytyczne oraz zasady, przydatne podczas projektowania graficznego interfejsu użytkownika dla
aplikacji iOS
PP https://developer.apple.com/technologies/tools/ – opis narzędzi developerskich i zastosowanych w nich rozwiązaniach
PP http://iosdevelopertips.com/ – przydatne porady i fragmenty kodu dla developerów iOS
PP http://stackoverflow.com/ – serwis posiadający ogromne zbiory odpowiedzi (dla większości języków) na problemy powstające
podczas pisania kodu, w szczególności dla Objective-C (http://stackoverflow.com/questions/tagged/objective-c)

Łukasz Mazur lukash.mazur@gmail.com

Autor jest obecnie programistą / architektem aplikacji biznesowych dedykowanych na plat-

formy mobilne. Pracuje dla irlandzkiej firmy Mobile Travel Technologies Ltd. Jest jednym ze
współtwórców / developerów aplikacji mobile easyJet na system iOS, aktualnie uznawanej za
jedną z najlepiej opracowanych mobilnych aplikacji w swoim segmencie.

38 / 1 . 2012 . (1)  /

 JĘZYKI PROGRAMOWANIA
Marek Sawerwain

Erlang
- język inny niż C++ czy Java
Popularność języków C/C++ oraz Java jak na razie jest niezagrożona, jednakże warto
wiedzieć, że istnieją też inne równie dobre języki programowania. Jednym z nich jest
Erlang, naturalnie daleko mniej popularny niż np: Java. Choć jest to język od Javy
starszy, to jednak pod wieloma względami daleko przewyższa wiele starszych oraz
młodszych języków programowania. W tym krótkim artykule nie sposób opisać ca-
łości języka, jednak mamy nadzieję, że zaprezentowane przykłady zachęcą Czytelni-
ków do dalszych poszukiwań.

B
ez wątpienia Erlang to język inny niż C++ czy Java, aplikacjami Erlanga. Naturalnie Erlang to rozwiązanie
choćby dlatego, iż jego korzenie tego języka sięgają Open Source, ale istnieje możliwość pełnego komercyj-
języka Prolog (programowanie w logice) oraz tech- nego wykorzystania Erlanga, a także uzyskania komer-
nik programowania funkcjonalnego. Paradygmaty progra- cyjnego wsparcia podczas realizacji własnych projektów.
mowania w logice oraz funkcyjnego mocno odróżniają się Możliwe jest to także w Polsce, bowiem istnieje centrum
od programowania sekwencyjnego czy metodologii pro- Erlanga w Krakowie (http://www.erlang-solutions.com/
gramowania obiektowego tak szeroko stosowanych we etc/poland).
współczesnych rozwiązaniach. Jednakże sam Erlang ofe-
ruje także możliwość tworzenia aplikacji rozproszonych INSTALACJA PAKIETU ERLANG
i współbieżnych odpornych na uszkodzenia, co dziś, kiedy
większość systemów działa w środowisku równoległym, Choć język Erlang nie jest tak popularny jak C++ czy
znakomicie się sprawdza i pozwala na tworzenie efektyw- Java, to jednak wszystkie duże dystrybucje Linuxa oferu-
nych rozwiązań. ją gotowe pakiety, więc nie trzeba przeprowadzać własnej
Język Erlang powstał w latach osiemdziesiątych minio-
nego wieku, jego pierwsza wersja została wydana w 1986 Rysunek 1. Strona domowa języka Erlang
roku. Jednak większą popularność zdo-
bywa ostatnio, jako język do budowy
rozproszonych i wydajnych aplikacji.
Warto się zapytać o przykładowe aplika-
cje opracowane w Erlangu, jedną z nich
jest program Wings3D, czyli modeler 3D
cieszący się dużą popularnością. W cało-
ści został opracowany w Erlangu. Dobrym
przykładem jest także serwer Yaws, czy-
li serwer WWW także oparty o Erlanga.
Stosowany jest także na Facebooku.
Generalnie należy powiedzieć, że Er-
lang to język do tworzenia aplikacji cza-
su rzeczywistego, może być stosowany
w bankowości, telefonii, a także jako
język programowania ogólnego. Jedną
z ciekawszych możliwości jest możli-
wość aktywnej podmiany kodu w trakcie
działania aplikacji bez konieczności jej
wyłączania.
Biblioteka języka Erlang oferuje także
zestaw funkcji ułatwiających tworzenie
aplikacji o nazwie OTP. Pakiet ten ułatwia
tworzenie i zarządzanie rozproszonymi

40 / 1 . 2012 . (1)  /


kompilacji. W przypadku dystrybucji opar-
tych o Debiana, czyli także Ubuntu, wy-
starczy z konsoli, będąc użytkownikiem
root, wydać polecenie:
apt-get install erlang
w przypadku Fedory polecenie jest
następujące:
yum install erlang
Naturalnie możemy korzystać z instalato-
rów graficznych, bez konieczności odwoły-
wania się do trybu konsoli.
Jeśli posiadamy MacOS, to korzystamy
ze zbioru repozytoriów np: MacPorts albo
Homebrew, instalacja, podobnie jak w Li-
nuxach, sprowadza się do polecenia:
Rysunek 2. Wings3D, edytor modeli 3D napisany za pomocą
brew install erlang języka Erlang
albo
port install erlang
W przypadku systemu Windows należy instalator Erlan-
ga ściągnąć ze strony domowej. Najnowsza wersja to
R15B01, więc będzie to plik o nazwie otp_win32_R15B01.
exe. Po jego ściągnięciu i instalacji otrzymujemy kom-
pletne środowisko do pracy z językiem Erlang. Obecny
jest także pakiet wxErlang, czyli biblioteka do obsługi
GUI. W przypadku instalacji Erlang, w systemach Linux
czy MacOS, warto upewnić się, czy pakiet wxErlang został
zainstalowany, np. dla MacPorts należy wydać polecenie
o postaci:
port install erlang +wxwidgets
aby zainstalować obsługę dla GUI. Może też się okazać,
że trzeba będzie samodzielnie przeprowadzić kompilację
Erlanga. Dokładne informacje jak to zrobić można odszu-
kać w dokumentacji.
Ponieważ praca z poziomu konsoli z pewnością nie jest
przyjazna dla użytkownika początkującego, to warto za-
tem postarać się o instalację środowiska Eclipse oraz od-
powiedniej wtyczki (o nazwie Erlide), która ułatwi naukę
i tworzenie pierwszych programów w Erlangu.
Jeśli dokonaliśmy instalacji Erlang'a np. w środowisku
Windows (należy zwrócić uwagę, aby poszczególne na-
zwy katalogów nie zawierały spacji, z tego też powodu
lepiej nie instalować Erlanga do katalogu Program Files),
to instalacja jest bardzo prosta, sprowadza się do urucho-
mienia środowiska Eclipse, następnie z menu Help wybie-
ramy opcję Install new software..., w oknie dialogowym
wpisujemy adres http://erlide.org/update, a następnie
wybieramy moduły Erlanga do instalacji, a po kilku chwi-
lach zgadzamy się na restart środowiska Eclipse. Po
ERLANG - JĘZYK INNY NIŻ C++ CZY JAVA
ponownym uruchomieniu musimy skonfigurować środo-
wisko startowe Erlanga, co zrobimy, wybierając z Win-
dow, Preferences, Erlang opcję Installed runtimes. Po
tej czynności warto raz jeszcze zamknąć i ponownie uru-
chomić Eclipse i można zakładać nasz pierwszy projekt.
Trzeba jeszcze dodać, iż Erlide pozwala na konfigurację
procesu uruchamiania projektu, możemy więc wskazać
moduł główny i predykat startowy, co pozwoli na wygod-
ne testowanie aplikacji.
PODSTAWY ERLANGA – TYPY
DANYCH
Programy w języku Erlang mają zupełnie inną składnię
niż programy tworzone w typowych językach programo-
wania jak Java czy C++. Wynika to naturalnie z faktu, iż
Erlang to język oparty o język Prolog, gdzie dodatkowo
szeroko są wykorzystywane funkcyjne techniki progra-
mowania. Oznacza to, iż będzie trzeba zmienić sposób
myślenia o programach, jakie się tworzy w Erlangu, a to
nie jest wbrew pozorom zadanie łatwe, szczególnie jeśli
długo pisaliśmy programy w tradycyjnych językach struk-
turalnych i obiektowych.
Erlang jednak posiada rozbudowany aparat do tworze-
nia tzw. programów sekwencyjnych, a więc podobnych co
do idei do programów pisanych w Javie czy C++, co tylko
ułatwia tworzenie własnych programów.
Do podstawowych pojęć występujących w Erlangu na-
leżą oczywiście liczby całkowite, liczby zmiennoprzecin-
kowe, przykładowo:
12, -234, 16#AB5E, 2#1001010, $A, 3.14, 3.34E-5
Należy dodać, że np. 2#1001010 to zapis liczby w postaci
dwójkowej, ogólnie można bowiem pisać B#VAL, gdzie B
/ www.programistamag.pl / 41
 JĘZYKI PROGRAMOWANIA
to baza, a VAL to wyrażenie liczbowe w odpowiedniej ba-
zie. Zapis $A oznacza w tym konkretnym przypadku kod
Ascii litery A. Ważnym pojęciem są także tzw. atomy, czyli
ciągi znaków, np.:
abcd, ciag_oddzielony_podkreśleniami, 'ciąg
w apostrofach'
Atomy mogą reprezentować różnego rodzaju przydat-
ne stałe, np. oznaczające typy komunikatów bądź typy
danych.
Liczby i napisy możemy organizować w tzw. krotki. Jest
to rodzaj struktury, w której liczba pól w danym przypad-
ku jest ściśle określona, np.:
{osoba, 'Imię', 'Nazwisko', 12}
Pierwszy element wymienionej krotki może być wykorzy-
stywany do sprawdzania, czy badana krotka istotnie re-
prezentuje dane o osobie.
Kolejny element to listy, które w odróżnieniu od krotek
mogą zmieniać dynamicznie zawartość. Pewną wadą Er-
langa jest fakt, iż ciąg znaków objęty cudzysłowami także
jest listą. Przykłady list są następujące:
[12, 34, 34, xyz, lla]
[abc, {osoba, 'Imię','Nazwisko', 12}, 23]
”napis który jest listą”
Lista to podstawowa struktura danych w Erlangu, więc
nieraz będziemy do niej wracali. Połączenie krotek i list
tworzy tzw. typy złożone, co pozwala na tworzenie drzew,
szczególnych odmian list, a także typu zbiorowego o za-
chowaniu zgodnym z matematycznym pojęciem zbioru.
Ostatnim elementem dotyczącym typów danych są
zmienne. Wzorem języka Prolog, nazwa zmiennej rozpo-
czyna się od dużej litery. Natomiast, wartość zmiennej
można nadać tylko raz, gdyż raz przypisanej wartości nie
można zmienić do końca obowiązującego zasięgu zmien-
nej. Jest to typowe rozwiązanie dla języka Prolog czy też
języków funkcyjnych i zawsze sprawia dużo kłopotów, je-
śli dotychczas programowaliśmy tylko i wyłącznie w ję-
zykach obiektowych bądź strukturalnych. Podobnie jak
w Prologu mamy zmienną anonimową oznaczoną sym-
bolem _ (podkreślenie). Stosowana jest wtedy, gdy dana
wartość nie jest dla nas istotna, jednakże chcemy zazna-
czyć jej obecność.
CZAS NA PIERWSZY PROGRAM
Listing 1 zawiera nasz pierwszy program w Erlangu, choć
tak naprawdę nie jest to pełny program, a jedynie zbiór
predykatów (nazywanych także procedurami), czyli tzw.
moduł. Pierwsza linia to nazwa modułu; powinna być taka
sama jak nazwa pliku. Następnie słowem export określamy
listę symboli publicznych, widocznych dla innych użytkowni-
ków naszego modułu. Zapis silnia/1 oznacza, że funkcja sil-
nia z jednym argumentem będzie udostępniona publicznie.
42 / 1 . 2012 . (1)  /
Co znajdziemy w pudełku z Erlangiem?
Po instalacji środowiska Erlang nie otrzymujemy tylko i wy­
łącznie samego kompilatora oraz biblioteki standardowej.
Pierwszą grupą bibliotek, na jaką trzeba zwrócić uwagę
jest pakiet OTP, czyli framework do budowy rozproszonych
aplikacji.
Dostępna jest także baza danych czasu rzeczywistego Mne­
sia, oraz dostęp do baz danych w standardzie ODBC. Obecny
jest także pakiet Orber, czyli implementacja CORBY w Erlangu.
Mamy także pakiet dialyser do statycznej analizy kodu. Warto
zajrzeć do katalogu lib po instalacji Erlanga, bowiem w tym
katalogu zainstalowane zostały dodatkowe biblioteki, w tym
także pakiet wxErlang używany przez nas do budowy GUI.
W naszym pierwszym przykładzie mamy definicję
funkcji silnia w dwóch odsłonach. W pierwszej odsłonie
mamy typową rekurencyjną definicję funkcji silnia, gdzie
w pierwszej kolejności określamy wartość funkcji silnia
dla zera (definicja kończy się średnikiem):
silnia(0) -> 1;
Natomiast druga linia naszej funkcji to krok rekurencyjny,
zgodny z matematyczną definicją funkcji silnia:
silnia(N) -> N * silnia(N-1).
Jak widać w tym przypadku definicja kończy się kropką,
co oznacza koniec procedury silnia. Poprzednio kończyli-
śmy średnikiem, bowiem wymieniony został tylko jeden
z przypadków. Jest to nieco inne podejście niż w Prologu,
gdzie poszczególne przypadki definicji danej procedury
były kończone kropką.
Funkcję silnia możemy zdefiniować też w nieco inny
sposób, wykorzystując strażnika wartości, w przypadku
rekurencyjnym powinniśmy napisać, iż wartość N zawsze
jest większa niż zero:
silnia2(N) when N > 0 -> N * silnia2(N-1).
Uruchomienie naszej funkcji silnia wymaga od nas uru-
chomienia interpretera Erlanga. Interpreter uruchamia-
my w tym katalogu, w którym znajduje się plik źródłowy
przyklad1.erl. Następnie należy dokonać kompilacji w na-
stępujący sposób (na końcu należy dopisać kropkę koń-
czącą wyrażenie Erlanga):
c(przyklad1).
Po kompilacji zobaczymy komunikat ok, i możemy spraw-
dzić działanie np. funkcji silnia:
przyklad1:silnia(10).
Listing 1 zawiera także predykat pole do obliczenia pola
powierzchni kwadratu oraz koła. Obliczenie pola kwadratu
jest realizowane w następujący sposób:
 ERLANG - JĘZYK INNY NIŻ C++ CZY JAVA

Rysunek 3. Ilustracja rekurencyjnego obliczania długości listy i odwracania

kolejności elementów na liście

Długość listy Zmiana kolejności elementów na liście

len([1,2,3,4]) = len([1 | [2,3,4]) reverse([1|2,3], []) =>
= 1 + len([2 | [3,4]]) reverse([2,3], [1|[]])
= 1 + 1 + len([3 | [4]]) reverse([2|3], [1]) =>
= 1 + 1 + 1 + len([4 | []]) reverse([3], [2|[1])
= 1 + 1 + 1 + 1 + len([]) reverse([3|[]], [2,1]) =>
= 1 + 1 + 1 + 1 + 0 reverse([], [3|[2,1]])
= 1 + 1 + 1 + 1 reverse([], [3,2,1]) =>
= 1 + 1 + 2 [3,2,1]
= 1 + 3
= 4

przyklad1:pole({kwadrat,7.67}). Powtórzenie zmiennej na samym końcu oznacza, że war-

Warto w tym miejscu spróbować zdefiniować kilka dodat-
kowych przykładów dla innych figur, pomoże to poznać
składnię języka Erlang, która jest inna niż w tradycyjnych
językach typu C++ czy Java.
Listing 1. Pierwszy program, moduł w Erlangu
tość tej zmiennej stanie się wartością całego wyrażenia.
Tak prosta operacja pozwala na implementację dowolnej
innej operacji na liście, np. obliczenie długości listy jest
realizowane w następujący sposób:
len([]) -> 0;
len([_|T]) -> 1 + len(T).

-module(przyklad1). Pierwsza linia to przypadek dotyczący długości listy pu-

-export([silnia/1, silnia2/1, pole/1]).
stej, czyli wielkość jest równa naturalnie zero, natomiast
silnia(0) -> 1; wartością dłuższej listy jest jedność plus długość listy bez
silnia(N) -> N * silnia(N-1). głowy. Za pomocą rekurencji możemy obliczyć długość
listy, poszczególne etapy pokazuje także Rysunek 3.
silnia2(0) -> 1;
silnia2(N) when N > 0 -> N*silnia2(N-1). Innym przykładem jest odwrócenie kolejności elemen-
tów na liście, co realizujemy w następujący sposób:
pole({kwadrat, Bok}) ->
Bok * Bok; reverse(L) -> reverse(L, []).
reverse([H | R], RL) -> reverse(R, [H | RL]);
pole({kolo, Promien}) ->
3.14159265 * Promien * Promien; reverse([], RL) -> RL.

pole(Other) ->
{invalid_object, Other}. Poszczególne etapy tego procesu można zaobserwować
ponownie na Rysunku 3. Istnieje też możliwość odczyta-
nia dwóch elementów z początku, np. pisząc:
GŁOWA I OGON, CZYLI LISTA
[A,B|C]=[1, 2, 3, 4, 5].

Listy stanowią najważniejszą strukturę danych w języku

Erlang. Z listą związane jest pojęcie głowy, czyli pierw-
szego elementu listy, oraz ogona, stanowiącego pozostałe
elementy. Jeśli lista ma tylko jeden element, to można
powiedzieć, iż ma tylko głowę, a ogon jest pusty. Ope-
racja rozdziału na głowę i ogon to podstawowa operacja,
jaka jest wykonywana na liście. Operacja ta została ozna-
czona pionową kreską, np. odczytanie głowy jest realizo-
wane jako:
[ G | _ ] = [1, 2, 3, 4, 5], G.
Znak podkreślenia oznacza, że wartość ogona nas nie in-
teresuje, i podobnie w tym przypadku, ale tym razem to
głowa jest pomijana:
[ _ | O ] = [1, 2, 3, 4, 5], O.
zmienna A zostanie powiązana z wartością 1, zmienna
B z wartością 2, natomiast zmienna C zgodnie z oczeki-
waniami z resztą listy [3,4,5]. Przytoczone przypadki to
tzw. technika dopasowanie wzorca, jest ona szeroko sto-
sowana w programach pisanych w Erlangu, jednakże ze
względu na brak miejsca nie będziemy szerzej omawiać
tego zagadnienia.
O listach warto by jeszcze napisać bardzo dużo, ale
wymienimy jeszcze tylko dwie dodatkowe funkcje z bo-
gatych zasobów Erlanga: lists:keymember oraz lists:key-
delete. Zadaniem pierwszej funkcji jest sprawdzenie na
liście krotek, obecności takiej krotki, która na wskazanej
pozycji zawiera podany element. Natomiast keydelete
usuwa z listy krotki zawierające podany element na wska-
zanej pozycji. Te dwie funkcje będziemy wykorzystywać
do zarządzania listą użytkowników w jednym z następ-
nych przykładów.

/ www.programistamag.pl / 43
 JĘZYKI PROGRAMOWANIA

Krótko i szybko, czyli sortowanie

Algorytm sortowania szybkiego zawsze jest podawany jako przykład zawartości opisu algorytmu w językach funkcyjnych.
W przypadku Erlanga jest podobnie, co potwierdza poniższy kod:

-module(przyklad2).
-export([qsort/1]).

qsort([]) -> [];

qsort([Pivot|Rest]) ->
{Smaller, Larger} = partition(Pivot, Rest,[],[]),
qsort(Smaller) ++ [Pivot] ++ qsort(Larger).

partition(_,[], Smaller, Larger) -> {Smaller, Larger};

partition(Pivot, [H|T], Smaller, Larger) ->

if H =< Pivot -> partition(Pivot, T, [H|Smaller], Larger);
H > Pivot -> partition(Pivot, T, Smaller, [H|Larger])
end.

Idea programu jest identyczna do opisu sortowania szybkiego, wybiera się pewien element (tzw. pivot), a następnie przerzuca
się elementy większe i mniejsze przed lub za tym wybranym elementem. W Erlangu wykorzystujemy naturalnie listy i operację
podziału na głowę i ogon. Przemieszczenie elementów jest realizowane przez procedurę partition, natomiast qsort dzieli, a na­
stępnie łączy posortowane fragmenty listy.

ODWROTNA NOTACJA POLSKA Jest ona odpowiedzialna za konwersję ciągu znaków do

Nasza pobieżna wiedza o listach wystarczy, aby zre-
alizować bardziej ciekawy przykład, a będzie to kalku-
lator w tzw. odwrotnej notacji polskiej. W tym zapisie
argumenty zawsze poprzedzają operatory, czyli zamiast
2+5 napiszemy 2 5 + albo zamiast 1+2-5 napiszemy
np. 1 2 + 5 -. W obliczeniach wykorzystuje się stos,
bowiem możemy umieszczać na stosie wielkości liczbo-
we, i w momencie otrzymania odpowiedniego operatora
odczytać odpowiednią ilość argumentów i wykonać ope-
rację, a następnie umieścić obliczoną wielkość na stosie.
Krótko mówiąc, opracowanie tego typu kalkulatora w Er-
langu to łatwe zadanie, bowiem jak widać Listing 2 jest
dość krótki.
Mamy tylko jeden predykat o nazwie calc, którego ar-
gumentem jest ciąg znaków do analizy. Jednakże zde-
finiowano także inne przypadki calc odpowiedzialne za
realizację obliczeń, np. linia:
calc("+", [L1,L2|R]) -> [L2+L1|R];
zgodnie z oczekiwaniami realizuje sumę dwóch pierw-
szych elementów na liście, a wynik jest wstawiany po-
nownie na listę. Podobnie pozostałe operatory czy funk-
cje, np. w linii:
calc("sin", [L1|R]) -> [math:sin(L1)|R];
pobieramy jeden argument i obliczamy wartość funkcji
sin i wstawiamy obliczoną wielkość do listy. Ważną rolę
pełni też linia:
calc(L, R) -> [read(L)|R].
wartości liczbowej, a wykonuje to predykat read, zdefinio-
wany w dalszej części Listingu 2. Wykorzystujemy funkcję
string:to_float odpowiedzialną za właściwą konwersję.
Jak widać, analizę tego programu można rozpocząć od
środka, choć naturalnie analiza listy z argumentami roz-
poczyna się od następującej linii:
calc(L) when is_list(L) ->
[R] = lists:foldl(fun calc/2, [],
string:tokens(L, " ")), R.
w której to predykat calc przyjmuje tylko jeden argument
i jest to lista z poleceniami do wykonania. Pierwsze za-
danie w tym predykacie to sprawdzenie funkcją is_list,
czy argument jest listą, jeśli tak jest, to odczytywane są
z listy poszczególne argumenty i realizowane obliczenia.
To zadanie jest dwuetapowe. W pierwszej kolejności wy-
korzystywana jest funkcja string:tokens, której zadaniem
jest zmiana ciągu znaków na listę składającą się z sym-
boli, w naszym przypadku będzie to polegać na tym, iż
ciąg znaków np. 10 20 + zostanie zamieniony na listę
[10, 20, ”+”]. W drugim etapie elementy z listy są prze-
kazywane za pomocą funkcji foldl do wskazanego predy-
katu, czyli omówionego wcześniej przypadku predykatu
calc z dwoma argumentami. Realizacja obliczeń to efekt
działania lists:foldl. Funkcja ta działa w taki sposób, iż
poszczególne elementy listy są kolejno wstawiane do po-
danej funkcji, jednakże brane są także pod uwagę wyni-
ki, co pozwala np. obliczyć wartość funkcji silnia z piątki
w taki sposób:
lists:foldl(fun(X, P) -> X * P end, 1,
[1,2,3,4,5]).

44 / 1 . 2012 . (1)  /


W przypadku naszego kalkulatora poszczególne wywoła-
nia calc modyfikują listę z obliczeniami.
Listing 2. Kalkulator dla odwrotnej notacji polskiej
-module(rpn).
-export([calc/1]).
calc(L) when is_list(L) ->
[R] = lists:foldl(fun calc/2, [],
string:tokens(L, " ")), R.
calc("+", [L1,L2|R]) -> [L2+L1|R];
calc("-", [L1,L2|R]) -> [L2-L1|R];
calc("*", [L1,L2|R]) -> [L2*L1|R];
calc("/", [L1,L2|R]) -> [L2/L1|R];
calc("^", [L1,L2|R]) -> [math:pow(L2,L1)|R];
calc("sin", [L1|R]) -> [math:sin(L1)|R];
calc(L, R) -> [read(L)|R].
read(L) ->
case string:to_float(L) of
{error,no_float} -> list_to_integer(L);
{F,_} -> F
end.
NADAWCY I ODBIORCY WIADOMOŚCI
Przekazywanie komunikatów to jeden z elementów, za
który można polubić programowanie w Erlangu. W na-
szym następnym przykładzie zbudujemy bardziej skom-
plikowany przykład, gdzie zaprogramujemy prosty komu-
nikator podobny w swej idei choćby do Gadu-Gadu, ale
w pierwszej kolejności zrealizujemy bardziej elementarny
przykład, a jego treść zawiera Listing 3.
Początek naszego programu rozpoczyna się od proce-
dury start. W pierwszej linii tej procedury powołujemy
nowy proces, który realizuje kod procedury loop. Zada-
niem loop jest odbieranie dwóch typów komunikatów.
Pierwszy komunikat składa się z dwóch elementów:
{From, Msg}
Zmienna From odpowiada za nadawcę, natomiast Msg
stanowi treść wiadomości. Po odebraniu takiej wiadomo-
ści jest ona przesyłana z powrotem do nadawcy:
From ! {self(), Msg},
a procedura loop jest ponownie, dzięki rekurencji, uru-
chamiana. Drugi komunikat stop, zgodnie ze swoją na-
zwą, zatrzyma działanie loop, ponieważ nie pojawia się
kolejne rekurencyjne wywołanie tej pętli.
Nic więcej o procedurze loop nie da się powiedzieć,
toteż warto wrócić do start. Po uruchomieniu procesu za
pomocą spawn, otrzymaliśmy jego identyfikator. Możemy
teraz, wykorzystując operator !, przesłać komunikat np:
Pid ! {self(), hello}
Procedura loop odczyta ten komunikat jako {From, Msg},
bowiem mamy nadawcę oraz treść wiadomości, w na-
szym przypadku będzie to tzw. atom o postaci hello. Po
ERLANG - JĘZYK INNY NIŻ C++ CZY JAVA
wysłaniu komunikatu za pomocą receive czekamy na ko-
munikat zwrotny w tym samym formacie {From, Msg},
a po jego otrzymaniu za pomocą io:format wyświetlamy
na konsoli prosty komunikat. Jednak nasz proces z pro-
cedurą loop nadal jest aktywny, możemy go wyłączyć,
przekazując komunikat stop.
Jak widać, jest to bardzo prosty przykład, jednakże jest
to już aplikacja rozproszona. Możemy, do czego zachęcam,
moduł loop umieścić w innym module, a procedura start
nadal będzie posiadać podobną postać, przy czym spawn
będzie naturalnie odnosił się do innego modułu. W nieco
inny sposób będzie trzeba utworzyć nowy proces.
Listing 3. Przekazywanie komunikatów
-module(echo).
-export([start/0, loop/0]).
start() ->
Pid = spawn(echo, loop, []),
Pid ! {self(), hello},
receive
{Pid, Msg} -> io:format("echo: ~w~n",[Msg])
end,
Pid ! stop.
loop() ->
receive
{From, Msg} ->
From ! {self(), Msg},
loop();
stop -> true
end.
wxERLANG, OKNA I PRZYCISKI
Zanim krótko opiszemy przykład udający Gadu-Gadu, po-
trzebne będzie GUI do naszej aplikacji. Listing 4 przedsta-
wia przykładowe okno zrealizowane w pakiecie wxErlang,
który jest portem biblioteki wxWidgets do środowiska
Erlang. W przypadku Windows zawsze mamy dostęp do
tego pakietu, inne systemy mogą od nas wymagać insta-
lacji dodatkowych pakietów.
Początek Listingu 4 jest podobny jak w naszych po-
przednich przykładach, choć polecenie:
-compile(export_all).
zgodnie z oczekiwaniami udostępnia wszystkie procedury
znajdujące się w module, natomiast:
-include_lib("wx/include/wx.hrl").
dołącza definicje różnego rodzaju stałych przydatnych
podczas tworzenia programów korzystających z GUI.
Mamy jeszcze definicje stałych:
-define(ABOUT, ?wxID_ABOUT).
albo:
-define(ID_BUTTON, 2005).
/ www.programistamag.pl / 45
 JĘZYKI PROGRAMOWANIA

Stałe te będą przez nas wykorzystywane podczas wykry-
wania zdarzeń i tworzenia widgetów. Program z Listingu 4
ma trzy procedury. Pierwsza start uruchamia naszą apli-
kację, setup tworzy interfejs, natomiast loop jest odpo-
wiedzialna za przetwarzanie komunikatów.
W całym procesie tworzenia menu nie wykorzystujemy
żadnych specjalnych technik programowania, utworzenie
menu Plik, które zawiera jedną opcję Plik, to następujące
polecenia:
MenuBar = wxMenuBar:new(),
File = wxMenu:new(),
wxMenuBar:append(MenuBar, File, "&Plik"),
Poszczególne polecenia rozdzielamy przecinkiem, trzeba
zwrócić uwagę na nakazanie obsługi komunikatów, co ro-
bimy w następujący sposób:
wxFrame:connect(Frame, command_menu_selected),
wxFrame:connect(Frame, close_window).
Str ="Prosty przykład w wxErlang.",
MD = wxMessageDialog:new(Frame, Str,
[{style, ?wxOK bor ?wxICON_INFORMATION},
{caption, "O Programie"}]),
wxDialog:showModal(MD),
wxDialog:destroy(MD),
Powyższe linie to typowy kod sekwencyjny, co pozwala
na łatwe wdrożenie się do pisania programów w Erlangu,
gdyż możemy tworzyć oprogramowanie przynajmniej na
początku w sposób dobrze znany, bez konieczności stoso-
wania rozwiązań wyłącznie funkcyjnych bądź też progra-
mowania w logice.
Nie trzeba też okien mozolnie projektować bezpo-
średnio poprzez tworzenie kodu, możemy utworzyć po-
trzebne elementy interfejsu w postaci plików w formacie
XRC. Pakiet wxErlang obsługuje pliki XRC, więc warto
skorzystać z tej możliwości, oszczędność czasu będzie
znacząca.

Listing 4. Okno i menu w pakiecie wxErlang

Dopiero teraz pętla loop będzie otrzymywać odpowied-
nie komunikaty. Obsługa komunikatów jest zgodna -module(wxex2).
-compile(export_all).
z językiem Erlang, czyli mamy blok receive, gdzie defi-
niujemy poszczególne typy komunikatów. Obsługa wyj- -include_lib("wx/include/wx.hrl").
ścia po wyborze z menu opcji Wyjście przedstawia się
-define(ABOUT, ?wxID_ABOUT).
następująco: -define(EXIT, ?wxID_EXIT).

#wx{id=?EXIT, event=#wxCommand{type=command_menu_ start() ->

selected}} -> S=wx:new(),
wxWindow:close(Frame, []) Frame = wxFrame:new(S, ?wxID_ANY, "Okno"),
setup(Frame),
wxFrame:show(Frame),
loop(Frame),
Listing 4 zawiera jeszcze obsługę drugiego komunikatu, wx:destroy().
gdzie wyświetlane jest okno dialogowe „O Programie”.
setup(Frame) ->
Utworzenie takiego okna, jego wyświetlenie, a następnie MenuBar = wxMenuBar:new(),
usunięcie jest realizowane w następujący sposób: File = wxMenu:new(),

Rysunek 4. Projekt głównego okna programu do przekazywania komunikatów opracowany w DialogBlocks

46 / 1 . 2012 . (1)  /


Help = wxMenu:new(),
wxMenu:append(Help, ?ABOUT, "O programie"),
wxMenu:append(File, ?EXIT, "Koniec"),
wxMenuBar:append(MenuBar, File, "&Plik"),
wxMenuBar:append(MenuBar, Help, "P&omoc"),
wxFrame:setMenuBar(Frame, MenuBar),
wxFrame:createStatusBar(Frame),
wxFrame:setStatusText(Frame, "Witamy w naszym
programie!"),
wxFrame:connect(Frame, command_menu_selected),
wxFrame:connect(Frame, close_window).
loop(Frame) ->
receive
#wx{id=?ABOUT, event=#wxCommand{}} ->
Str ="Prosty przykład w wxErlang.",
MD = wxMessageDialog:new(Frame, Str,
[{style, ?wxOK bor ?wxICON_INFORMATION},
{caption, "O Programie"}]),
wxDialog:showModal(MD),
wxDialog:destroy(MD),
loop(Frame);
#wx{id=?EXIT, event=#wxCommand{type=command_
menu_selected}} ->
wxWindow:close(Frame, [])
end.
SERWER I KLIENT DO POGADUSZEK
Nasz ostatni przykład, czyli aplikacja do wymiany komu-
ników pomiędzy osobami, ma niestety zbyt duży kod źró-
dłowy, aby w pełni go opisać i zaprezentować. Jednakże
pierwsze zadanie polega na zaprojektowaniu okna dia-
logowego. Rysunek 4 przedstawia projekt naszego okna
dialogowego wykonany w programie DialogBlocks. Ponie-
waż Erlang jak na razie nie ma żadnego dodatkowego
programu wspomagającego projektowanie okien dialogo-
wych, to trzeba skorzystać z dodatkowego oprogramowa-
nia. W kodzie źródłowym okno zostało zaprojektowane
ręcznie, ale zawsze można skorzystać z plików XRC.
Idea wykorzystania naszego programu jest następują-
ca: należy uruchomić serwer, a następnie na pozostałych
węzłach uruchamiane jest oprogramowanie klienta łączą-
ce się z naszym serwerem.
Nasza aplikacja składa się z dwóch modułów: talkergui
odpowiedzialnego za GUI oraz talker. Ten drugi moduł to
modyfikacja aplikacji do przekazywania komunikatów,
jaką można odszukać w dokumentacji do Erlanga. Naj-
ważniejsze procedury są następujące:
start_server/0, server/1, logon/2, getuserlist/0,
logoff/0, message/2
Pierwsza start_server jest uruchamiana tylko raz, na
węźle serwera. Aby opisywany program działał, trzeba
uruchomić interpreter z nadaną nazwą dla uruchomione-
go węzła np. w taki sposób:
erl -sname w0
ERLANG - JĘZYK INNY NIŻ C++ CZY JAVA
Jednakże niezbędne jest wprowadzenie jednej zmiany
w pliku talker.erl. Należy go dopasować do używanej
przez nas sieci, a dokładniej zmienić nazwę hosta na od-
powiedni. Jeśli nasz host nosi nazwę pc0, a węzeł Erlanga,
na którym zostanie uruchomiony serwer, to w0, to pro-
cedura server_node_name posiada następującą postać:
server_node_name() ->
w0@pc0.
Po tej poprawce możemy skompilować i uruchomić ser-
wer oraz program do GUI:
c(talker).
c(talkergui).
talker:start_server().
Pozostali użytkownicy uruchamiają interpreter Erlanga na
węzłach o innych nazwach - muszą mieć dostęp do skom-
pilowanych plików talker.beam oraz talkergui.beam. W ich
przypadku wystarczy, jeśli uruchomią tylko sam program
z GUI: talkergui:start()., gdyż talker.erl jest już skompilo-
wany oraz posiada poprawne odniesienie do serwera.
Użytkownik modułu talker, a w naszym przypadku bę-
dzie to moduł talkergui, (choć można moduł talker uży-
wać bezpośrednio z poziomu konsoli) korzysta również
z procedur logon do zalogowania się na serwer, message
do przekazania wiadomości do innego użytkownika,
getuserlist do pobrania listy wiadomości oraz logoff do
wylogowania się z serwera. W procedurach logon i log­
off wykorzystujemy m.in. metodę lists:keymember do
sprawdzania, czy dany użytkownik jest zalogowany.
Pozostaje tylko jeden problem. Jeśli obsługa komuni-
katów jest realizowana przez inny moduł, a środowisko
GUI również jest zdefiniowane w innym module, to w jaki
sposób przekazać odebraną wiadomość? Naturalnie, trze-
ba wykorzystać komunikaty Erlanga. W obsłudze klienta,
po odebraniu komunikatu, wykonujemy dwie czynności,
na konsole kierujemy odpowiedni komunikat, oraz wy-
syłamy komunikat do ParentModule, a zmienna ta repre-
zentuje masz moduł GUI (talkergui):
{message_from, FromName, Message} ->
io:format("Wiadomosc od ~p: ~p~n", [FromName,
Message]),
ParentModule ! {message_from, FromName, Message}
W talkergui procedura loop odbiera komunikat z wiado-
mością w następujący sposób:
{message_from, FromName, Message} ->
CtrlWin = wxWindow:findWindowById(?ID_TEXT_BOX,
[{parent, Frame}]),
wxTextCtrl:appendText(wx:typeCast(CtrlWin,
wxTextCtrl), FromName ++ ": " ++ Message ++ "\n"),
loop(Frame);
W ten sposób udało się nam dość elegancko skomuni-
kować program pracujący w trybie konsoli ze środowi-
skiem GUI, a trzeba powiedzieć, iż ten sposób komunika-
/ www.programistamag.pl / 47
 JĘZYKI PROGRAMOWANIA

Rysunek 5. Testowanie aplikacji do wymiany komunikacji

cji może odbywać się także w rzeczywistym środowisku
sieciowym.
PODSUMOWANIE
Na zakończenie warto jak zawsze zachęcać do dalszych
poszukiwań, wbrew pozorom o Erlangu znajdziemy sporo
informacji, także różnego rodzaju przykłady, więc warto
poszukać. Trzeba także wspomnieć o dwóch książkach:
pierwsza to „Erlang Programming” oraz druga „Erlang and
OTP in Action”, które stanowią podręczniki dla tego języ-
ka programowania. Erlang, o czym nie było okazji wspo-
mnieć, jest rozwiązaniem, które łatwo łączy się z innymi
językami, np. C/C++. Dlatego jeśli planujemy tworzyć
serwer działający w ramach naszej platformy, to może
warto rozważyć zastosowanie Erlanga, który znakomicie
nadaje się do tworzenia serwerów ze względu na obec-
ność systemu komunikatów. Choć tak naprawdę jest to
język uniwersalny i można w nim tworzyć wydajne aplika-
cje rozwiązujące różnego rodzaju problemy. Wydaje się,
iż jest również łatwiejszy do stosowania niż np. Prolog,
ze względu na dużą liczbę typowych konstrukcji sekwen-
cyjnych, co tylko ułatwia tworzenie pierwszych własnych
programów w Erlangu.

W SIECI: Główna strona języka Erlang: http://www.erlang.org/

PP Serwis o programowaniu w języku Erlang: http://trapexit.org/
PP Nauka Erlanga dla początkujących: http://learnyousomeerlang.com/
PP Podręcznik Wiki o programowaniu w Erlangu: http://en.wikibooks.org/wiki/Erlang_Programming
PP Komercyjne wsparcie dla zastosowań Erlanga: http://www.erlang-solutions.com
PP Przykłady programów w Erlangu dot. sortowania szybkiego: http://en.literateprograms.org/Quicksort_(Erlang)
PP Dodatek do edytora Emacs umożliwiający pracę z Erlangiem: https://github.com/massemanet/distel
PP Wtyczka dla Eclipse pozwalająca na wygodną pracę ze środowiskiem Erlang: http://erlide.org/

Marek Sawerwain redakcja@programistamag.pl

Autor jest pracownikiem naukowym Uniwersytetu Zielonogórskiego, na co dzień

zajmuje się teorią kwantowych języków programowania, a także tworzeniem
oprogramowania dla systemów Windows oraz Linux. Zainteresowania: teoria
języków programowania oraz dobra literatura.

48 / 1 . 2012 . (1)  /

 KOMIKS

/ www.programistamag.pl / 49
 PROGRAMOWANIE GRAFIKI
Wojciech Sura

Direct3D – podstawy
Użytkownicy komputerów często nie mają pojęcia, jak wielka moc obliczeniowa
drzemie w ich karcie graficznej. Współczesne procesory mają zwykle dwa lub cztery
rdzenie, gdy tymczasem liczba rdzeni przeciętnej karty graficznej przekracza już licz-
bę 200. Ujarzmienie takiej potęgi daje programiście bardzo dużo możliwości – i co
ciekawe, wcale nie jest takie trudne.

N
a początku zadajmy sobie proste pytanie: czy na trójkąt. Nie ma mowy o czymś takim, jak bryła, punkt
ekranie komputera można wyświetlić trójwymia- zaczepienia, kamera czy światło. Każdy z tych elemen-
rową grafikę? Mnogość gier komputerowych i pro- tów musi zostać - w oparciu o mechanizmy Direct3D
gramów typu CAD sugerowałaby odpowiedź twierdzącą, - zaimplementowany przez programistę.
a przecież jest dokładnie na odwrót: ekran komputera Przyjrzyjmy się więc, jak – z perspektywy programisty
może wyświetlić tylko płaskie obrazy. Innymi słowy to, co – wygląda proces renderowania grafiki 3D.
widzimy na ekranie, jest tylko dwuwymiarową projekcją
pewnej trójwymiarowej sceny. Właściwą analogią może RENDERING PIPELINE
być zdjęcie lub film, które utrwalają trójwymiarowy świat
na dwuwymiarowym medium. Proces renderowania podzielony jest na etapy, ułożone
Wykonanie takiej projekcji nie jest, wbrew pozorom, wzdłuż specyficznej ścieżki, nazywanej rendering pipeli-
aż tak trudne - dosyć powiedzieć, że już w latach 80' po- ne. Niektóre etapy realizowane są w całości przez kartę
wstawały gry na Atari, które potrafiły w czasie rzeczywi- graficzną, inne mogą być częściowo kontrolowane przez
stym zobrazować pewien prymitywny, ale już trójwymia- programistę, zaś jeszcze inne muszą zostać przygotowa-
rowy świat. Jednak w przypadku bardziej skomplikowanej ne przez niego w całości. Ponadto, niektóre elementy tej
i realistycznej grafiki rośnie znacząco złożoność algoryt- ścieżki są opcjonalne, zaś obecność innych jest wyma-
mów ją renderujących, co dramatycznie odbija się na ich gana do prawidłowego przeprowadzenia całego procesu.
wydajności. Osiągnięcie kilkudziesięciu klatek na sekun- Rysunek 1 przedstawia najprostszą ścieżkę zawierającą
dę dla sceny składającej się z tysięcy trójkątów wypeł- wszystkie elementy wymagane do wyrenderowania sceny
nianych setkami megabajtów tekstur tylko przy pomocy zawierającej trójwymiarowe bryły. Proces renderowania
procesora (nie zapominając o logice gry) jest nierealne.
Aby rozwiązać ten problem, powstały dedykowane układy Rysunek 1. Ścieżka renderowania
wspomagające renderowanie grafiki, montowane na kar-
tach graficznych. W ten sposób karta, która pierwotnie
służyła tylko do wyświetlania obrazu na ekranie, stała się
w pewnym momencie niewielkim centrum obliczeniowym
zdolnym wykonywać ogromne ilości operacji zmienno-
przecinkowych w czasie rzeczywistym.
Architektura jednostek obliczeniowych karty graficz-
nej rożni się znacząco od architektury procesora. Aby nie
zmuszać programisty do uczenia się programowania na
zupełnie nową platformę i jednocześnie by standaryzo-
wać dostęp do mocy obliczeniowej karty graficznej, po-
wstały specjalne API - pomosty, pośredniczące pomiędzy
aplikacją a sterownikiem i umożliwiające wykorzystanie
możliwości karty podczas programowania w języku wyż-
szego poziomu. Jednym z takich pomostów jest właśnie
Direct3D, składnik biblioteki DirectX rozwijanej przez
Microsoft.
Z perspektywy programisty, Direct3D jest rendererem,
czyli mechanizmem odpowiedzialnym za przetworzenie
i wyświetlenie na ekranie przekazanych mu danych. API
Direct3D jest stosunkowo niskopoziomowe: dosyć za-
uważyć, ze najbardziej zaawansowanym obiektem, z któ-
rym mamy do czynienia podczas pracy z tą biblioteką jest

50 / 1 . 2012 . (1)  /


może być wywołany kilkukrotnie dla pojedynczej klatki,
a programista ma pełną kontrolę nad tym, w jaki sposób
będą składane wyniki kolejnych przebiegów.
Input assembly
Pierwszym etapem ścieżki renderowania jest input assem­
bly (IA). W etapie tym dostarczone przez programistę
dane konwertowane są na prymitywy – czyli punkty, od-
cinki i trójkąty – a następnie w takiej postaci przekazywa-
ne są do dalszego przetworzenia w późniejszych etapach.
Struktura danych pojedynczego wierzchołka nie jest na-
rzucona – programista ma pełną dowolność w zdefiniowa-
niu, jakie dane i jakiego typu będą przekazywane karcie
graficznej. Zazwyczaj jednak są to: pozycja wierzchołka,
jego normalna oraz kolor lub współrzędne tekstury.
Etap input assembly jest w całości realizowany przez
renderer, a programista – poza dostarczeniem danych
– nie ma nad nim żadnej kontroli.
Vertex shader
W kolejnym kroku dane przygotowane przez input as-
sembly przetwarza vertex shader i przy nim zatrzymamy
się na chwilę dłużej.
Shadery są podstawową siłą roboczą, która umożliwia
karcie graficznej osiągnięcie tak dużej wydajności. Sha-
der jest niewielkim programem napisanym w jednym ze
specjalnie do tego celu przygotowanych języków progra-
mowania (w DirectX jest to HLSL - High Level Shading
Language; innymi są na przykład GLSL czy Cg), kompi-
lowanym dla karty graficznej. Kompilacja shadera może
zostać wykonana w trakcie pracy programu (w takiej sy-
tuacji kody shaderów muszą być przechowywane wraz
z programem, co jest – wbrew pozorom – dosyć popu-
larną techniką, spotykaną nawet w niektórych grach), ale
możliwe jest też skorzystanie ze wcześniej skompilowa-
nych kodów binarnych.
Shadery pracują w architekturze SIMD (Single Instruc-
tion, Multiple Data): program shadera jest jeden, ale jest
on wywoływany niezależnie i równolegle na dużej ilości
danych. W praktyce, jeśli dwie różne bryły mają być prze-
tworzone w różny sposób, stosuje się jedno z dwóch roz-
wiązań: shader może pracować w trybie warunkowym,
regulowanym dodatkowymi danymi przekazanymi razem
z wierzchołkami bryły lub po prostu klatka może być ren-
derowana kilkoma przebiegami, z wykorzystaniem róż-
nych shaderow dla różnych elementów sceny podczas
każdego przebiegu.
Główna funkcja (entry point) vertex shadera dosta-
je na wejściu pojedynczy wierzchołek w takim forma-
cie, jaki programista zdefiniował w fazie IA. Rezultatem
zwracanym przez ten shader powinien również być do-
kładnie jeden wierzchołek. Także i tu programista może
zdefiniować, jaka będzie struktura danych, którą shader
przekaże dalej, ale z jednym wyjątkiem: pośród zwraca-
nych danych należy wyróżnić jedną strukturę, która bę-
dzie interpretowana później przez mechanizmy Direct3D
DIRECT3D – PODSTAWY
Rysunek 2. Rasteryzacja
jako pozycja wierzchołka. Jest to informacja konieczna do
przeprowadzenia kolejnych etapów obliczeń.
Zadaniem vertex shadera jest wykonanie przekształ-
ceń geometrycznych na wierzchołku: przesunięciu, ob-
róceniu lub przeskalowaniu, a następnie obliczeniu jego
docelowego położenia na dwuwymiarowej projekcji. Choć
może to brzmieć mało zachęcająco, to na szczęście bi-
blioteka Direct3D w parze z językiem HLSL udostępniają
dużo narzędzi pozwalających zrealizować te zadania przy
naprawdę niewielkim wysiłku ze strony programisty.
W Direct3D programista jest zobligowany do samo-
dzielnego napisania vertex shadera i włączenia go do
ścieżki renderowania.
Rasteryzator
Zaraz po zakończeniu pracy vertex shadera uruchamia-
ny jest rasteryzator. Jego zadanie polega na przeanalizo-
waniu prymitywów przygotowanych przez vertex shader
i obliczenie, które piksele ekranu zostaną przez nie zajęte.
Zadanie to jest realizowane przez kartę graficzną, jednak
przed rozpoczęciem renderowania programista ma moż-
liwość ustalić tryb pracy rasteryzatora – uzyskując w ten
sposób różne rezultaty w zależności od potrzeb.
Pixel shader
Każdy z pikseli obliczonych przez rasteryzator przetwa-
rzany jest przez kolejny shader – z racji swojego zadania
zwany pixel shaderem. Pixel shader, podobnie jak vertex
shader, musi zostać napisany przez programistę, skompi-
lowany i umieszczony w rendering pipeline przed rozpo-
częciem renderowania. Dane wejściowe do pixel shadera
wymagają jednak dodatkowego wyjaśnienia.
Pixel shader przyjmuje jako parametr dane dokładnie
takiego samego typu, jakie zostały zwrócone przez ver-
tex shader. Jak pamiętamy, oprócz wymaganej pozycji
wierzchołka, programista ma pełną dowolność w zdefi-
niowaniu informacji generowanych przez vertex shader.
Kłopot polega jednak na tym, że vertex shader jest w sta-
nie jasno zdefiniować wartości tylko dla wierzchołków da-
/ www.programistamag.pl / 51
 PROGRAMOWANIE GRAFIKI


 być również na przykład bitmapa).





 w to uwierzyć, cały proces, począwszy od fazy IA aż do OM






 może zrobić jeszcze większe wrażenie, jeśli uświadomimy








 gdy tymczasem programista może skorzystać jeszcze z kil-











 o mocy obliczeniowej karty graficznej.
Rysunek 3. Interpolacja wykonana przez rasteryzator
nego prymitywa (trójkąta, odcinka), natomiast brakuje
informacji na temat punktów znajdujących się w jego
wnętrzu. W tym miejscu ratuje nas jednak rasteryzator,
który w trakcie przetwarzania prymitywów inteligentnie
interpoluje wartości zwrócone przez vertex shader w taki
sposób, że pixel shader otrzymuje komplet danych dla
każdego wygenerowanego piksela.
Przyjmijmy na przykład, że vertex shader oprócz współ-
rzędnych wierzchołka zwraca dodatkowo zdefiniowaną
przez programistę pojedynczą liczbę rzeczywistą oraz że
pierwszemu wierzchołkowi została przyporządkowana
wartość 0.0, drugiemu – 0.5, trzeciemu zaś 1.0. Rysunek
3 obrazuje, w jaki sposób wartość ta będzie interpolowana
dla wszystkich pikseli zrasteryzowanego trójkąta.
Output merger
Ostatnim etapem ścieżki renderowania jest output mer-
ger (OM), którego zadaniem jest końcowa obróbka efek-
tów pracy vertex i pixel shadera.
Jednym z kluczowych zadań output mergera jest wy-
konanie tzw. depth testu – testu głębi. Direct3D nie daje
żadnej kontroli nad tym, w jakiej kolejności przetwarzane
będą przekazane mu prymitywy. Co więcej, część proce-
su renderowania wykonywana jest równolegle, więc może
się zdarzyć, że w jednej klatce pewien prymityw będzie
przetworzony wcześniej, zaś w innej – później. Powsta-
je tu więc problem związany z zasłanianiem się prymity-
wów: może zdarzyć się, że element, który znajduje się
bliżej, zostanie pechowo wyrenderowany wcześniej niż
inny, znajdujący się dalej od obserwatora, i w efekcie zo-
stanie przez niego zasłonięty.
Output merger rozwiązuje ten problem poprzez zasto-
sowanie tzw. z-buffera. Jest to bufor o rozmiarach rów-
nych wyjściowemu obrazowi, w którym output merger
rejestruje odległość wszystkich renderowanych piksli.
W momencie, gdy jeden z nich pokrywa się z innym, mer-
ger jest w stanie zweryfikować, który z nich znajduje się
bliżej i to on zostaje zapisany jako wynikowy, eliminując
w ten sposób opisany wcześniej problem.
Oprócz testowania głębi, output merger odpowiedzial-
ny jest też za mieszanie kolorów (w przypadku, gdy pi-
kesle są półprzezroczyste) oraz zapisywanie wyników
52 / 1 . 2012 . (1)  /
w docelowym buforze (zwykle na ekranie, ale może to
Output merger kończy proces renderowania. Choć trudno
wywoływany jest przynajmniej raz dla każdej klatki – czyli
nawet kilkadziesiąt razy na sekundę! Szybkość obliczeń
sobie, że opisana ścieżka zawiera tylko wymagane kroki,
ku dodatkowych rodzajów shaderów, które można włączyć
do rendering pipeline. Daje to całkiem niezłe wyobrażenie
TROCHĘ MATEMATYKI
Aby prawidłowo oprogramować cały proces renderowa-
nia, nie można obejść się bez wiedzy o przekształceniach,
które w jego trakcie powinny zostać wykonane.
Układ współrzędnych
Direct3D operuje na kartezjańskim układzie współrzęd-
nych, w którym każdy punkt ma trzy współrzędne: x, y
i z. Osie OX i OY pokrywają się z osiami OX i OY ekranu
komputera, zaś oś OZ jest osią dodatkową, wskazującą w
głąb monitora. Istnieje ważna różnica pomiędzy oboma
układami: w układzie ekranowym wartości współrzędnej
y rosną w dół, natomiast Direct3D korzysta z matema-
tycznej definicji, gdzie wartości te rosną w górę. Niezgod-
ność kierunków osi y obu układów nie stanowi jednak
większego problemu, ponieważ to Direct3D jest odpowie-
dzialny za przeniesienie punktu z układu kartezjańskiego
do komputerowego, o czym za chwilę.
Czeka nas jednak jeszcze jedna niespodzianka – otóż
wbrew naszym oczekiwaniom, punkty przestrzeni opisywa-
ne są w Direct3D nie przez trzy, a przez cztery współrzęd-
ne. Jednak bez strachu: czwarta współrzędna (nazywana
w) wprowadzona została głównie po to, aby można było
wygodnie i szybko wykonywać przekształcenia, których
w przestrzeni trójwymiarowej w ten sposób zrealizować się
nie da. W praktyce rendererowi można przekazywać punk-
ty trójwymiarowe, a ten automatycznie przekształci je
w punkty czterowymiarowe, inicjując czwartą współrzędną
wartością 1.0. Taką też wartością powinien zainicjować tę
współrzędną programista, jeśli zdecyduje się na przekazy-
wanie rendererowi kompletu danych. Inne wartości mogą
spowodować nieprzewidziane zachowanie niektórych prze-
kształceń, więc należy je stosować z ostrożnością.
Macierze przekształceń są oczywiście również cztero-
wymiarowe (4x4).
Prześledźmy teraz, w jaki sposób przekształcane są
współrzędne wierzchołków w trakcie wykonywania ścieżki
renderowania.
Przekształcenia bryły
Bryły przechowywane są w pamięci zazwyczaj w tzw.
współrzędnych lokalnych. W każdej bryle wyróżniany
 DIRECT3D – PODSTAWY

jest pomocniczo pewien wirtualny punkt (nazywany za-

zwyczaj punktem zaczepienia), który staje się środkiem
układu współrzędnych bryły i to względem niego usta-

lane są współrzędne jej wierzchołków. Na przykład, je-

śli rozważymy jednostkowy sześcian, którego punkt za-
czepienia znajduje się w jego geometrycznym środku, to
wierzchołki rozpięte będą na współrzędnych (-0.5, -0.5,
-0.5); (0.5, 0.5, 0.5) (Rysunek 4). Dzięki takiej, a nie
innej organizacji danych możemy później umieścić ów
sześcian w dowolnym miejscu sceny, nakładając na jego
wierzchołki odpowiednie przekształcenia.
Załóżmy na przykład, że chcemy, aby środek rende-
rowanego sześcianu znalazł się w punkcie (1, 1, 1); wy-
starczy wówczas na wszystkie jego wierzchołki nałożyć
przekształcenie translacji (przesunięcia) o wektor (1, 1,
1), a sześcian znajdzie się dokładnie tam, gdzie chce-
my (Rysunek 5). Mechanizm ten przydaje się szczególnie
w przypadku, gdy jedną bryłę chcemy powielić i umieścić
na scenie w wielu miejscach naraz – wystarczy wówczas
przechować w pamięci tylko jedną jej definicję, ale rende-

rować ją wielokrotnie, używając za każdym razem innego
Rysunek 4. Współrzędne lokalne
przekształcenia.
Macierz przekształcenia, która przenosi współrzędne
wierzchołków bryły z układu lokalnego do układu świa-
ta (globalnego) nazywana jest macierzą świata (World
matrix) i zwykle jest nakładana na wierzchołek przed
wszystkimi innymi przekształceniami w vertex shaderze.



Projekcja perspektywiczna

Stajemy teraz przed głównym problemem całego proce-


su, czyli w jaki sposób przedstawić trójwymiarowy świat
na płaskim obrazie? Szukane przekształcenie, które trój-
wymiarowemu punktowi przyporządkowuje dwuwymia-

rowy odpowiednik, nosi miano projekcji, zaś najczęściej
stosowanym rodzajem projekcji jest projekcja perspek-
tywiczna, która w dużym stopniu odzwierciedla sposób,
w jaki normalnie postrzegamy świat.
W Direct3D przyjęto, że docelowym obszarem, w któ-
rym muszą znaleźć się wyniki ścieżki renderowania, jest
prostopadłościan rozpięty na przedziałach: [-1.0, 1.0]
na osi OX, [-1.0, 1.0] na osi OY oraz [0.0, 1.0] na osi
OZ. Tak wygenerowane dane są liniowo przekształcane
na współrzędne ekranowe, to znaczy punkt (-1.0, 1.0, Rysunek 5. Konwersja na współrzędne świata
0.0) zostanie przekształcony na lewy, górny piksel, punkt
(1.0, -1.0, 0.0) – na prawy dolny i tak dalej. Współrzędna
z nie odgrywa żadnej roli w tym przekształceniu, jednak tafli, która ograniczy obszar pola widzenia od tyłu (czer-
jest używana na przykład podczas testów głębi. Punkt, wony prostokąt na Rysunku 6). Z sześciu wspomnianych
który znajdzie się poza opisanym wcześniej obszarem, płaszczyzn otrzymamy ostrosłup ścięty (ang. perspective
nie jest wyświetlany. frustum), w którym zawierają się wszystkie obiekty, któ-
Jak więc działa projekcja perspektywiczna? re możemy obserwować przez naszą taflę. Idea projekcji
Wyobraźmy sobie, że stoimy gdzieś w plenerze, trzy- perspektywicznej polega na obserwacji, że wspomniany
mając przed sobą prostokątną, szklaną taflę (niebieski ostrosłup ścięty wraz z jego zawartością odpowiednimi
prostokąt na Rysunku 6). Kiedy popatrzymy na otacza- przekształceniami można sprowadzić do wymaganego
jący nas krajobraz przez narożniki tej tafli, wyznaczymy przez Direct3D prostopadłościanu (Rysunek 7).
tym samym cztery płaszczyzny, ograniczające pole wi- Przekształcenie to jest dosyć skomplikowane, jednak
dzenia. Aby wykonać projekcję perspektywiczną, potrze- ratują nas tutaj funkcje biblioteczne Direct3D, które na
bujemy jeszcze jednej płaszczyzny, równoległej do naszej bazie kilku parametrów generują odpowiednią macierz

/ www.programistamag.pl / 53
 PROGRAMOWANIE GRAFIKI

Rysunek 6. Pole widzenia obserwatora

Rysunek 7. Pole widzenia przekształcone w obszar

renderowania

Rysunek 8. W tym przypadku proporcje pola

widzenia projekcji perspektywicznej i okna są
takie same

Rysunek 9. Niezgodność proporcji

spowoduje zniekształcenia

54 / 1 . 2012 . (1)  /

 DIRECT3D – PODSTAWY

Przygotuj dane sceny do wyrenderowania Proces rende-

Dla każdej bryły (lub zestawu brył): rowania obrazu
Procesor

Przekaż do Direct3D informację o buforze z danymi bryły

Skonfiguruj etapy renderowania
Przekaż do Direct3D skompilowany vertex shader
Przekaż do Direct3D skompilowany pixel shader
Uruchom renderer
[Input Assembly]
Zbierz informacje o prymitywach do wyrenderowania
Dla każdego prymitywu:
Dla każdego wierzchołka prymitywu:
[Vertex Shader]
Karta graficzna

Przekształć wierzchołek ze współrzędnych lokalnych na globalne przy pomocy macierzy świata

Przekształć wierzchołek ze współrzędnych globalnych na współrzędne ekranowe przy pomocy macierzy projekcji
[Rasteryzacja]
Oblicz, które piksele zostaną zajęte przez prymityw
Dla każdego piksela:
[Pixel Shader]
Oblicz docelowy kolor piksla
[Output Merger]
Wykonaj test głębi i zapisz piksel w buforze wyjściowym.

przekształcenia, którą wystarczy nałożyć w vertex shade- Renderowanie w pigułce

rze na przetwarzane wierzchołki.
Konwersja na współrzędne ekranowe
Ostatnim etapem przetwarzania danych, w którym nie bierze
już udziału programista, jest wspomniane przed chwilą linio-
we przekształcenie współrzędnych punktów z prostopadło-
ściennego obszaru renderowania na współrzędne ekranowe.
Należy tu zauważyć pewien ważny fakt. Nikt nie pilnuje
automatycznie zależności pomiędzy prostokątem definiu-
jącym pole widzenia (niebieski prostokąt na rysunku 6),
a docelowym oknem (lub bitmapą), na którym rysowany
jest wynik całego procesu. W interesie programisty leży
więc, aby ich proporcje (to znaczy stosunki szerokości do
wysokości) były zachowywane – w przeciwnym razie ob-
raz rysowany w oknie będzie zniekształcony.
Poskładajmy teraz całą teorię w całość i zarysujmy
w pseudokodzie, jak wygląda prosty program rende-
rujący pojedynczą trójwymiarową scenę (na diagramie
powyżej).
NA KONIEC...
Opisany przeze mnie mechanizm dotyczy wprawdzie Di-
rect3D, jednak jego ogólne założenia są bardzo podobne
w przypadku innych rendererów (na przykład OpenGL).
Aby rozpocząć pisanie programów wykorzystujących
sprzętową akcelerację grafiki 3D, potrzeba jeszcze tyl-
ko wiedzy na temat API renderera, o czym postaram się
opowiedzieć w kolejnym artykule poświęconym podsta-
wom renderowania grafiki z udziałem Direct3D 11.

Wojciech Sura wojciechsura@gmail.com

Programista w firmie Optopol S.A. zajmującej się produkcją sprzętu i oprogramowania

do pozyskiwania, analizy i wizualizacji obrazów medycznych. Programuje od przeszło
dziesięciu lat w Delphi, C++ i C#, prowadząc również prywatne projekty.

reklama

CYBERCOM POLAND oferuje swoje usługi

w Polsce już od 15 lat. Główne obszary działań to
telekomunikacja, przemysł, media, bankowość
char[][] l = new char[3][]; i finanse, handel detaliczny oraz sektor publiczny.
while (true) { Specjalizuje się w rozwiązaniach internetowych,
l[0]=("Tworzymy innowacyjne rozwiązania B2B "+ bezpieczeństwa, usług mobilnych oraz teleko­
"na rynki UE od 2002 roku").toCharArray();
l[1]= "Android, JEE, Oracle, RoR".toCharArray(); munikacyjnych. Świadczy pełen zakres usług
l[2]= "Zapraszamy do wspołpracy!".toCharArray(); consultingowych i outsourcingowych, testowa­
log.severe("www.I"+l[1][1]+"f"+l[1][5]+l[1][1]+ nia oraz R&D dla dużych i średnich firm.
l[1][5]+l[0][0]+l[0][19]+".pl/l00p");
} www.cybercom.com/pl/
 PROGRAMOWANIE URZĄDZEŃ
Łukasz Górski

Wykorzystanie sensora Kinect

w systemie Windows
Sensor Kinect, umożliwiający interakcję z konsolą Xbox 360 za pomocą gestów i po-
leceń głosowych, zyskał wielką popularność i przychylne recenzje na rynku elektro-
niki użytkowej. Nie powinno więc dziwić, że firma Microsoft postanowiła rozszerzyć
bazę użytkowników opracowanej przezeń technologii. Wraz z opublikowaniem od-
powiedniego SDK dla systemu Windows możliwe stało się wykorzystanie tej techno-
logii również w oprogramowaniu działającym na komputerach osobistych. Co więcej,
1 lutego 2012 r. na rynek wypuszczona została nowsza wersja sensora, przeznaczo-
na do współpracy z systemem Windows, lepiej wspierana przez SDK i zawierająca
pewne ulepszenia firmware’u. Tym samym Microsoft tym bardziej podkreślił swoje
wsparcie dla rozwoju technologii NUI (Natural User Interface – naturalny interfejs
użytkownika) również w segmencie komputerów PC.

W
ramach artykułu wskażemy, w jaki sposób uzy-
skać dostęp do strumieni danych przesyłanych
przez sensor; nabytą wiedzę wykorzystamy do
zaimplementowania prostego programu analizującego
gesty oraz mowę użytkownika i pokażemy, jak wyko-
rzystać go do sterowania aplikacjami uruchomionymi na
komputerze – takimi, jak przeglądarka zdjęć czy program
prezentacyjny.
Wcześniej jednak wskażemy na możliwości techniczne
urządzenia.
BUDOWA I MOŻLIWOŚCI SENSORA
Generalnie w sensorze wyróżnić można następujące ele-
menty (por. rysunek 1):
1. Czteroelementowy zestaw mikrofonów – umożliwia
rejestrację dźwięku i lokalizację jego źródła w prze-
strzeni; mikrofony wyposażone są w funkcję redukcji
hałasu.
2. Emiter podczerwieni – generujący wiązkę promieni
podczerwonych, wykorzystywanych przez kamerę głę-
bokości (4) do pomiaru odległości obiektów znajdują-
cych się w polu widzenia sensora.
3. Kamera rejestrująca strumień wideo.
4. Kamera głębokości, opisana wyżej w pkt. 2.
Wskazane wyżej możliwości techniczne powodują, iż
programista ma dostęp do następujących strumieni
danych:
■■ strumień wideo – w rozdzielczościach 640x480 (RGB
i YUV) i 1280x960 (wyłącznie RGB),
■■ strumień głębi – pozwala pobrać informacje o odległo-
ści obiektów od sensora; Kinect identyfikować może te
znajdujące się w odległości od ok. 800 mm do 4000
mm (w wersji dla Windows – od ok. 400 mm, z pewny-
mi ograniczeniami),
■■ strumień danych szkieletowych – transmituje infor-
macje o położeniu wyróżnionych elementów ciała (jo-
ints w terminologii Kinect SDK) maksymalnie dwóch
osób (śledzenie aktywne). Elementy te przedstawia
rysunek 2. Dodatkowo sensor może udostępnić dane
o położeniu sylwetek czterech dodatkowych osób (bez
szczegółowych informacji o położeniu poszczególnych
joints – śledzenie pasywne). Funkcjonalność ta zwalnia
programistę z konieczności implementacji algorytmów
wykrywających, na podstawie strumieni wideo i głębi,
sylwetkę ludzką i dokonywania analizy jej położenia.
Pozwala to skupić się na implementacji rozwiązań re-
alizujących docelową funkcjonalność tworzonego przez
programistę oprogramowania,
■■ strumień danych audio – umożliwiający redukcję ha-
łasu, analizę źródła dźwięku i rozpoznawanie mowy
(wraz z Microsoft Speech SDK).
INSTALACJA SDK I KONFIGURACJA
ŚRODOWISKA
Przejdziemy teraz do praktycznej części artykułu. Czytel-
nicy chcący wypróbować prezentowane programy powin-
ni (oprócz oczywiście posiadania sensora Kinect – czy to
w wersji dla Xbox-a, czy to dla Windowsa) zainstalować
SDK, dostępne na stronie http://kinectforwindows.org.
Wykorzystanie SDK wymaga odpowiedniego skonfigu-
rowania środowiska programistycznego. Zadbać należy

56 / 1 . 2012 . (1)  /

 WYKORZYSTANIE SENSORA KINECT W SYSTEMIE WINDOWS
o dodanie do projektu referencji do zestawu Microsoft.
Research.Kinect. Odpowiednia biblioteka dynamiczna do-
myślnie znajduje się w folderze C:\Program Files\Micro-
soft SDKs\Kinect\v1.0\Assemblies.
Rysunek 3. Niezbędne referencje
PIERWSZY PROGRAM – STRUMIEŃ
WIDEO
Mając za sobą niezbędne przygotowania, możemy przejść
do prezentacji przykładów wykorzystania urządzenia.
Na samym początku pokażemy, w jaki sposób uzyskać
w aplikacji dostęp do strumienia wideo, implementując
następujące proste GUI:
Rysunek 4. Pierwszy program w działaniu
Interfejs wykorzystuje bibliotekę Windows Forms i składa
się z pojedynczej formy wraz z kontrolką PictureBox, któ-
rą nazwiemy videoStream.
Kod inicjujący w naszym wypadku wyglądał będzie tak,
jak pokazano w Listingu 1 (str. 59).
Rozpoczynamy od pobrania obiektu reprezentującego
sensor – z kolekcji KinectSensors, statycznego pola kla-
sy KinectSensor, reprezentującego wszystkie urządzenia
Kinect dostępne w systemie. Następnie inicjujemy stru-
mień danych wideo (ColorStream), a także dodajemy ob-
sługę zdarzenia AllFramesReady – wywoływanego, gdy
dostępna jest nowa ramka danych. Możliwe byłoby rów-
nież obsłużenie zdarzenia ColorFrameReady, związanego
wyłącznie ze strumieniem danych wideo.
Rozwiązanie oparte na zdarzeniach zalecane jest jako
zapewniające największą responsywność aplikacji; alter-
natywnie możliwe jest odpytywanie w pętli o zawartość
kolejnych ramek, korzystając z wywołań w rodzaju ki-
nect.ColorStream.OpenNextFrame(1000) – gdzie jako
argument podajemy czas oczekiwania na nowy zestaw
Rysunek 1.
Elementy sensora (źródło: J. Webb, J. Ashley, Beginning Kinect
Programming with the Microsoft Kinect SDK, wyd. Apress
2012, s. 10)
Rysunek 2.
Śledzone elementy (źródło: http://i.msdn.microsoft.com/dynimg/
IC539011.png)
danych. Obsługę strumienia wideo prezentuje Listing 2
(str. 59).
Na początku otwieramy ramkę wideo i sprawdzamy,
czy nie jest pusta. W wypadku bowiem, gdyby kod obsłu-
gujący zdarzenie działał zbyt powoli i nie nadążał z sukce-
sywną obsługą kolejnych zgłoszeń, zmienna image miała-
by wartość null.
Następnie tworzymy bufor, w którym zapisane zostaną
dane pochodzące ze strumienia wideo – i wypełniamy go.
W dalszej części konwertujemy „surowe” dane pochodzą-
ce z sensora do postaci bitmapy colorBitmap, odwracamy
(dane stanowią „lustrzane odbicie” rzeczywistych) i wy-
świetlamy w kontrolce videoStream.
DRUGI PROGRAM – STRUMIEŃ GŁĘBI
I DANYCH SZKIELETOWYCH
W następnym przykładowym programie pokażemy,
w jaki sposób uzyskać dostęp do danych z czujnika głę-
bi. GUI będzie analogiczne do poprzedniego i składać
/ www.programistamag.pl / 57
 PROGRAMOWANIE URZĄDZEŃ
się będzie z pojedynczej kontrolki PixtureBox o nazwie
depthStream:
Rysunek 5. Drugi program w działaniu
Obiekt będzie tym jaśniejszy, im bardziej oddalony będzie
od sensora. Sylwetki użytkowników oznaczane będą kolo-
rem, tło zaś prezentowane będzie w odcieniach szarości.
Dodatkowo – zaznaczone zostaną punkty ciała (joints)
śledzone przez sensor.
Kod inicjujący przedstawia się analogicznie do tego
z pierwszego programu (Listing 3).
Włączenie strumienia danych szkieletowych pozwoli
nie tylko zaznaczać śledzone punkty ciała, ale również
identyfikować sylwetki użytkowników w strumieniu głębi,
a co za tym idzie – odpowiednio je kolorować.
Kod obsługujący zdarzenie, dla jasności, podzielono na
dwie logiczne części, związane z obsługą odpowiedniego
strumienia. Zacznijmy od strumienia głębi.
Ze względu na konieczność zdekodowania danych, kod
jest nieco bardziej skomplikowany niż ten dla strumienia
wideo. Wygląda w sposób następujący (Listing 4).
Na początku wprowadzamy siedem barw bazowych,
identyfikujących tło i sześciu użytkowników. Nastę­pnie
definiujemy bitmapę, którą wyświetlać będziemy w kon-
trolce depthStream GUI programu, a także bufor na
strumień danych głębi. Pobieramy także informacje
o zakresie, w którym sensor jest w stanie identyfikować
oddalenie obiektów. W wypadku Kinecta konsoli Xbox
uzyskano przedział od 800 mm do 4000 mm. Następnie
otwieramy strumień i kopiujemy dane do bufora.
W tym miejscu kod nieco się komplikuje. Nie może-
my, jak w poprzednim programie, po prostu skopiować
danych z bufora do bitmapy, lecz musimy poddać je ob-
róbce. Każdy „piksel” danych strumienia głębi to poje-
dyncza dana typu short. Jej pierwszych 13 bitów zawie-
ra informacje o oddaleniu (w mm) punktu od sensora,
a ostatnie 3 – identyfikują piksele, które składają się na
sylwetkę użytkownika (każdy użytkownik ma przyznaną
liczbę od 1 do 7; 0 przeznaczone jest dla tła). Informacje
te wydobywamy w pętli i przechowujemy w zmiennych
distance i idx. Następnie sprawdzamy, czy odczytana
odległość zawiera się w zakresie śledzenia sensora i jeśli
tak – odpowiadający piksel wyjściowej bitmapy „cieniuje-
my” odpowiednią barwą.
58 / 1 . 2012 . (1)  /
Przystąpimy teraz do naniesienia na bitmapę punktów
położenia joints. Służy do tego następujący kod (zobacz
str. 60).
Otwieramy ramkę danych szkieletowych i również
sprawdzamy, czy nie jest pusta. Podobnie jak wyżej,
dane zapisane w ramce kopiujemy do bufora skeletons
– i iterujemy po zapisanych danych szkieletowych użyt-
kowników śledzonych aktywnie (w wypadku których pole
Track­ingState ma wartość SkeletonTrackingState.
Tracked). Zaznaczenie pozycji każdego joint na ekranie
wymaga skonwertowania pozycji ze współrzędnych 3D
(w ten sposób ich pozycja identyfikowana jest w strumie-
niu danych szkieletowych) na dwuwymiarowe współrzęd-
ne bitmapy. Służy do tego metoda MapSkeletonPoint-
ToDepth klasy KinectSensor. Wypisujemy pozycje tych
tylko joints, które znajdują się w polu widzenia sensora
i są przezeń śledzone (pole TrackingState o wartości Jo-
intTrackingState.Tracked).
Wreszcie, w ostaniej linii, (odwrócona) bitmapa wy-
świetlana jest w kontrolce PictureBox.
Dla porządku należy dodać, że obsługa zdarzeń
w osobnym wątku wykonania znacznie podniosła wydaj-
ność aplikacji na komputerze, na którym była testowana.
Nie stanowi to jednak istoty niniejszego artykułu, dlate-
go też część aplikacji związana z obsługą wątków została
pominięta.
TRZECI PROGRAM –
ROZPOZNAWANIE GESTÓW I MOWY
Wykorzystując powyższą wiedzę, przejść możemy do
implementacji zapowiedzianego na wstępie programu
rozpoznającego gesty. Niniejszy program ma chara­kter
przykładowy, toteż jego funkcjonalność będzie nieco
ograniczona: śledzić będziemy gesty wykonywane przez
prawą rękę; aplikacja rozpozna gest polegający na jej
przesunięciu w lewo i prawo (podobne gesty rozpoznawa-
ne są w interfejsach telefonów komórkowych jako „dalej”
i „wstecz”). Aby zbytnio nie komplikować kodu źródłowe-
go, zakładamy, że z sensora korzystać będzie pojedynczy
użytkownik, który nie będzie opuszczał jego pola widze-
nia. Dla prostoty pominiemy również kwestie związane
z architekturą aplikacji rozpoznającej gesty.
Czytelnik nie powinien mieć problemów z ominięciem
tych ograniczeń w swojej aplikacji. Bardziej rozbudowa-
ne przykłady w tym względzie znaleźć można w Interne-
cie – por. wykaz adresów na końcu niniejszego artykułu.
W tym wypadku inicjować musimy jedynie strumień
danych szkieletowych (Listing 6, str. 60).
Rozpoznawanie gestów założonych na wstępie niniej-
szego artykułu nie jest trudne. Dla zbadania, czy ręka
wykonała gest „dalej”, wystarczy sprawdzić, czy w ciągu
ostatnich dwóch sekund spełniono łącznie następujące
warunki:
■■ użytkownik przesuwał dłoń wyłącznie w prawo,
■■ na odległość co najmniej 40 cm,
■■ dłoń pozostawała stabilna w poziomie,
 WYKORZYSTANIE SENSORA KINECT W SYSTEMIE WINDOWS

Listing 1. Inicjalizacja strumienia wideo

KinectSensor kinect = KinectSensor.KinectSensors[0];

kinect.ColorStream.Enable(ColorImageFormat.RgbResolution640x480Fps30);
kinect.AllFramesReady += new EventHandler<AllFramesReadyEventArgs>(nui_AllFramesReady);
kinect.Start();

Listing 2. Obsługa strumienia wideo

ColorImageFrame image = e.OpenColorImageFrame();

if (image == null) return;
byte[] colorPixels = new byte[image.PixelDataLength];
image.CopyPixelDataTo(colorPixels);
Bitmap colorBitmap = new Bitmap(image.Width, image.Height, PixelFormat.Format32bppRgb);
BitmapData data = colorBitmap.LockBits(new Rectangle(0, 0, image.Width, image.Height), ImageLockMode.
WriteOnly, colorBitmap.PixelFormat);
IntPtr ptr = data.Scan0;
Marshal.Copy(colorPixels, 0, ptr, image.Width * image.Height * image.BytesPerPixel);
colorBitmap.UnlockBits(data);
colorBitmap.RotateFlip(RotateFlipType.RotateNoneFlipX);
videoStream.Image = colorBitmap;

Listing 3. Inicjalizacja strumieni głębi i danych szkieletowych

kinect = KinectSensor.KinectSensors[0];
kinect.DepthStream.Enable(DepthImageFormat.Resolution320x240Fps30);
kinect.SkeletonStream.Enable();
kinect.AllFramesReady += new EventHandler<AllFramesReadyEventArgs>(kinect_AllFramesReady);
kinect.Start();

Listing 4. Obsługa strumienia głębi

Color[] colors = { Color.White, Color.Red, Color.Green, Color.Blue, Color.Yellow, Color.Orange, Color.

Magenta };
Bitmap bitmap = new Bitmap(320, 240);
short[] bytes = new short[320 * 240];
int min = kinect.DepthStream.MinDepth,
max = kinect.DepthStream.MaxDepth;
var image = e.OpenDepthImageFrame();
if (image == null) return;
BitmapData bits = bitmap.LockBits(new Rectangle(0, 0, bitmap.Width, bitmap.Height), ImageLockMode.
WriteOnly, PixelFormat.Format32bppRgb);
image.CopyPixelDataTo(bytes);
unsafe
{
byte* pixels = (byte*)bits.Scan0.ToPointer();
for (int x = 0; x < bitmap.Width; x++)
for (int y = 0; y < bitmap.Height; y++)
{
short distance = (short)(bytes[x * 240 + y] >> DepthImageFrame.PlayerIndexBitmaskWidth);
int idx = bytes[x * 240 + y] & DepthImageFrame.PlayerIndexBitmask;
byte red = 0, green = 0, blue = 0;
if (distance != kinect.DepthStream.TooNearDepth && distance != kinect.DepthStream.
TooFarDepth && distance != kinect.DepthStream.UnknownDepth)
{
red = (byte)(colors[idx].R * (distance - min) / (max - min));
green = (byte)(colors[idx].G * (distance - min) / (max - min));
blue = (byte)(colors[idx].B * (distance - min) / (max - min));
}
pixels[x * 4 * 240 + y * 4] = blue;
pixels[x * 4 * 240 + y * 4 + 1] = green;
pixels[x * 4 * 240 + y * 4 + 2] = red;
}
}
bitmap.UnlockBits(bits);

/ www.programistamag.pl / 59
 PROGRAMOWANIE URZĄDZEŃ

Listing 5. Obsługa strumienia danych szkieletowych

SkeletonFrame skeletonFrame = e.OpenSkeletonFrame();

if (skeletonFrame == null) return;
Skeleton[] skeletons = new Skeleton[skeletonFrame.SkeletonArrayLength];
skeletonFrame.CopySkeletonDataTo(skeletons);
using (Graphics graphics = Graphics.FromImage(bitmap))
foreach (Skeleton skeleton in skeletons)
if (skeleton.TrackingState == SkeletonTrackingState.Tracked)
foreach (Joint joint in skeleton.Joints)
if (joint.TrackingState == JointTrackingState.Tracked)
{
DepthImagePoint point = kinect.MapSkeletonPointToDepth(joint.Position, kinect.DepthStream.
Format);
graphics.FillEllipse(Brushes.Red, point.X - 3, point.Y - 3, 7, 7);
}
bitmap.RotateFlip(RotateFlipType.RotateNoneFlipX);
depthStream.Image = bitmap;

Listing 6. Inicjalizacja programu rozpoznającego gesty

kinect = KinectSensor.KinectSensors[0];
kinect.SkeletonStream.Enable();
kinect.SkeletonFrameReady += new EventHandler<SkeletonFrameReadyEventArgs>(kinect_SkeletonFrameReady);
kinect.Start();

Listing 7. Klasa przechowująca historię położeń śledzonych punktów ciała

class Positions
{
public SkeletonPoint Hand { get; set; }
public SkeletonPoint HipCenter { get; set; }
public SkeletonPoint ShoulderCenter { get; set; }
public DateTime Time { get; set; }
}

Listing 8. Rejestrowanie położeń śledzonych punktów ciała

SkeletonFrame frame = e.OpenSkeletonFrame();

if (frame == null) return;
Skeleton[] skeletons = new Skeleton[frame.SkeletonArrayLength];
frame.CopySkeletonDataTo(skeletons);
var tracked = (from skeleton in skeletons where skeleton.TrackingState == SkeletonTrackingState.
Tracked select skeleton).FirstOrDefault();
if (tracked == null) return;
var position = new Positions { Hand = tracked.Joints[JointType.HandRight].Position,
HipCenter = tracked.Joints[JointType.HipCenter].Position,
ShoulderCenter = tracked.Joints[JointType.ShoulderCenter].Position,
Time = DateTime.Now };
if (_positions.Count == 90) { _positions.RemoveAt(0); }
_positions.Add(position);

if (IsSwypeRight())
{
_positions.Clear();
}
if (IsSwypeLeft())
{
_positions.Clear();
}

■■ przemieszczała się wyłącznie dłoń użytkownika; reszta
sylwetki pozostawała (względnie) nieruchomo.
W celu ich weryfikacji w programie rejestrować będziemy
dane z ostatnich 90 ramek danych szkieletowych. Prze-
chowamy je w następującej klasie (Listing 7).
Zapisujemy więc informacje o położeniu dłoni i reje-
strujemy czas, w którym położenie to zostało odczytane.
Dodatkowo przechowujemy informacje o pozycji miedni-
cy i górnej części tułowia – w celu sprawdzenia założenia
o stabilności całej sylwetki.
W funkcji obsługi zdarzenia wybieramy (jedyną) śle-
dzoną aktywnie sylwetkę i zapisujemy rejestrowane in-
formacje w liście _positions (Listing 8).
Sprawdzenie, czy wykonano gest, dokonywane jest
w metodach IsSwypeRight oraz IsSwypeLeft. Pierwsza
z nich prezentuje się następująco (Listing 9).
W powyższym kodzie za pomocą komentarzy oznaczo-

60 / 1 . 2012 . (1)  /

 WYKORZYSTANIE SENSORA KINECT W SYSTEMIE WINDOWS

Listing 9. Detekcja gestu

private bool IsSwypeRight()

{
if (_positions.Count == 0) return false;
Positions last = _positions.Last();
for (int i = _positions.Count - 2; i >= 0 && last.Time - _positions[i].Time <= TimeSpan.
FromSeconds(2); i--) //1
{
if (!(_positions[i + 1].Hand.X > _positions[i].Hand.X) || //2
!(Math.Abs(_positions[i].Hand.Y - last.Hand.Y) <= 0.1f) || //3
!(Math.Abs(_positions[i].HipCenter.X - last.HipCenter.X) <= 0.1f) || //4
!(Math.Abs(_positions[i].ShoulderCenter.X - last.ShoulderCenter.X) <= 0.1f)) //5
return false;
if (last.Hand.X - _positions[i].Hand.X >= 0.4f) //6
return true;
}
return false;
}

Listing 10. Reakcja na gesty

if (IsSwypeRight())
{
_positions.Clear();
SendKeys.Send("{RIGHT}");
}
if (IsSwypeLeft())
{
_positions.Clear();
SendKeys.Send("{LEFT}");
}

Listing 11. Inicjalizacja rozpoznawania mowy

var info = (from ee in SpeechRecognitionEngine.InstalledRecognizers() where ee.Id == "SR_MS_en-US_

Kinect_11.0" select ee).FirstOrDefault();
var engine = new SpeechRecognitionEngine(info.Id);
var gb = new GrammarBuilder();
gb.Culture = info.Culture;
gb.Append("rotate");
var directions = new Choices(new string[] { "left", "right" });
gb.Append(new SemanticResultKey("direction", directions));
engine.LoadGrammar(new Grammar(gb));
engine.SpeechRecognized +=new EventHandler<SpeechRecognizedEventArgs>(engine_SpeechRecognized);

Listing 12. Rozpoznawanie mowy

public void engine_SpeechRecognized (object sender, SpeechRecognizedEventArgs e)

{
if (e.Result.Confidence <= 0.8)
return;
if (""+e.Result.Semantics["direction"].Value == "left")
SendKeys.Send("^,");
else
SendKeys.Send("^.");
}

Listing 13. Inicjalizacja strumienia audio

var stream = kinect.AudioSource.Start();

engine.SetInputToAudioStream(stream,
new SpeechAudioFormatInfo(
EncodingFormat.Pcm, 16000, 16, 1,
32000, 2, null));

engine.RecognizeAsync(RecognizeMode.Multiple);

/ www.programistamag.pl / 61
 PROGRAMOWANIE URZĄDZEŃ
no miejsca, gdzie badane są wskazane na wstępie warun-
ki co do pozycji poszczególnych joints:
1. badamy ramki z ostatnich 2 sekund,
2. sprawdzamy, czy użytkownik przemieszczał prawą dłoń
wyłącznie w prawo,
3. sprawdzamy, czy dłoń pozostała stabilna w poziomie,
tj. nie przemieściła się o więcej niż o 10 cm,
4. sprawdzamy stabilność położenia punktu odpowiada-
jącego miednicy – również, czy nie przemieściła się
o więcej, niż o 10 cm,
5. badamy stabilność górnej części tułowia, analogicznie
do położenia miednicy,
6. ostatecznie: sprawdzamy, czy dłoń przesunięto na od-
ległość co najmniej 40 cm.
Łączne spełnienie wszystkich powyższych warunków
spowoduje, iż odczytany zostanie gest przesunięcia dło-
ni w prawo. Wszelkie wartości liczbowe powyżej zostały
dobrane eksperymentalnie. Kod dla gestu przesunięcia
w lewo będzie, oczywiście, analogiczny.
Pozostało jedynie wskazać, w jaki sposób wykorzystać
odczytane gesty. Proponuję zmodyfikować końcową część
funkcji obsługi zdarzenia SkeletonFrameReady w nastę-
pujący sposób (Listing 10, poprzednia strona).
Spowoduje to wysłanie do aktywnego okna zdarze-
nia odpowiadającego za naciśnięcie lewego lub prawego
klawisza kursora. Jeżeli aktywną aplikacją byłaby prze-
glądarka zdjęć, spowodowałoby to zmianę oglądanej fo-
tografii; w wypadku aktywnego PowerPoint’a – zmianę
aktualnego slajdu.
Przykład ten rozbudujemy teraz o możliwość rozpo-
znawania mowy – dodamy możliwość obracania aktualnie
oglądanego w przeglądarce zdjęć obrazka poprzez wyda-
nie głosowego polecenia „rotate left/right”.
W tym celu skorzystamy z biblioteki Microsoft Speech
Platform SDK w wersji 11, dostępnej bez opłat na stro-
nie firmy Microsoft. W tym miejscu należy zaznaczyć, że
większość źródeł wskazuje na konieczność skorzystania
z 32-bitowej wersji SDK; następujący przykład z powo-
dzeniem jednak współpracuje z jego 64-bitową odmianą.
Po zainstalowaniu biblioteki należy dodać do projek-
tu odpowiednią referencję, analogicznie jak w wypadku
SDK Kinecta. Odpowiedni plik DLL domyślnie dostępny
jest w następującej lokalizacji: C:\Program Files\Micro-
soft SDKs\Speech\v11.0\Assembly\Microsoft.Speech.dll.
Z biblioteki korzysta następujący kod (Listing 11, po-
przednia strona).
Łukasz Górski lukasz.gorski@gmail.com
Interesuje się zagadnieniami programowania równoległego i funkcyjnego. Na co dzień
korzysta z Pythona, Javy i C++. Posiada doświadczenie w pracy z rozwiązaniami firmy
Oracle
62 / 1 . 2012 . (1)  /
W pierwszej kolejności przygotowujemy silnik rozpo-
znawania mowy, opierając się na tym zainstalowanym już
w systemie, dostępnym dla języka angielskiego (polski
nie jest niestety dostępny), identyfikowanym przez ciąg
znaków „SR_MS_en-US_Kinect_11.0”. Następnie przygo-
towujemy strukturę gramatyczną rozpoznawanych przez
sensor poleceń. Wskazujemy, iż składać się one będą ze
słowa „rotate” oraz kierunku tego obrotu – alternatywnie
„left” lub „right”. Obsługa zdarzenia polegającego na
rozpoznaniu polecenia głosowego miała będzie miejsce
w metodzie engine_SpeechRecognized (Listing 12, po-
przednia strona).
Badamy najpierw poziom pewności, że dane polecenie
głosowe zostało w istocie rozpoznane. Jeżeli przekracza
on – dobrany doświadczalnie – poziom 80%, to przesyła-
my do systemu odpowiedni kod odpowiedzialny za obrót
obrazka, uzależniony od wskazanego przez użytkownika
kierunku.
Pozostaje jeszcze skonfigurowanie biblioteki Micro-
soft Speech do współpracy z sensorem – wskazanie, że
źródłem rozpoznawanego dźwięku jest strumień audio
Kinecta.
Uruchomienie strumienia następuje poprzez wywołanie
odpowiedniej metody: kinect.AudioSource.Start();
powinno ono nastąpić co najmniej cztery sekundy po
wywołaniu metody kinect.Start() (por. np. Listing
1) – dopiero bowiem po takim czasie Kinect gotowy jest
przesyłać dane audio. Następnie strumień ten wskazuje-
my jako źródłowy dla biblioteki Microsoft Speech i inicju-
jemy (asynchroniczne) rozpoznawanie mowy (Listing 13,
poprzednia strona).
Warto zauważyć, że – podobnie j/w – uruchomienie
rozpoznawania mowy w osobnym wątku wykonania zna­
cznie podnosi efektywność całej aplikacji.
ZAKOŃCZENIE
W artykule przedstawiono sposób uzyskania dostępu do
strumieni danych udostępnionych przez SDK. Czytelników
chcących pozyskać więcej informacji zachęcam do odwie-
dzenia adresów internetowych wymienionych w ramce
„W Sieci”. Polecam również dalsze eksperymentowanie
z urządzeniem.
„W SIECI”:
PP http://kinectforwindows.org
PP http://msdn.microsoft.com/pl-pl/library/hh428637.aspx
PP http://kinecttoolbox.codeplex.com/
 PRENUMERATA

Prenumerata - korzyści:
»» Prenumerata magazynu Programista to wygodny sposób na dostęp do aktualnej i przydatnej wiedzy dla specjalistów IT.
»» Nie wychodząc z domu będziesz otrzymywał czasopismo tradycyjną pocztą lub dostaniesz e-mail z informacją o
nowym wydaniu do pobrania.
»» Cena egzemplarza w prenumeracie jest niższa względem pojedyńczego numeru.
»» Prenumerując magazyn Programista zyskujesz czas i pieniądze.

Prenumerata dla firm

Zadbaj by w Twojej firmie specjaliści mieli dostęp do aktualnej wiedzy! W Prenumeracie dla firm możesz otrzymać:
»» Kilka egzemplarzy magazynu Programista na papierze, aby wszyscy członkowie zespołu mieli dostęp do czasopisma.
»» Licencje na wiele stanowisk do wydań elektronicznych (.pdf, ePub, .mobi).
»» Atrakcyjne rabaty.
»» Reklamę w magazynie.
W sprawie oferty prosimy o kontakt: prenumerata@programistamag.pl

ZAMAWIAM
CZAS TRWANIA PRENUMERATĘ OD
RODZAJ PRENUMERATY PRENUMERATY CENA BRUTTO NUMERU:
Wydanie drukowane Roczna 12 wydań 199,00 zł + 36 zł przesyłka*
Wydanie drukowane Dwuletnia 24 wydania 398,00 zł + 72 zł przesyłka*
Wydanie elektroniczne Roczna 12 wydań 99,00 zł
Wydanie elektroniczne Dwuletnia 24 wydania 198,00 zł
Dane zamawiającego i Imię i nazwisko:
adres wysyłki
Adres wysyłki:
e-mail:
Telefon:
Dla firm (faktura) Nazwa firmy:
Adres siedziby firmy:
NIP:
Prenumerata zostanie uruchomiona po zaksięgowaniu wpłaty na konto wydawcy:
Anna Adamczyk, ul.Dereniowa 4/47, 02-776 Warszawa,
Bank Pekao S.A. 34 1240 1125 1111 0010 2401 3333

Data i podpis zamawiającego:

*Do ceny wydań drukowanych doliczamy 3 zł za wysyłkę jednego egzemplarza

W przypadku pytań, napisz do nas: prenumerata@programistamag.pl

 INŻYNIERIA OPROGRAMOWANIA
Sławomir Sobótka

Domain Driven Design krok po kroku

Część II: Zaawansowane modelowanie DDD
– techniki strategiczne: konteksty i architektu-
ra zdarzeniowa
Modele nietrywialnych domen wymagają struktury. Struktury, która pomaga nam
okiełznać chaos. W zestawie technik DDD znajdują się podejścia strukturyzacji sys-
temu na każdym poziomie abstrakcji. Techniki DDD stanowią również „rusztowania
mentalne”, które prowadzą procesy myślowe modelarza w kierunku bardziej ade-
kwatnych modeli. W artykule zostaną przedstawione techniki destylacji domen, wy-
dzielania kontekstów, komunikacji pomiędzy kontekstami, porządkowania złożonych
kontekstów oraz na poziomie mikro – efektywnego modelowania Agregatów.

Plan serii stwową strukturę, która separuje elementy modelu wg

Niniejszy tekst jest drugim z serii artykułów mających na celu
szczegółowe przedstawienie kompletnego zestawu technik
modelowania oraz nakreślenie kompletnej architektury apli­
kacji wspierającej DDD.
Część 1: Podstawowe Building Blocks DDD;
Część 2: Zaawansowane modelowanie DDD – techniki stra­
tegiczne: konteksty i architektura zdarzeniowa;
Część 3: Szczegóły implementacji aplikacji wykorzystującej
DDD na platformie Java (dwa podejścia: Spring i EJB 3.1 oraz
JPA);
Część 4: Skalowalne systemu w kontekście DDD – architek­
tura CqRS;
Część 5: Kompleksowe testowanie aplikacji opartej o DDD;
Część 6: Behavior Driven Development – Agile drugiej ge­
neracji.
ich podatności na zmiany.
Na zakończenie naszych rozważań powrócimy do oma-
wianych w poprzedniej części Agregatów i zastanowimy
się nad ich granicami. Poznamy techniki efektywnego
modelowania granic Agregatów oraz typowe błędy.
DESTYLACJA CORE DOMAIN - KIEDY
NIE STOSUJEMY DDD
Stosowanie technik DDD wnosi pewien narzut w proce-
sie tworzenia oprogramowania. Narzut ten jest inwesty-
cją, która jednak nie zwraca się w każdym przypadku.
W zwiążku z tym na wstępie modelowania DDD określa-
my miejsca w systemie, w których stosujemy techniki
DDD, oraz miejsca, w których ich nie stosujemy.
Supporting Domain – świadomy dług techniczny

STRATEGICZNA STRUKTURYZACJA – Relatywnie proste domeny nie wymagają technik DDD

RÓŻNE SKALE, JEDEN CEL
„Wszystko jest na miejscu i wszystko ma swoje miejsce”
– cytat Benjamina Franklina jest chyba najlepszym pod-
sumowaniem strategicznych technik DDD.
Pierwszą decyzją, jaką podejmujemy podczas modelo-
wania z wykorzystaniem DDD, jest określenie tych miej-
sce w całej „rozciągłości” systemu, w których będziemy
stosować techniki DDD.
Kolejnym poziomem strukturyzacji jest wydzielenie ja-
snych granic Bounded Context – kontekstów, w których
obowiązują osobne modele.
Separacja modeli jest ze wszech miar pożyteczna, jed-
nak zwykle rodzi problem: domeny muszą ze sobą współ-
pracować. Zatem zastanowimy się, jak technicznie doko-
nać mapowania kontekstów. Poszczególne modele mogą
być wciąż złożone, dlatego nadamy im głębszą – war-
– ich modelowanie z definicji nie wymaga złożonego
procesu mentalnego. Możemy je z powodzeniem zaim-
plementować w uproszczonej (1,2 – warstwowej) archi-
tekturze. Zwykle okazuje się, że nad prostymi domenami
wykonujemy jedynie operacje CRUD (Create, Read, Upda-
te, Delete), zatem warto skorzystać z mnogości wyboru
framework'ów pozwalających generować niemal automa-
tycznie aplikacje klasy „przeglądarka do bazy danych”.
Te relatywnie proste domeny nazywamy Supporting
Domain. W tych miejscach systemu decydujemy się na
kompromisy jakościowe (jakość modelu, jakość kodu)
– świadomie zaciągamy dług techniczny.
Przykładowo w naszym systemie możemy zdecydować
się na wprowadzenie systemu komentarzy. Zakładając,
że jego działanie nie jest krytyczne dla powodzenia całe-
go przedsięwzięcia biznesowego, klasyfikujemy ten pod-
system jako Supporting Domain. Warto zwrócić uwagę,

64 / 1 . 2012 . (1)  /


że w innym kontekście podsystem komentarzy może być
krytyczny (ponieważ np. buduje zaufania) – wówczas
traktujemy go jako Core Domain.
Generic domain – modele domen bazowych
Pewne domeny są generyczne w stosunku do naszej głów-
nej domeny. Przykładowo tworząc system służący do han-
dlu zawartością multimedialną, nie będziemy skupiać wy-
siłku mentalnego, pracując nad modułem fakturowania.
Fakturowanie jest krytyczne (zależy nam na jakości tego
modułu), ale przede wszystkim nie stanowi ono głównej
wartości, oraz ponadto tego typu systemy istnieją na ryn-
ku (zarówno Open Source, jak i komercyjnym). Dlatego
też przykładowe fakturowanie możemy potraktować jako
Generic Domain. Z podsystemami zaliczanymi do Generic
Domains integrujemy się w taki sposób, aby ich modele
nie „przeciekały” do naszego głównego modelu.
Innym przykładem Generic Domain może być biblio-
teka do operowania na Grafach. Być może będziemy ją
wykorzystywać w Module Magazynowym, aby sugerować
najkrótsze ścieżki, jakimi należy się poruszać pomiędzy
regałami w magazynach, aby jak najszybciej skomple-
tować zamówienie. W tym przypadku nadbudowujemy
domenę Magazynu (regały, półki, korytarze) nad gene-
ryczną domeną grafów (węzły, ścieżki, algorytmy wyszu-
kiwania ścieżek).
Core Domain – miejsce dla DDD
Omówiliśmy rodzaje domen, dla których nie stosujemy
technik DDD. Techniki DDD mają zastosowanie (jako in-
westycja) w Core Domain. Core Domain to sfera logiki
biznesowej, która jest głównym powodem, dla którego
system powstaje. Być może model z Core Domain sta-
nowi przewagę systemu (klienta zamawiającego system)
nad konkurencją. W Core Domain inwestujemy czas na-
szych najlepszych ludzi – Developerów oraz Ekspertów
Domenowych. W DDD zakładamy, że modelowanie Core
Domain stanowi największe wyzwanie w cyklu produk-
cji systemu. Zakładamy również, że słaby model stanowi
wysokie ryzyko niepowodzenia przedsięwzięcia.
Podstawową techniką destylacji Core Domain jest
spisanie Dokumentu Wizji. Dokument ten powinien być
krótki (np. 1/2 A4), dzięki temu skłoni jego twórcę do
skupienia się na głównych (Core) założeniach, które zwy-
kle dokładnie mapują się na czynniki przewagi, czyli Core
Domain.
GRANICE BOUNDED CONTEXT –
GRANICE WSPÓLNEGO JĘZYKA
Drugim poziomem strukturyzacji modelu jest wydzielanie
Bounded Context – kontekstów, do których jest przypisa-
ny Ubiquitous Language. Przypomnijmy w tym miejscu:
istnienie „wspólnego języka”, którym posługują się wszy-
scy uczestnicy projektu – od Eksperta Domenowego po
Developerów - jest jednym z głównych założeń DDD.
DOMAIN DRIVEN DESIGN KROK PO KROKU
Modele odseparowane przez Bounded Context nie
mogą odnosić się do siebie wprost. Są to niezależne byty,
które mogą być rozwijane przez osobne zespoły. Oma-
wiane w dalszej części Wzorce Architektoniczne pozwa-
lają na hermetyzację modeli, która redukuje problemy
związane ze zmianami i pozwala na niezależne rozwijanie
modeli przez zespoły, które nie „wchodzą sobie w drogę”.
Projekt referencyjny (link w ramce „w sieci”) zawiera
3 przykładowe Bounded Context: Sales, CRM, Shipping.
W przypadku tego projektu BC odpowiadają modułom
systemu.
Granice kompetencji Ekspertów domenowych
W systemach o większej skali mamy często do czy-
nienia z sytuacją, gdzie korzystamy z wiedzy wie-
lu Ekspertów Domenowych. Eksperci ci specjalizują się
w hermetycznych domenach (sferach) wiedzy. Możliwość
komunikacji merytorycznej pomiędzy ekspertami jest
mocno ograniczona.
W kontekście naszego przykładowego modelu: pojęcie
„produktu” w Module Sprzedaży oznacza coś, co ma cha-
rakterystykę handlową, pewne atrybuty promocyjne, być
może jest powiązane z profilami behawioralnymi klientów.
Natomiast w Module Magazynowym jest to przedmiot,
którego główną cechą jest przykładowo to, że zajmuje
określoną przestrzeń na regałach i być może wymaga
specjalnego traktowania podczas transportu.
Jedynie ubóstwo naszego języka powoduje, że eksper-
ci domenowi socjalizujący się w sprzedaży i eksperci spe-
cjalizujący się w domenie magazynów używają podobnej
fali akustycznej, która brzmi „produkt”. Jednak na pozio-
mie znaczenia to brzmienie budzi zupełnie różne skoja-
rzenia – skojarzenia z pojęciami pojawiające się w umy-
śle jednego eksperta są w ogóle niedostępne dla umysłu
innego eksperta.
Zatem próba uogólnienia i „zsumowania” kilku mode-
li wynikających z wiedzy osób o rozłącznych kompeten-
cjach jest zajęciem karkołomnym. W DDD takie podejście
jest zaliczane do anty-wzorców i nazywa się Corporate
Model Anti-Pattern.
Jeżeli eksperci domenowi znający na wskroś swe spe-
cjalizacje nie są w stanie się porozumieć, to w jaki sposób
możemy sobie wyobrazić sytuację, w której developerzy
– nie znający zwykle żadnej z tych domen – mogą być
w stanie stworzyć wspólny model kilku domen...?
Granice słownictwa Ekspertów Domenowych z Ubiquitous
Language wyznaczają granice modeli - Bounded Context.
Techniki uwspólniania modeli
Część pojęć jest wspólna dla wszystkich Bounded Con-
text. Przykładowo klasa Money z poprzedniego artykułu
modeluje pojęcie, co do którego wszyscy Eksperci Dome-
nowi zgadzają się w każdym szczególe. Wspólne pojęcia
umieszczamy w tak zwanym Shared Kernel.
Inną techniką uwspólniania modeli jest podejście na-
zywane w DDD: Conformist. Polega na tym, że jeden
/ www.programistamag.pl / 65
 INŻYNIERIA OPROGRAMOWANIA
model jest zależnością do drugiego. Zmiany w jednym
modelu powodują „katastrofę” w drugim. Z tego wzglę-
du jest to podejście, którego rozważenie zaleca się w
przypadków projektów wspieranych przez zespoły
outsourcingowe.
WSPÓŁPRACA KONTEKSTÓW
– W KIERUNKU ARCHITEKTURY
ZDARZENIOWEJ
Modele domen wyznaczone przez Bounded Context są
hermetyczne – oznacza to, że pojęcia z jednego modelu
nie „wyciekają” do innych modeli. Jednak systemy mają
to do siebie, że ich składowe muszą współpracować.
W poprzedniej części artykułu wprowadziliśmy wstęp-
ny szkic warstwowej architektury aplikacji. Nad warstwą
logiki domenowej umieszczamy logikę aplikacji, modelu-
jącą Use Case/Sser Story/Serwisy SAO. Poniżej domeny
umieszczamy warstwę infrastruktury, która zawiera mię-
dzy innymi implementacje repozytoriów.
Zobaczmy, jak na bazie tych założeń możemy podejść
do komunikacji pomiędzy Bounded Contexts.
Rysunek 1. Podejścia architektoniczne do współpracy pomiędzy Bounded Context
66 / 1 . 2012 . (1)  /
Współpraca poprzez dane
W najbardziej podstawowym przypadku jeden BC po-
trzebuje pewnych danych z innego BC. W takim wypadku
komunikację możemy modelować poprzez Repozytoria.
Implementacja repozytorium w BC1 wywołuje Serwis
Aplikacyjny (de facto API) BC2. Innymi słowy API BC2
staje się źródłem danych w BC1. Pamiętajmy, że z za-
łożenia model domenowy nie „wycieka” ponad warstwę
Serwisów Aplikacyjnych. Zatem komunikacja musi nastę-
pować poprzez Obiekty Transferowe.
Dzięki takiemu podejściu uzyskujemy hermetyzację
modeli. Model domeny BC2 nie jest znany w dome-
nie BC1. Zespół pracujący nad BC2, publikując API,
„podpisuje kontrakt” ze „światem zewnętrznym” i od
tej pory szczegółem implementacyjnym jest sposób,
w jaki kontrakt ten jest spełniony. Dzięki temu model
domeny BC2 może rozwijać się niezależnie i we wła-
snym tempie.
Praktyka ta różni się w zasadniczy sposób od popular-
nego podejścia, w którym moduły „gmerają sobie nawza-
jem” w modelach danych.

Współpraca poprzez operacje
Innym przypadkiem współpracy BC jest wywołanie API
w celu wykonania pewnych operacji. Nie operujemy więc
wprost na modelu domenowym innego BC, a wywołujemy
zbudowane nad nim API. Jest to klasyczna praktyka, ale
wspominamy o niej dla zachowania kompletności.
Współpraca poprzez sygnały – Zdarzenia
biznesowe
Wywoływanie serwisów z innych BC wprowadza silny Co-
upling. W przypadku większej ilości współpracujących ze
sobą modułów skończymy z Architekturą o strukturze
klasycznego Spaghetti.
Klasyczną techniką Decouplingu jest wprowadzenie
modelu zdarzeń. Zdarzenia są jedną z technik Inversion
of Control – obok Dependency Injection i Aaspect Orien-
ted Programming. Musimy pamiętać jednak, że odwra-
cając kontrolę, jednocześnie ją tracimy. Zatem zdarzeń
używamy wówczas, gdy chcemy modelować współpracę,
gdzie nie zależy nam na kontroli kolejności, czasu ani re-
zultatu wykonania.
W DDD przy pomocy zdarzeń modelujemy istotne
z biznesowego punktu widzenia fakty, które zaszły w cy-
klu życia Agregatu.
Listing 1. Zgłoszenie zdarzenia w Bounded Context CRM w
Agregacie Customer
@Entity
public class Customer extends BaseAggregateRoot{
public enum CustomerStatus{
STANDARD, VIP, PLATINUM
}
@Enumerated(EnumType.STRING)
private CustomerStatus status;
public void changeStatus(CustomerStatus status){
if (status.equals(this.status))
return;
this.status = status;
eventPublisher.publish(
new CustomerStatusChangedEvent(
getEntityId(), status));
}
}
Listing 1 ilustruje przykład zgłoszenia zdarzenia przez
Agregat Customer w momencie zmiany jego statusu.
Klasa CustomerStatusChangedEvent jest nośnikiem in-
formacji o tym, który klient (ID) zmienił status. Mode-
lując zdarzenia, musimy podjąć decyzję o tym, jakie in-
formacje umieszczamy w klasach zdarzeń – w naszym
przykładzie jest to techniczne ID – być może lepszą de-
cyzją byłoby przeniesienie informacji o biznesowym nu-
merze klienta...
Zdarzenie modeluje fakt, który miał miejsce i nie moż-
na go zawetować – możemy co najwyżej zareagować
w dodatkowy sposób na zaistniały fakt. Aby osiągnąć taki
DOMAIN DRIVEN DESIGN KROK PO KROKU
kontrakt na poziomie implementacji technicznej musi-
my posłużyć się transakcyjnym silnikiem zdarzeń, który
zagwarantuje nam, że zdarzenie zostanie propagowane
dopiero wówczas, gdy transakcja, w której go wygenero-
wano, powiodła się. Przykładem standardu wspierającego
komunikaty transakcyjne jest Java Message Service.
Listing 2. Listener zdarzenia w Bounded Context Sales
– listener znajduje się na poziomie aplikacji
@EventListeners
public class CustomerStatusChangedListener{
@EventListener(asynchronous=true)
public void handle(CustomerStatusChangedEvent
event) {
if (event.getStatus() == CustomerStatus.VIP){
calculateReabteForAllDraftOrders(
event.getCustomerId(), 10);
}
}
private void calculateReabteForAllDraftOrders(
Long customerId, int i) {
// TODO Auto-generated method stub
}
}
Listing 2 przedstawia kod jednego z Listenerów naszego
przykładowego zdarzenia. Listener ten wprowadza nastę-
pującą funkcjonalność: jeżeli w module CRM klient stanie
się VIPem, wówczas w module Sales nadajemy mu 10%
rabatu na wszystkie niezatwierdzone zamówienia.
Warto zwrócić uwagę na fakt, iż nasz przykładowy Li-
stener posiada jedynie logikę filtrowania zdarzeń, nato-
miast całą pracę deleguje do Serwisu Aplikacyjnego (API)
swojego modułu. Jest to zatem jedynie kod „klejący”.
Jak widzimy na Rysunku 1, nasz przykładowy Listener
jest klientem do API na takim samym poziomie jak np.
klienty GUI. Jest to zatem jeden z wielu aktorów, którzy
mogą uruchamiać API. Przykładowo rabaty na zamówie-
nia mogą być naliczane nie tylko automatycznie podczas
promowania klienta do statusu VIP, ale również ręcznie,
poprzez GUI np. panelu administracyjnego.
Zdarzenia wprowadzamy do architektury systemu z
kilku powodów:
■■ decoupling modeli – opisany przykład
■■ asynchroniczne wykonanie dodatkowych operacji
– przykładowo w module CRM możemy wysyłać maile
do klientów, których statusy zmieniono; wysyłka maili
to czynność z jednej strony dodatkowa, a z drugiej po-
tencjalnie długotrwała
■■ otwarcie architektury na pluginy – „wpinanie” kolej-
nych listenerów można potraktować jako dodawanie
pluginów
■■ rejestrowanie zdarzeń w celu ich przetwarzania i analizy
- np. z wykorzystaniem silników CEP (Complex Events
Processing) pozwalających na deklarowanie kwerend
filtrujących określone wzorce zdarzeń w czasie
■■ składowanie zdarzeń jako modelu danych alternatyw-
nego dla bazy relacyjnej – Event Sourcing
/ www.programistamag.pl / 67
 INŻYNIERIA OPROGRAMOWANIA

Saga – model czasu w procesie biznesowym
Rozszerzeniem modelu zdarzeń jest Saga biznesowa.
Technicznie saga jest persystentnym multi-listenerem.
Oznacza to, że obiekty Sagi nasłuchują wielu zdarzeń
oraz ich stan jest utrwalany pomiędzy kolejnymi zdarze-
niami – z uwagi na potencjalnie długi czas upływający
pomiędzy kolejnymi zdarzeniami.
Natomiast na poziomie koncepcyjnym Saga modeluje
de facto czas.
Listing 3 zawiera przykładowy kod Sagi, która mode-
luje przepływ zamówienia. Saga reaguje na zdarzenia:
stworzenia zamówienia, zatwierdzenia zamówienia, na-
stąpienia wysyłki oraz dostarczenia zamówienia. Zakłada-
my, że nie możemy przewidzieć kolejności pojawienia się
tych zdarzeń, oraz czas pomiędzy ich wystąpieniem może
sięgać miesięcy.
Każda metoda nasłuchująca konkretnego zdarzenia
w Sadze modyfikuje jej wewnętrzny stan (wzorzec pro-
jektowy Memento) oraz sprawdza, czy warunki bizneso-
we potrzebne do zakończenia Sagi zostały spełnione.
Więcej o Sagach na stronie projektu Levan oraz na
stronie szyny NServiceBus, która wspiera model Sag po-
przez API silnika.
POZIOMY MODELU – OKIEŁZNAĆ
CHAOS
Mając do czynienia ze złożonymi modelami, możemy potrze-
bować dodatkowego rusztowania „rozpinającego” strukturę
modelu. Z czasem, gdy nasze rozumienie modelu pogłębia
się, zauważamy, że pewne jego elementy są ogólnym fun-
damentem, na którym opierają się specyficzne czynności.
Specyficzne czynności mają znowuż swe wariacje.

Listing 3. Saga modelująca przepływ zamówienia

@Saga
public class OrderShipmentStatusTrackerSaga extends
SagaInstance<OrderShipmentStatusTrackerData> {

@Inject
private OrderRepository orderRepository;

@SagaAction
public void handleOrderCreated(OrderCreatedEvent event) {
data.setOrderId(event.getOrderId());
completeIfPossible();
}

@SagaAction
public void handleOrderSubmitted(OrderSubmittedEvent event) {
data.setOrderId(event.getOrderId());
// do some business
completeIfPossible();
}

@SagaAction
public void orderShipped(OrderShippedEvent event) {
data.setOrderId(event.getOrderId());
data.setShipmentId(event.getShipmentId());
completeIfPossible();
}

@SagaAction
public void shipmentDelivered(ShipmentDeliveredEvent event) {
data.setShipmentId(event.getShipmentId());
data.setShipmentReceived(true);
completeIfPossible();
}

private void completeIfPossible() {

if (data.getOrderId() != null
&& data.getShipmentId() != null
&& data.getShipmentReceived()) {
Order shippedOrder = orderRepository.load(data.getOrderId());
shippedOrder.archive();
orderRepository.save(shippedOrder);
markAsCompleted();
}
}
}

68 / 1 . 2012 . (1)  /

 DOMAIN DRIVEN DESIGN KROK PO KROKU

Różne części modelu charakteryzują się różną podat-
nością na zmiany. Czytelnicy zaznajomieni z Archetypa-
mi Modeli Biznesowych znają pojęcie dwóch poziomów
modelu: Operational Level i Knowledge Level. Natomiast
w DDD nadajemy modelowi jeszcze głębszą strukturę
i wyłaniamy w nim aż cztery poziomy...
Rozwarstwienie logiki to dopiero początek
W poprzedniej części dokonaliśmy rozwarstwienia logiki
na warstwę aplikacji i warstwę logiki domenowej. War-
stwa aplikacji modelu (czylu Use Case/User Story/Serwi-
sy SAO) jest odpowiedzialna za:

Rysunek 2. Poziomy modelu domenowego (wraz z mapowaniem na Archetypowe Operational i Knowlege Level)

/ www.programistamag.pl / 69
 INŻYNIERIA OPROGRAMOWANIA
■■ orkiestrację domeny – scenariusz sterowania obiekta-
mi domenowymi
■■ dodatkową logikę typową dla tej konkretnej aplikacji
■■ technikalia takie jak transakcje i bezpieczeństwo
Warstwa logiki domenowej to miejsce, w którym mode-
lujemy przy pomocy Building Blocks logikę ograniczoną
przez Bounded Context.
W tym rozdziale zajmiemy się dalszą strukturyzacją
złożonych modeli w warstwie logiki domenowej.
Capability
Poziom Capability zawiera klasy modelujące potencjalne
możliwości, jakie oferuje nasz system. W naszym przy-
kładowym systemie umieścimy tutaj agregaty Product
i Client oraz Value Object Money. Posiadając produkty,
użytkowników i pieniądze, możemy potencjalnie dalej
modelować: handel, usługi, reklamacje itd. Na tym po-
ziomie zmiany są relatywnie niezbyt częste.
Operations
Poziom Operations zawiera klasy modelujące konkretne
operacje, jakie aktualnie wspiera nasz system. W na-
szym przykładowym systemie umieścimy tutaj agregaty
Order, Invoice oraz Serwis Biznesowy BookKeeper. Skła-
danie zamówień oraz wystawianie na ich podstawie przez
księgowego faktur to konkretne operacje, jakie zbudo-
waliśmy nad modelem potencjału (produktami, klientami
i pieniędzmi). Ten poziom jest średnio podatny na zmiany.
Policy
Poziom polityk niejako „dostraja” poziom Operacji. Przy-
kładowo Księgowy (Serwis Domenowy BookKeeper)
z poziomu Operacji nalicza podatki na różne sposoby
– w zależności od wdrożenia systemu w różnych krajach
lub w zależności od tego, kto jest klientem na fakturze.
Zwróćmy uwagę, że sposób wybrania polityki (konfigura-
cja wdrożenia bądź decyzja w runtime) to funkcjonalność
aplikacji.
Obiekty na poziomie polityk modelują wariacje operacji
biznesowych. Model ten jest mocno podatny na zmiany.
Warto zauważyć, że polityki na poziomie technicz-
nym to technicznie rzecz biorąc domknięcia Operacji.
Domknięcia w sensie popularnych od pewnego czasu ję-
zyków funkcyjnych. Natomiast w starszych językach im-
plementujemy je poprzez Wzorzec Projektowy Strategii
(zob. część I).
Decission Support
Niektóre systemy posiadają rodzaj „sztucznej inteli-
gencji” - mniej lub bardziej wyrafinowane mechaniczny
analityczne wspierające lub wręcz podejmujące decyzje.
W naszym przykładowym systemie mógłby być to mo-
del sugerowania zamienników produktów w razie ich bra-
70 / 1 . 2012 . (1)  /
ku – sugestie na postawie analizy behawioralnej klien-
ta, jego znajomych lub wszystkich klientów (polityka!).
Innym przykładem jest model dobierania rabatu (jeżeli
klientowi przysługuje wiele rabatów, np. z uwagi na: po-
zycję zamówienia, zawartość całego zamówienia, histo-
rię zamówień klienta oraz dodatkowe rabaty: dla VIPów,
z okazji zimy itd.). Model dobierania rabatów może być
dostrojony (policy!) tak, aby działał na korzyść klienta lub
właściciela systemu...
GRANICE AGREGATÓW –
MODELUJEMY NIEZMIENNIKI
Na zakończenie omawiania zaawansowanego modelowa-
nia DDD poruszymy zagadnienie określania granicy Agre-
gatów. Jest to najważniejszy aspekt modelowania DDD,
który decyduje o powodzeniu lub klęsce modelowania.
Nieodpowiednio „zakreślone” granice Agregatów powo-
dują powstanie modeli słabo podatnych na zmiany oraz
nieefektywnych z wydajnościowego punktu widzenia.
W części pierwszej przyjęliśmy dosyć intuicyjne grani-
ce naszych Agregatów, natomiast teraz zastanowimy się
bardziej świadomie nad ich modelem.
Czytelnicy doświadczeni w modelowaniu DDD mogli
zwrócić uwagę na przykładowy Agregat Order, którego
granica była zakreślona dosyć „chciwie”, co mogło poten-
cjalnie powodować problemy z utrzymaniem i wydajno-
ścią modelu.
Agregat w definicji DDD jest spójną jednostką zmiany
(pracy). Od strony praktycznej Agregat powinien modelo-
wać i enkapsulować w swym wnętrzu niezmienniki. Przy-
kładowo, jeżeli model domenowy zakłada, że zawsze:
a+b=c
to wówczas Agregat powinien enkapsulować a, b, c oraz
zapewniać, że po wywołaniu każdej metody Agregatu nie-
zmiennik jest zachowany. W naszym przykładowym Agre-
gacie Order modelujemy niezmienniki: 1) dodatnie/usu-
nięcie produktu powoduje przeliczenie ceny po rabatach,
2) dodatnie produktu już istniejącego nie powoduje poja-
wienia się nowej pozycji zamówienia, a jedynie zwiększe-
nie ilości na już istniejącej pozycji.
Technika analizy przypadków użycia
Dosyć łatwo możemy doprowadzić do nieodpowiednie-
go modelowania granicy Agregatów, jeżeli zastosujemy
klasyczne podejście polegające na grupowaniu rzeczow-
ników w „worki”. Przykładowo, jeżeli odnajdziemy w mo-
delu rzeczownik Zamówienie, to „wrzucamy” do nie-
go kolejne, „mniejsze” rzeczowniki, tworząc zbyt duży
agregat.
Techniką, która sprawdza się lepiej w DDD, jest po-
wstrzymanie się od wstępnego grupowania pojęć w tego
typu „worki” do momentu analizy przypadków użycia/
operacji domenowych i grupowania ich pod kątem spój-
nych jednostek zmiany.
 DOMAIN DRIVEN DESIGN KROK PO KROKU

PODSUMOWANIE – O CZYM NIE ■■ efektywne pobieranie danych – Lazy Loading rozwiązu-

POWIEDZIELIŚMY
Omówiliśmy kolejne poziomy strategicznego modelowa-
nia domeny, począwszy od Destylacji Core Domen, czyli
miejsca, gdzie stosujemy techniki DDD, poprzez wyła-
nianie na podstawie Ubiquitous Language granic mode-
lu – Bounded Context, aż po granice poszczególnych
Agregatów.
Poruszyliśmy również zagadnienie struktury wielko-
skalowej modelu, gdzie separujemy potencjał modelu
od konkretnych operacji i modeli wspierających decyzje
oraz dostrajających je polityk. Kluczem nadawania tej
struktury jest zakres odpowiedzialności oraz podatność
na zmiany.
Warto zawrócić uwagę, iż zbyt chciwie zakreślone
Agregaty powodują następujące problemy:
je jedynie część z nich,
■■ równoległym dostępem do danych – im więcej danych
w agregacie, tym większe prawdopodobieństwo, że
wielu użytkowników będzie miało interes w jego rów-
noległej modyfikacji; Optimistic Locking jedynie chroni,
nas przed konsekwencjami, nie rozwiązując problemu
■■ skalowanie – jesteśmy zmuszeni, aby cały Agregat
persystować w tym samym modelu danych oraz na tej
samej maszynie (zakładając, że rozproszone transak-
cje są błędem w sztuce projektowania skalowalnych
systemów).
Zainteresowanych tą tematyką odsyłam do pierwszej
pozycji w ramce „w sieci”.

W SIECI:
PP strategiczne modelowanie agregatów: http://dddcommunity.org/library/vernon_2011
PP oficjalna strona DDD http://domaindrivendesign.org
PP wstępny artykuł poświęcony DDD http://bottega.com.pl/pdf/materialy/sdj-ddd.pdf
PP przykładowy projekt: http://code.google.com/p/ddd-cqrs-sample/
PP sagi w NServiceBus http://www.nservicebus.com/sagas.aspx

Sławomir Sobótka slawomir.sobotka@bottega.com.pl

Programujący architekt aplikacji specjalizujący się w technologiach Java i efektyw-

nym wykorzystaniu zdobyczy inżynierii oprogramowania. Trener i doradca w firmie
Bottega IT Solutions. W wolnych chwilach działa w community jako: prezes Stowar-
zyszenia Software Engineering Professionals Polska (http://ssepp.pl), publicysta w
prasie branżowej i blogger (http://art-of-software.blogspot.com).

reklama

Loremipsumdolorsit
a m CHCESZ
e t , cBYĆ
o nNA se BIEŻĄCO?
ctetur
DOŁĄCZ DO NEWSLETTERA
adipiscingelit.Mauris
pos MAGAZYNU
u e r e c "PROGRAMISTA"
ondimentum
juston onvestibulum.
www.programistamag.pl
ullamgravidadolor
feugiatdiamfringilla
/ www.programistamag.pl / 71
 KLUB LIDERA - IT
Dokumentowanie architektury
Jak zorganizować proces rozwoju architektury?
Jeśli skrupulatnie przejdziesz razem z nami przez opisane kroki, gwarantujemy, że
Ty i ludzie, z którymi współpracujesz, będziecie mieć całkowitą jasność co do tego,
jakiej konkretnie dokumentacji potrzebujecie. Zdefiniujesz kryteria, dzięki którym
określisz, czy tworzenie danego fragmentu dokumentacji będzie dla Twojego
zespołu przydatne czy nie.
T
o, co za chwilę przeczytasz, będzie mieć sens wy-
łącznie wtedy, gdy już wielokrotnie spotkałeś się
z problemami dotyczącymi dokumentowania i do-
kumentacji w architekturze systemów informatycznych.
Tak to już jest, że dopóki nie spotkasz się z określonymi
trudnymi sytuacjami, pewne rzeczy mogą nie mieć dla
Ciebie znaczenia praktycznego. Zatem jeśli:
■■ pracujesz samotnie albo w bardzo małym zespole,
■■ rotacja w Twoim zespole jest bardzo mała,
■■ nigdy nie przyszło Ci do głowy, aby w jakiś szczególny
sposób dbać o dokumentowanie architektury,
to spokojnie możesz przejść do kolejnego ciekawego
artykułu w magazynie lub potraktuj ten tekst poglądo-
wo i jako przedstawienie problemów pojawiających się
w projektach. Lecz jeśli:
■■ w Twoim zespole często należy wprowadzać nowe oso-
by do projektu,
■■ próbowałeś już wielokrotnie dokumentować archite­
kturę i nie zdawało to egzaminu,
■■ masz wrażenie, że automatyczne generowanie tysięcy
stron dokumentacji jest absolutnie bezcelowe,
■■ w Twoim zespole wiedza o systemie mieści się w więk-
szości w głowach programistów,
to znajdziesz tu kilka przepisów, jak rozwiązać wspo-
mniane problemy. W tym artykule chcemy przeprowadzić
Ciebie i Twój zespół przez fragment procesu zmierzają-
cego do odtworzenia dokumentacji złożonego systemu
informatycznego.
SENS DOKUMENTOWANIA
We have come to value working software over compre-
hensive documentation – stwierdza Manifest Agile. Zaraz
potem rzesze zespołów uwolnionych spod jarzma z ze-
garmistrzowską dokładnością zdefiniowanych procesów,
każących im dokumentować nawet mrugnięcie okiem, ru-
szyły w stronę Agile z nowymi hasłami na ustach „Precz
z dokumentacją!”, „Dobry kod i testy to również doku-
mentacja!”. Pojawiły się nowe praktyki, lecz zostały stare
72 / 1 . 2012 . (1)  /
Michał Bartyzel, Mariusz Sieraczkiewicz
problemy. Wciąż nie można połapać się w architekturze
systemu. Już nie z powodu bezużyteczności dokumenta-
cji, lecz z powodu jej braku.
W tej całej pogoni za nowym i lepszym jakoś zawieru-
szyło się ostatnie zdanie Manifestu Agile: „That is, while
there is value in the items on the right, we value the
items on the left more”. Nie oznacza to, że dokumen-
tacja jest złem, którego należy się wystrzegać, lecz że
celem projektu programistycznego jest przede wszyst-
kim działające oprogramowanie, a dokumentacja pełni
rolę pomocniczą. Stanie na stanowisku, że dobry kod
i częsta komunikacja całkowicie zastąpią dokumenta-
cję, jest równie nonsensowne, co opinia, że za pomo-
cą UMLowych diagramów można napisać cały system,
a potem wystarczy już „tylko” wygenerować kod. Rze-
czywistość tak nie działa. Nie ma jednego sposobu na
załatwienie wszystkich problemów. Wspomniane zdanie
z Manifestu mówi, że:
■■ poszerz swoje myślenie o dokumentacji; dokumenta-
cja to nie tylko tekst, obrazki i diagramy, lecz również
kod źródłowy, testy;
■■ celem projektu jest stworzenie oprogramowania, a do-
kumentacja jest o tyle przydatna, o ile wspomaga ten
cel;
■■ są różne konteksty użycia dokumentacji, w zależności
od kontekstu dokumentacja może się różnić; raz może
to być prosty odręczny rysunek, raz złożony diagram
klas, innym razem kod źródłowy jest wystarczającą
dokumentacją.
W związku z powyższym, zanim rozpoczniesz działa-
nia dokumentowania systemu, absolutną koniecznością
jest precyzyjne określenie po co dokumentacja w ogóle
powstaje.
CEL TWOJEJ DOKUMENTACJI
Tak, właśnie Twojej. Podejście do dokumentowania archi-
tektury systemu w każdym zespole, w każdym projekcie
będzie inne. To jest właśnie główny kłopot w tym obsza-
rze. Mamy UML, mamy narzędzia, lecz jak je wykorzy-
stać, aby stworzyć coś rzeczywiście przydatnego?

Zwróć uwagę, że jeśli postawimy kwestię właśnie w ten
sposób: „jak używać dostępnych narzędzi, aby stworzyć
użyteczną dokumentację”, niemal automatycznie nasu-
wa się pytanie: „co i komu jest właściwie potrzebne?”.
I o to chodzi! Jeśli będziemy po prostu dokumentować,
to powstanie duża ilość dokumentacji bez żadnego spre-
cyzowanego zastosowania. Jeśli najpierw określmy kon-
tekst użycia dokumentacji, kto, kiedy, do czego będzie jej
używał, to będzie powstawało tylko tyle dokumentacji, ile
trzeba i ani bajta więcej.
ETAP 1. POSZUKIWANIE PROBLEMÓW
W przypadkach, z którymi mamy do czynienia najczęściej,
czyli podczas odtwarzania dokumentacji już istniejącego
systemu, cele dokumentacji najłatwiej zdefiniować, wy-
chodząc od problemów, które występują, gdy dokumen-
tacji nie ma.
Krok 1. Proces wytwarzania oprogramowania
Żeby namierzyć problem z dokumentacją, trzeba wskazać
miejsce, w którym występuje. Z tego powodu pierwszym
krokiem będzie narysowanie procesu wytwarzania opro-
gramowania, w którym zespół bierze udział. Niestety nie
wystarczy, że będziesz „miał go w głowie”. Jakoś tak to
magicznie działa, że gdy narysujesz proces, to zaczynasz
patrzeć na niego z innej perspektywy – jako obserwator,
nie jako uczestnik. Twoje postrzeganie jest wtedy szersze
i nieco bardziej obiektywne. Nawet jeśli używasz znanej
metodyki, również przygotuj rysunek. Proces, w którym
bierzesz udział, z pewnością wygląda nieco inaczej, niż
wzorcowy diagram w materiałach szkoleniowych. To wła-
śnie „nieco” może sprawić, że kłopoty występują albo zni-
kają. Efektem tego kroku będzie schemat blokowy, które-
go przykład znajdziesz na Rysunku 1.
Rysunek 1. Przykładowy schemat procesu wytwarzania oprogramowania
DOKUMENTOWANIE ARCHITEKTURY
Krok 2. Zbieranie informacji o problemach
W drugim kroku zbierzesz informacje o tym, jakiego ro-
dzaju problemy wystąpiły w tracie prac, którym mogłaby
zaradzić dokumentacja. Możesz ten krok wykonać samo-
dzielnie, lecz więcej różnorodnych informacji uzyskasz,
gdy zaangażujesz w niego cały swój zespół. Zbieranie
problemów odbywa się poprzez wypełnienie treścią na-
stępującego zdania:
■■ W trakcie…
■■ (kto?)…
■■ miał problem z…
■■ ponieważ…
■■ i spowodowało to…
Każda z części powyższego zdania ma swoje specyficzne
zadanie, dlatego każdą z nich omówimy osobno.
„W trakcie…” uwypukla miejsce, w którym problem się
pojawia. Wpisz tu nazwę etapu z narysowanego wcześniej
procesu wytwarzania oprogramowania, w którym bierzesz
udział. Od miejsca w procesie może zależeć forma doku-
mentacji oraz sposób jej udostępniania. Na przykład jeśli
kłopot występuje podczas etapu wdrożenia, to ten fragment
dokumentacji najpewniej przybierze bardzo formalną po-
stać, jeśli jednak dotyczy etapu implementacji, to być może
wystarczy odręczny schemat na dużej kartce przyklejonej
na ścianie w pomieszczeniu, w którym pracuje zespół.
Część „(kto?)…” identyfikuje osobę, która miała opi-
sywany problem. W tym miejscu mogą pojawić się: imię
faktycznej osoby, rola pełniona w projekcie, stanowisko.
Ta część definiuje odbiorcę dokumentacji. Jest o tyle istot-
na, że innych informacji potrzebuje programista, innych
projektant, a jeszcze innych architekt. Dzięki precyzyj-
nemu nazwaniu odbiorcy, będziemy potrafili uwypuklić te
elementy systemu, które są istotne dla tej właśnie osoby.
/ www.programistamag.pl / 73
 KLUB LIDERA - IT
Rysunek 2. Definiowanie kryteriów na podstawie zidentyfikowanych problemów
„Miał problem z…” określa faktyczny moment poja-
wienia się problemu. Zatrzymaj się na chwilę, bo trze-
ba powiedzieć o bardzo ważnej rzeczy. W tym miejscu
mogą pojawić się wyłącznie czynności, z którymi miała
problem dana osoba. Czynność to coś, co możesz wy-
konać, to określone działanie, które ma swój początek
i koniec, czynność odbywa się w czasie. Dlaczego jest to
takie ważne? Jeśli określisz problemy następująco:
■■ miał problem z bazą danych,
■■ miał problem z testami,
■■ miał problem z komunikacją z Product Ownerem,
to niewiele z tego wynika. Jedyne bowiem, co możesz
zaradzić w takich wypadkach, to: dokumentacja bazy
danych, dokumentacja testów, porozmawiać z Product
Ownerem. Takie definiowanie problemów jest zbyt ogólne
i utrudnia znalezienie środka zaradczego. Jeśli natomiast
zgodnie z przedstawioną zasadą skoncentrujesz się na
czynnościach np.:
■■ miał problem z określeniem, które procedury składo-
wane uruchamiają się w żądaniu X,
■■ miał problem z napisaniem testu jednostkowego do Y,
■■ miał problem z tym, że długo czekał na odpowiedź Pro-
duct Ownera,
to niemal od razu przychodzi do głowy, które elementy
systemu wymagają objaśnienia i które aspekty współpra-
cy z Product Ownerem należy poprawić. Definiując pro-
blemy, odnoś się do konkretnych czynności.
Część „ponieważ…” dookreśla potencjalne braki w do-
kumentacji. Tutaj jest miejsce na wpisanie, czego dana
osoba nie wiedziała lub jaki błąd popełniła.
Na koniec została jeszcze część „i spowodowało
to…”. Na tym etapie odpowiadasz na pytania: Jaki skutek
miał ten błąd dla: terminów, innych zależnych procesów,
stabilności systemu, podwykonawców, klientów? Można
powiedzieć, że ta część zdania wyodrębnia problemy biz-
nesowe związane z dokumentacją. Tutaj określisz argu-
Michał Bartyzel,
Mariusz Sieraczkiewicz m.sieraczkiewicz@bnsit.pl
Trenerzy i konsultanci w firmie BNS IT. Badają i rozwijają metody psychologii pro-
gramowania, pomagające programistom lepiej wykonywać ich pracę. Na co dzień
Autorzy zajmują się zwiększaniem efektywności programistów poprzez szkolenia,
warsztaty oraz coaching i trening.
74 / 1 . 2012 . (1)  /
Autor
menty, które możesz przedstawić jako poparcie swoich
działań odtwarzania dokumentacji.
Jeszcze mała podpowiedź na koniec. Zbieranie powyż-
szych informacji przebiega sprawniej, jeśli dasz ludziom
tabelę do wypełnienia. W nagłówkach kolumn wpisz po-
szczególne części zdania i ewentualne objaśnienia. W po-
szczególnych wierszach ankietowani będą opisywać ko-
lejne problemy. Forma tabeli sprawia, że nie trzeba za
każdym razem przepisywać powtarzalnych fragmentów,
a osoba ją wypełniająca może skupić się na myśleniu za-
miast na pisaniu.
Etap 2. Definiowanie kryteriów
Większość pracy masz już za sobą. Teraz pozostało je-
dynie ostateczne sformułowanie kryteriów, które musi
spełniać dokumentacja architektury Twoje go systemu.
Pojedyncze kryterium jest określone poprzez trzy nastę-
pujące pytania:
■■ Kto będzie używał dokumentacji architektury,
które osoby, które role, które pełnione funkcje?
■■ Kiedy będzie używał dokumentacji architektury,
na którym etapie procesu wytwarzania oprogramowania,
■■ Czego musi się dowiedzieć z dokumentacji archi-
tektury, na jakie konkretne pytania musi odpowiadać
dokumentacja.
Podobnie jak poprzednio, wygodnie będzie zebrać wszyst-
kie kryteria w tabeli, której nagłówki kolumn będą za-
wierały powyższe pytania. Aby wypełnić tabelę kryteriów,
skorzystaj wyodrębnionych wcześniej problemów w spo-
sób przedstawiony na Rysunku 2.
Zgodnie z obietnicą złożoną na początku, po sumien-
nym wykonaniu wszystkich opisanych kroków, w tym
momencie dysponujesz listą kryteriów, które musi speł-
niać dokumentacja architektury Twojego systemu. Od tej
pory za każdym razem, gdy zaplanujesz stworzenie ja-
kiejś części dokumentacji, zweryfikuj to pod kątem swo-
ich kryteriów.
m.bartyzel@bnsit.pl,
Zaglądaj na:
www.serwerblog.com
www.facebook.com/serwerblog

Blog o infrastrukturze IT
 WDROŻENIA
Highsky.com
– projekt, oprogramowanie i wdrożenie pla­
tformy inwestycyjnej highsky.com zintegro­
wanej z platformą MetaTrader 5.
Projekt został zrealizowany przez zespół Positive Power Sp. z o.o. na zlecenie
czeskiego domu maklerskiego HighSky Brokers A.S. W artykule zaprezentowano
wybrane etapy realizacji projektu highsky.com, a także sposoby integracji plat-
formy MetaTrader 5 z zewnętrznymi aplikacjami. Opisano również język skryp-
towy MQL5, który został wbudowany w platformę i umożliwia rozszerzenie jej
funkcjonalności.
P
latforma MetaTrader 5 to zestaw nowoczesnych in-
strumentów umożliwiających handel na rynku wa-
lutowym oraz giełdowym. Oprócz możliwości za-
wierania transakcji platforma oferuje również szereg
różnorodnych narzędzi analitycznych, pozwalających na
ocenę bieżących oraz historycznych danych. W ich skład
wchodzą m.in. dynamiczne wykresy cenowe.
Platforma składa się z wielu elementów. Wśród nich
wyróżniamy m.in. aplikacje klienckie (terminale), służą-
ce do zlecania operacji handlowych i analizy danych oraz
wielofunkcyjne serwery, m.in.:
■■ przetwarzające operacje handlowe,
■■ udostępniające dane historyczne,
■■ przechowujące kopie zapasowe,
dostępowe (access points), z którymi łączą się terminale.
Użytkownik końcowy uzyskuje dostęp jedynie do ter-
minala, a pozostała infrastruktura jest ukryta za serwe-
rami dostępowymi. Dzięki takiej architekturze systemu
znacznie podnosi się bezpieczeństwo danych przechowy-
wanych na serwerach.
Posiadacze smartphone’ów i tabletów mogą skorzy-
stać z aplikacji mobilnej, która umożliwia przeglądanie
wykresów oraz handel. Aplikacja jest dostępna na tele-
fony iPhone oraz z systemem Android, można je pobrać
nieodpłatnie ze strony http://www.metatrader5.com/en/
download.
MQL5
Aplikacja kliencka MetaTradera została wyposażona w
język skryptowy MQL5. Przy pomocy języka MQL5 moż-
na tworzyć zarówno proste skrypty agregujące dane czy
powiadamiające o zmianie kursów, jak i zaawansowane
automaty, które potrafią samodzielnie przeprowadzać
operacje handlowe.
76 / 1 . 2012 . (1)  /
Wojciech Holisz
Język MQL5 jest językiem wysokiego poziomu, zorien-
towanym obiektowo. Składania przypomina język C++.
Podobnie jak C++, język MQL5 cechuje się statyczną
typizacją. Do naszej dyspozycji zostały oddane typy da-
nych pozwalające na wykonywanie operacji na liczbach
całkowitych (int, uint, long), zmiennopozycyjnych (flo-
at, double) oraz wartościach logicznych (bool), a także
możliwość definiowania własnych typów danych w postaci
struktur oraz klas.
Skrypty tworzone w MQL5 dzielą się na kilka typów.
Pierwszy rodzaj to tzw. Expert Advisor, czyli roboty, dzię-
ki którym można całkowicie zautomatyzować procesy
handlowe. Roboty potrafią na bieżąco śledzić sytuację na
giełdzie i na podstawie dokonanej analizy zlecać opera-
cje kupna bądź sprzedaży. Drugi rodzaj to proste skrypty,
których zadaniem jest zwykle wykonanie jednego specy-
ficznego zadania, a następnie zakończenie pracy. Z kolei
biblioteki (Library) nie są typowymi skryptami, ale zbio-
rem funkcji, które można wielokrotnie wykorzystywać w
innych skryptach.
W listingu 1 przedstawiam kod prostego programu na-
pisanego w C++, który wyświetla na ekranie tekst oraz
jego odpowiednik w języku MQL5.
Jak widać, języki te są do siebie bardzo zbliżone. Skrypt
MQL5 zawiera funkcję o nazwie “OnStart”, która jest od-
powiednikiem funkcji “main” w języku C++ oraz definicję
klasy. Skrypt można przetestować w aplikacji MetaEditor.
Aby utworzyć nowy skrypt, należy wybrać opcję “New” z
menu “File”, w oknie zaznaczamy “Script” i przechodzimy
dalej. W kolejnym oknie możemy określić nazwę skryptu,
jego autora oraz parametry wejściowe. W pierwszym polu
wpisujemy nazwę i zatwierdzamy przyciskiem “Finish”.
Otworzy się nowe okno z domyślnym szablonem, który
usuwamy i wklejamy kod naszego skryptu.
Skrypt kompilujemy przy pomocy przycisku “Compi-
le” lub klawisza F7, a uruchamiamy, wybierając pozycję
“Start” z menu “Debug” lub klawiszem F5. Jeżeli nie uru-
 PROJEKT, OPROGRAMOWANIE I WDROŻENIE PLA­TFORMY INWESTYCYJNEJ HIGHSKY.COM
TYTUŁ

Rysunek 1. Aplikacja kliencka z uruchomionymi wykresami. Rysunek 2. Edytor skryptów MetaEditor.

Listing 1. Przykładowy program w C++ oraz jego odpowie­ chomiliśmy jeszcze MetaTradera, edytor zrobi to za nas,
dnik w MQL5 a następnie otworzy jeden wykres. W oknie “Toolbox”
umieszczonym przy dolnej krawędzi ekranu w zakład-
#include <iostream>
#include <string> ce “Eksperci”, znajdziemy tekst wyświetlony przez nasz
skrypt.
class Person
{
Okno z wykresem otwiera się, ponieważ skrypty nie
public: mogą zostać uruchomione jako samodzielne instancje.
Person(const std::string& name) : name(name) Każdy skrypt musi zostać “załączony” do wykresu, aby
{
} możliwe było jego wykonanie. Chcąc uruchomić skrypt z
poziomu MetaTradera, wyszukujemy go w oknie “Naviga-
const std::string& getName() const
{ tor” i wybieramy z menu podręcznego pozycję “Attach to
return name; Chart”.
}
protected: Oczywiście język zawiera również instrukcje sterujące.
std::string name; Instrukcje warunkowe, pętle oraz instrukcje wyboru defi-
};
niujemy identycznie jak w języku C++.
int main(int argc, char* argv[])
{ Listing 2. Przykład ze skryptu z pętlą oraz parametrami
Person* person = new Person("John");
wejściowymi
std::cout
<< "Hello World! My name is " #property copyright "Copyright 2012, MetaQuotes
<< person->getName() Software Corp."
<< "." << std::endl; #property link "http://www.mql5.com"
#property version "1.00"
delete person;
#property script_show_inputs
return 0;
} input uint from;
input uint to;
// MQL5
class Person void OnStart()
{ {
public: for (uint i = from; i <= to; ++i)
Person(string name) : name(name) {
{
if (i % 15 == 0)
}
{
string getName() const Print("FizzBuzz");
{ }
return name; else if (i % 3 == 0)
} {
protected: Print("Fizz");
string name; }
}; else if (i % 5 == 0)
{
void OnStart()
{ Print("Buzz");
Person* person = new Person("John"); }
else
Print("Hello World! My name is " + person. {
getName() + "."); Print(i);
}
delete person; }
} }

/ www.programistamag.pl / 77
 WDROŻENIA
Podobnie jak do programów pisanych w innych językach,
do skryptów MQL5 również możemy przekazywać parame-
try wejściowe. Parametry wejściowe definiowane są tak
samo, jak zmienne globalne, ale poprzedzamy je słowem
kluczowym “input”. W przykładzie zdefiniowane zostały dwa
parametry wejściowe o nazwach “from” oraz “to”.
W powyższych przykładach zostały umieszczone także
“właściwości skryptu”. Każdy skrypt może zostać opatrzony
szeregiem właściwości, w których możemy umieścić m.in.
informacje o autorze skryptu lub jego wersji. Właściwości
definiujemy przy pomocy polecenia “#property”, po któ-
rym występuje nazwa oraz wartość właściwości. Umiesz-
czenie w skrypcie właściwości “script_show_inputs” powo-
duje, że podczas jego uruchomienia wyświetli się okno z
możliwością wprowadzenia parametrów wejściowych.
Przedstawione przykłady zawierały jedynie podsta-
wowe elementy samego języka MQL5. Utworzymy teraz
skrypt Expert Advisor, który umożliwi integrację z apli-
kacją MetaTrader 5. Z menu “File” wybieramy pozycję
“New”. W kreatorze zaznaczamy “Expert Advisor (templa-
te)” i podajemy nazwę skryptu. W kolejnym etapie wybie-
ramy zdarzenia, na które reagować będzie nasz skrypt.
Po zatwierdzeniu przyciskiem “Finish” otworzy się nowe
okno z szablonem skryptu. Usuwamy jego zawartość i
wklejamy kod z listingu 3.
Metody “OnInit” oraz “OnDeinit” są wywoływane od-
powiednio podczas uruchamiania oraz zamykania skryp-
tu. W powyższym przykładzie zostały wykorzystane do
uruchomienia oraz zatrzymania zegara. Zegary generują
zdarzenia co określoną liczbę sekund. Nasz zegar urucha-
mia się co 10 sekund i wyświetla ile razy został wywołany
od momentu uruchomienia skryptu.
Metoda “OnTick” jest wywoływana w momencie, gdy
nastąpi aktualizacja cen na wykresie, do którego załączo-
ny jest nasz skrypt. Metoda z przykładu pobiera oraz wy-
świetla w konsoli najnowsze dostępne wartości cen kupna
oraz sprzedaży.
Skrypty Expert Advisor pozwalają również na integrację
z elementami interfejsu aplikacji. Ostatnia z przykładowych
metod “OnChartEvent” wyświetla współrzędne punktu, w
którym nastąpiło kliknięcie oraz kod naciśnięcia klawisza.
Możliwości naszych skryptów możemy rozszerzać po-
przez import funkcji z zewnętrznych bibliotek DLL. Poniż-
szy skrypt wywołuje popularną funkcję “MessageBox” z
biblioteki systemowej.
Listing 4. Wywołanie funkcji z zewnętrznej biblioteki DLL
#import "User32.dll"
int MessageBoxW(long, string, string, int);
#import
void OnStart()
{
MessageBoxW(0, "Hello World!", "Message", 0);
} akcji handlowych.
Dokumentacja wraz z przykładami użycia języka MQL5
jest dostępna pod adresem http://www.mql5.com/. Po
78 / 1 . 2012 . (1)  /
zapoznaniu się z tajnikami języka MQL5 można spró-
bować swoich sił w organizowanych co roku zawodach
Automated Trading Championship (http://championship.
mql5.com).
WORTAL HIGHSKY BROKERS
Wortal inwestycyjny https://www.highsky.com/ został
wykonany na potrzeby działającego na terenie Czech
domu maklerskiego HighSky Brokers, A.S. Serwis, skie-
rowany do użytkowników czesko- i anglojęzycznych, ofe-
ruje dostęp do aplikacji MetaTrader oraz wielu materiałów
szkoleniowych na temat działania platformy i funkcjono-
wania giełdy.
Dzięki integracji z systemem transakcyjnym MetaTra-
der, w serwisie istnieje możliwość założenia rachunku
inwestycyjnego “demo” bądź rachunku “rzeczywistego”.
Rachunki demo służą wyłącznie celom edukacyjnym.
Dzięki nim użytkownicy mogą zapoznać się z zasadami
funkcjonowania giełdy oraz testować różne strategie gry
bez obawy o utratę środków, gdyż wszelkie operacje han-
dlowe przeprowadzane na takich rachunkach są traktowa-
ne jako fikcyjne i nie skutkują faktycznym zakupem lub
sprzedażą. Rachunki demo wiążą się z jeszcze jedną funk-
cjonalnością serwisu - za ich pośrednictwem użytkownicy
wortalu mogą wziąć udział w organizowanym przez dom
maklerski HighSky Brokers konkursie. Każdy jego uczest-
nik rejestruje testowy rachunek demo, a następnie stara
się zgromadzić na swoim koncie jak największy kapitał.
Swoją aktualną pozycję można sprawdzić w codziennie
aktualizowanej liście rankingowej. Konkurs trwa kilka ty-
godni, a na zwycięzców czekają nagrody.
W przeciwieństwie do rachunków demo, rachunki rze-
czywiste umożliwiają faktyczną grę na giełdzie i są aktyw-
ne dopiero po podpisaniu stosownych umów o współpracy
z domem maklerskim. Po założeniu rachunku użytkow-
nik otrzymuje jednoczesny dostęp do aplikacji klienc-
kiej MetaTrader 5 oraz specjalnie przygotowanej strefy
klienta, gdzie może zweryfikować swoje dane oraz drogą
elektroniczną uzupełnić stan konta. Płatności on-line są
realizowane przy pomocy systemu Global Payments, za-
pewniającego wysokie bezpieczeństwo transakcji. Jedną
z cech - wyróżniającą płatności GP na tle innych - jest
konieczność cyfrowego podpisywania wszystkich danych
przesyłanych pomiędzy serwisem a systemem płatności,
dzięki czemu płatności są odporne na niepożądane mody-
fikacje danych.
Wortal pełni również funkcję informacyjną oraz edu-
kacyjną. Zawarte w nim artykuły szkoleniowe pozwalają
nowym użytkownikom zapoznać się z zasadami gry na
giełdzie, uczą także obsługi aplikacji MetaTrader. Z kolei
bieżące wiadomości ze świata giełdy zapewniają dopływ
cennych informacji pomocnych podczas zawierania trans-
Serwis internetowy udostępnia również aktualne no-
towania w postaci przewijanego paska widocznego na
każdej podstronie oraz stale uaktualnianych wykresów
(liniowych, słupkowych oraz świecowych). Dodatkowo na
 PROJEKT, OPROGRAMOWANIE I WDROŻENIE PLA­TFORMY INWESTYCYJNEJ HIGHSKY.COM
TYTUŁ

Listing 3. Przykład skryptu Expert Advisor

int OnInit()
{
Print("Bot started.");

EventSetTimer(10);

return 0;
}

void OnDeinit(const int reason)

{
Print("Bot killed.");

EventKillTimer();
}

void OnTick()
{
const string symbol = Symbol();

MqlTick tick;
SymbolInfoTick(symbol, tick);

Print("Symbol: ", symbol, ", Bid: ", tick.bid, ", Ask: ", tick.ask);
}

void OnTimer()
{
static uint i = 1;

Print("Timer was called ", i++, " times.");

}

void OnChartEvent(const int id, const long& lparam,

const double& dparam, const string& sparam)
{
switch (id)
{
case CHARTEVENT_CLICK:
Print("You clicked at ", lparam, ":", (int)dparam, ".");
break;

case CHARTEVENT_KEYDOWN:
Print("You pressed key with code ", lparam, ".");
break;
}
}

wykresach liniowych prezentowane są dane makroeko-
nomiczne obrazujące stan gospodarki. Do generowania
wszystkich wykresów w wortalu wykorzystano zewnętrz-
ne narzędzie Google Charts Tools, dzięki czemu zoptyma-
lizowano zapotrzebowanie na moc obliczeniową serwera,
na których hostowany jest serwis.
Publikowane artykuły to nie jedyne źródło informacji na
temat giełdy. W serwisie znajdziemy również wykaz semi-
nariów wraz z możliwością rejestracji. Na seminariach - za-
równo w formie tradycyjnych spotkań, jak i elektronicznych
konferencji - poruszane są tematy związane z giełdą oraz
obsługą inwestycji za pośrednictwem platformy MetaTrader.
TECHNOLOGIE
Aplikacje umieszczono na dwóch serwerach wirtualnych.
Wirtualizacja daje możliwość łatwej zmiany parametrów
serwera, jeżeli wystąpi konieczność np. zwiększenia mocy
obliczeniowej lub udostępnienia większej powierzchni
dyskowej. Serwis WWW jest hostowany na serwerze pra-
cującym pod kontrolą systemu Debian, a aplikacja inte-
grująca serwis WWW z platformą MetaTrader 5 w syste-
mie Windows Server.
Strona WWW została wykonana w języku PHP 5, a dane
przechowywane są w relacyjnej bazie MySQL 5. W celu
podniesienia bezpieczeństwa zainstalowano rozszerzenie
Suhosin dla języka PHP oraz rozszerzenie mod_security
do serwera Apache. Rozszerzenie Suhosin to zaawanso-
wany system, którego zadaniem jest ochrona serwerów
oraz użytkowników przed potencjalnymi zagrożeniami
występującymi w języku PHP i aplikacjach tworzonych
przy jego użyciu.
Bezpieczeństwo danych podnosi również zastosowanie
certyfikatów SSL. Dostęp do wszystkich podstron witry-

/ www.programistamag.pl / 79
 WDROŻENIA

ny highsky.com jest możliwy wyłącznie poprzez protokół
HTTPS. Częstym niedopatrzeniem popełnianym podczas
tworzenia serwisów WWW jest wymuszanie szyfrowania
SSL jedynie przy formularzach logowania czy rejestracji,
a wyłączanie go na pozostałych podstronach. Zabezpie-
cza to wprawdzie przed przechwyceniem hasła wpisywa-
nego podczas logowania, ale pozwala na przechwycenie
ciasteczka identyfikującego zalogowanego użytkownika,
jeżeli użytkownik przejdzie na nieszyfrowaną podstro-
nę. Pomimo pewnych słabości protokołu HTTPS należy
go włączać w całym serwisie. Takie rozwiązanie wymu-
sza szyfrowanie wszystkich treści, łącznie z obrazami, co
wiąże się z nieco większym zużyciem mocy obliczeniowej
procesora, ale bezpieczeństwo danych powinno stać na
pierwszym miejscu.
Dostęp do plików z kodem źródłowym oraz plików za-
wierających ważne dane (np. hasła dostępu do bazy) zo-
stał zabezpieczony poprzez umieszczenie ich w katalogu,
do którego serwer WWW nie ma dostępu. Serwer WWW
posiada dostęp jedynie do zasobów statycznych np. gra-
fik, arkuszy CSS oraz skryptów JavaScript. Istotne frag-
menty kodu źródłowego zostały dodatkowo zaszyfrowane.
Serwis WWW działa wydajnie dzięki zastosowaniu wer-
sji 5.3 języka PHP, która zyskała wiele poprawek związa-
nych z szybkością działania. Większą wydajność serwisu
osiągnięto poprzez zastosowanie wielopoziomowej pa-
mięci podręcznej (cache), czyli mechanizmu polegające-
go na zapamiętywaniu często wykorzystywanych danych,
ale zwykle dostępnych w źródłach o wolniejszym czasie
dostępu lub takich, których generowanie zajmuje więcej
czasu.
Jedną z zastosowanych optymalizacji jest instalacja
rozszerzenia APC. Moduł APC pełni dwie funkcje. Pierwsza
to kompilacja kodu do postaci kodu operacji (opcode),
dzięki czemu kod nie musi być przetwarzany za każdym
razem, gdy skrypt jest wywoływany. Druga funkcja APC
to możliwość korzystania z pamięci operacyjnej do prze-
chowywania danych (np. wyników zapytań wykonywa-
nych na bazie danych). Dzięki cache’owaniu wyników wy-
konywanych zapytań, serwer może szybciej generować
dynamiczne strony WWW. Zastosowanie APC zwiększa
szybkość wykonywania skryptów oraz zmniejsza zapo-
trzebowanie na pamięć podczas ich wykonywania.
Integrację serwisu z platformą MetaTrader 5 wykonano
przy pomocy API udostępnionego przez autorów oprogra-
mowania. W przeciwieństwie do języka MQL5, API nie jest
dostępne publicznie i korzystanie z niego jest możliwe
dopiero po wykupieniu odpowiedniej licencji. API umoż-
liwia m.in. zakładanie rachunków demo oraz rachunków
rzeczywistych, zarządzanie użytkownikami, dostęp do
bieżących i archiwalnych notowań oraz zlecanie operacji
handlowych.
Aplikacja integrująca serwis z platformą MetaTrader
5 została wykonana przy użyciu technologii .NET w ję-
zyku C#. Technologia .NET została wybrana ze względu
na możliwości łączenia kodu natywnego (API platformy)
z kodem zarządzanym oraz możliwościami oferowanymi
przez Windows Communication Foundation. Aplikacja wy-
korzystuje API platformy do zakładania rachunków oraz
udostępniania najnowszych notowań. Dzięki zastosowa-
niu WCF aplikacja może zostać uruchomiona samodziel-
nie lub jako usługa działająca pod kontrolą serwera IIS.

Wojciech Holisz wojciech.holisz@gmail.com

Absolwent Politechniki Śląskiej, od 3 lat związany z agencją interaktywną Positive

Power Sp. z o.o., obecnie na stanowisku Team Leader PHP Developer. Swoje zawo-
dowe zainteresowania koncentruje wokół szeroko pojętej inżynierii oprogramowania
oraz grafiki komputerowej.

Positive Power
Positive Power Sp. z o. o. skupia kilkudziesięciu ekspertów z branży IT, webdesignu
oraz działań kreatywnych. Agencja specjalizuje się w tworzeniu stron internetowych,
dedykowanych platform e-commerce oraz zaawansowanych aplikacji oraz szeroko
pojętym marketingu internetowym. W ciągu 10 lat istnienia przekonała do siebie
kilkaset firm i instytucji, m.in.: Onet.pl, Libet SA, Mennica Polska SA, Mitsubishi Elec-
tric, Subway, Intersport SA, Greenpeace, 8a.pl.

80 / 1 . 2012 . (1)  /

 PROJEKT, OPROGRAMOWANIE I WDROŻENIE PLA­TFORMY INWESTYCYJNEJ HIGHSKY.COM

Rysunek 3. Strona główna serwisu highsky.com.

/ www.programistamag.pl / 81