Professional Documents
Culture Documents
Spis treci
Przykadowy rozdzia
Skorowidz
Katalog ksiek
Katalog online
Zamw drukowany
katalog
Twj koszyk
Dodaj do koszyka
Cennik i informacje
Zamw informacje
o nowociach
Zamw cennik
Czytelnia
Fragmenty ksiek
online
Kontakt
Helion SA
ul. Kociuszki 1c
44-100 Gliwice
tel. 32 230 98 63
e-mail: helion@helion.pl
Helion 19912011
Spis treci
O autorze .....................................................................................................................................11
O recenzencie technicznym ..........................................................................................................13
Podzikowania ............................................................................................................................15
Przedmowa do trzeciego wydania .................................................................................................17
Cz I
Rozdzia 1.
Wprowadzenie ................................................................................. 19
PHP projektowanie i zarzdzanie ......................................................................21
Problem ................................................................................................................................................. 21
PHP a inne jzyki programowania .................................................................................................... 22
O ksice ............................................................................................................................................... 24
Obiekty ........................................................................................................................................... 24
Wzorce ............................................................................................................................................ 24
Narzdzia ....................................................................................................................................... 25
Nowoci w trzecim wydaniu ....................................................................................................... 26
Podsumowanie ..................................................................................................................................... 26
Cz II
Rozdzia 2.
Obiekty ............................................................................................. 27
PHP a obiekty ........................................................................................................29
Nieoczekiwany sukces obiektw w PHP ........................................................................................... 29
PHP/FI u zarania jzyka ......................................................................................................... 29
PHP3 skadniowy lukier ......................................................................................................... 30
Cicha rewolucja PHP4 ............................................................................................................ 30
PHP5 nieuchronne zmiany .................................................................................................... 31
W przyszoci ........................................................................................................................................ 32
Debata obiektowa za czy przeciw? ............................................................................................... 32
Podsumowanie ..................................................................................................................................... 32
Rozdzia 3.
SPIS TRECI
Metody .................................................................................................................................................. 37
Metoda konstrukcji obiektu ........................................................................................................ 38
Typy argumentw metod ................................................................................................................... 39
Typy elementarne ......................................................................................................................... 40
Typy obiektowe ............................................................................................................................. 42
Dziedziczenie ........................................................................................................................................ 44
Problemy zwizane z dziedziczeniem ........................................................................................ 44
Stosowanie dziedziczenia ............................................................................................................. 48
Zarzdzanie dostpem do klasy sowa public, private i protected ................................... 52
Podsumowanie ..................................................................................................................................... 56
Rozdzia 4.
Rozdzia 5.
SPIS TRECI
Rozdzia 6.
Cz III
Rozdzia 7.
Rozdzia 8.
SPIS TRECI
Rozdzia 9.
SPIS TRECI
SPIS TRECI
Cz IV
SPIS TRECI
SPIS TRECI
Cz V
Cz VI
Dodatek A
Bibliografia ..........................................................................................................455
Ksiki ................................................................................................................................................. 455
Publikacje ............................................................................................................................................ 456
Witryny WWW ................................................................................................................................. 456
Dodatek B
Skorowidz ............................................................................................................477
10
ROZDZIA 6
Obiekty
a projektowanie obiektowe
Znamy ju do szczegowo mechanizmy obsugi obiektw w jzyku PHP, wypadaoby wic zostawi na boku
szczegy i zastanowi si nad najlepszymi moliwymi zastosowaniami poznanych narzdzi. W niniejszym
rozdziale wprowadz Ci w kwestie oddalone nieco od obiektw, a blisze projektowaniu. Przyjrzymy si
midzy innymi UML, czyli efektywnemu graficznemu jzykowi opisu systemw obiektowych.
Rozdzia bdzie traktowa o:
x Podstawach projektowania co rozumie pod pojciem projektowania i w czym projektowanie
obiektowe rni si od proceduralnego.
x Zasigu klas jak decydowa o zawartoci i odpowiedzialnoci klas.
x Hermetyzacji czyli ukrywaniu implementacji i danych za interfejsami.
x Polimorfizmie czyli stosowaniu wsplnych typw bazowych dla uzyskania transparentnej podmiany
specjalizowanych typw pochodnych.
x Jzyku UML zastosowaniach diagramw w opisach architektur obiektowych.
CZ II OBIEKTY
W ramach procesu projektowego naley rwnie decydowa, kiedy dana operacja naley do danego typu,
a kiedy powinna nalee do innego typu, wykorzystywanego przez dany. Kady etap projektowania oznacza nowe
wybory i decyzje; jedne z nich prowadz do elegancji i przejrzystoci, inne mog si na decydencie zemci.
Rozdzia ten bdzie w czci powicony pewnym kwestiom, ktrych rozpoznanie jest pomocne w podejmowaniu
waciwych decyzji.
Funkcja readParams() wymaga przekazania jako argumentu wywoania nazwy pliku rdowego. W jej
ciele nastpuje prba otwarcia pliku, a potem odczyt kolejnych wierszy tekstu. Na podstawie wyszukiwanych
w poszczeglnych wierszach par kluczy i wartoci konstruowana jest asocjacyjna tablica parametrw zwracana
nastpnie do wywoujcego. Funkcja writeParams() przyjmuje z kolei na wejcie tablic asocjacyjn i ciek
dostpu do pliku docelowego. W implementowanej w ciele funkcji ptli przeglda tablic, zapisujc wyodrbniane
z niej pary klucz i warto w pliku docelowym. Oto kod uywajcy obu funkcji:
$file = "./param.txt";
$array['klucz1'] = "warto1";
$array['klucz2'] = "warto2";
$array['klucz3'] = "warto3";
writeParams($array, $file);
// zapis tablicy parametrw do pliku
$output = readParams($file); // odczyt tablicy parametrw z pliku
print_r($output);
114
ROZDZIA
6. OBIEKTY A PROJEKTOWANIE OBIEKTOWE
Kod jest, jak wida, stosunkowo zwizy i nie powinien sprawia problemw konserwatorskich. Do utworzenia
i zapisania pliku param.txt uyjemy wywoania writeParams(), ktrego zadaniem jest utrwalenie par klucz
warto:
klucz1:warto1
klucz2:warto2
klucz3:warto3
Niestety, dowiadujemy si wanie, e narzdzie powinnimy przystosowa do obsugi prostych plikw XML
o nastpujcym formacie:
<params>
<param>
<key>klucz</key>
<val>warto</val>
</param>
</params>
Rozpoznanie formatu zapisu pliku powinno si odbywa na podstawie rozszerzenia pliku dla plikw
z rozszerzeniem .xml naleaoby wszcz procedur odczytu w formacie XML.
Cho i tym razem poradzimy sobie z zadaniem, zagraa nam komplikacja kodu i zwikszenie uciliwoci
utrzymania (konserwacji). Mamy teraz dwie moliwoci. Albo bdziemy sprawdza rozszerzenie pliku parametrw
w kodzie zewntrznym, albo wewntrz funkcji odczytujcych i zapisujcych. Sprbujmy oprogramowa drug
z opcji:
function readParams($source) {
$params = array();
if (preg_match( "/\.xml$/i", $source)) {
// odczyt parametrw z pliku XML
} else {
// odczyt parametrw z pliku tekstowego
}
return $params;
}
function writeParams($params, $source) {
if (preg_match("/\.xml$/i", $source)) {
// zapis parametrw do pliku XML
} else {
// zapis parametrw do pliku tekstowego
}
}
Uwaga Kod przykadowy to zawsze sztuka kompromisu. Musi by dostatecznie czytelny, aby ilustrowa konkretn
koncepcj bd
problem, co czsto oznacza konieczno rezygnacji z kontroli bdw i elastycznoci. Innymi sowy,
prezentowany tu przykad jest jedynie ilustracj kwestii projektowania i powielania kodu, w adnym razie nie bdc
wzorcow implementacj parsowania i zapisywania danych w plikach. Z tego wzgldu wszdzie tam, gdzie nie jest to
konieczne do omwienia, implementacja fragmentw kodu zostaa zwyczajnie pominita.
Jak wida, w kadej z funkcji musielimy uwzgldni test rozszerzenia pliku parametrw. Tego rodzaju
zwielokrotnienie kodu moe by w przyszoci przyczyn problemw. Gdybymy bowiem stanli w obliczu
zadania obsugi kolejnego formatu pliku parametrw, musielibymy pamita o synchronizacji kodu
sprawdzajcego rozszerzenie w obu funkcjach.
Sprbujmy to samo zadanie zrealizowa za pomoc prostych klas. Na pocztek zdefiniujemy abstrakcyjn
klas bazow wyznaczajc interfejs typu:
115
CZ II OBIEKTY
W klasie tej definiujemy metod addParam() suc do uzupeniania tablicy parametrw i metod getAllParams()
dajc uytkownikom dostp do kopii tablicy parametrw.
Tworzymy te statyczn metod getInstance(), ktrej zadaniem jest analiza rozszerzenia nazwy pliku
parametrw i zwrcenie uytkownikowi klasy specjalizowanej do obsugi pliku odpowiedniego formatu. Wreszcie
definiujemy dwie abstrakcyjne metody: write() i read(), wymuszajc ich implementacj w klasach pochodnych
i tym samym narzucajc im wsplny interfejs obsugi plikw.
Uwaga Uycie metody statycznej do generowania obiektw klas pochodnych w klasie nadrzdnej jest bardzo
wygodne. Taka decyzja projektowa ma jednak rwnie wady. Typ ParamHandler jest teraz zasadniczo w swoich
gwnych instrukcjach warunkowych ograniczony do pracy z konkretnymi klasami. A jeli zechcemy obsuy inny
format danych? Oczywicie waciciel klasy ParamHandler moe zawsze uzupeni metod getInstance(). Ale ju
programista kodu klienckiego nie ma atwej moliwoci zmieniania klasy bibliotecznej (sama zmiana nie jest moe
specjalnie trudna, ale pojawia si problem ponownego aplikowania zmian w kolejnych wersjach bibliotek). Zagadnienia
tworzenia obiektw omwi bardziej szczegowo w rozdziale 9.
Zdefiniujmy teraz owe klasy specjalizowane (znw gwoli przejrzystoci przykadu pomijajc szczegy
implementacyjne):
class XmlParamHandler extends ParamHandler {
function write() {
// zapis tablicy parametrw $this->params w pliku XML
}
function read() {
// odczyt pliku XML i wypenienie tablicy parametrw $this->params
}
}
class TextParamHandler extends ParamHandler {
function write() {
116
ROZDZIA
6. OBIEKTY A PROJEKTOWANIE OBIEKTOWE
Obie klasy ograniczaj si do implementowania metod wirte() i read(). Kada z klas zapisuje i odczytuje
parametry w odpowiednim dla siebie formacie.
Uytkownik takiego zestawu klas bdzie mg zapisywa i odczytywa pliki parametrw niezalenie od ich
formatu, cakowicie ignorujc (i nie majc nawet tego wiadomoci) znaczenie rozszerzenia nazwy pliku:
$test = ParamHandler::getInstance("./params.xml");
$test->addParam("klucz1", "warto1");
$test->addParam("klucz2", "warto2");
$test->addParam("klucz3", "warto3");
$test->write(); // zapis w formacie XML
Odpowiedzialno
Odpowiedzialno za decyzj co do formatu pliku w podejciu proceduralnym bierze na siebie uytkownik
(kod kontrolujcy) i czyni to nie raz, a dwa razy. Co prawda kod sprawdzajcy rozszerzenie zosta przeniesiony
do wntrza funkcji, ale nie przesania to faktycznego przepywu sterowania. Wywoanie funkcji readParams()
musi zawsze wystpowa w kontekcie innym od kontekstu wywoania writeParams(), wic test rozszerzenia
pliku musi by powtarzany w kadej z tych funkcji, niezalenie od historii ich wywoa.
W wersji obiektowej wybr formatu pliku dokonywany jest w ramach statycznej metody getInstance(),
wic test rozszerzenia jest wykonywany tylko jednokrotnie, a jego wynik wpywa na wybr i konkretyzacj
odpowiedniej klasy pochodnej. Uytkownik nie bierze odpowiedzialnoci za implementacj korzysta po
prostu z otrzymanego obiektu, nie wnikajc w szczegy implementacji klasy tego obiektu. Wie jedynie tyle,
e korzysta z obiektu typu ParamHandler i e obiekt ten obsuguje operacje write() i read(). Kod proceduralny
musia wci zajmowa si szczegami swojej implementacji, a w kodzie obiektowym mamy przeniesienie
zainteresowania z implementacji na interfejs. Przeniesienie odpowiedzialnoci za implementacj z kodu
uytkownika na kod klasy powoduje, e uytkownik nie cierpi w aden sposb wskutek zmian decyzji i wczania
do hierarchii klas obsugujcych nowe formaty plikw parametrw dla niego te rozszerzenia s transparentne.
Spjno
Spjno to bliski stopie powizania zalenych od siebie procedur. W idealnym przypadku mamy do czynienia
z komponentami w jasny sposb dzielcymi odpowiedzialno. Jeli kod rozprasza powizane ze sob procedury,
jego konserwacja staje si utrudniona, poniewa wprowadzanie zmian wie si z identyfikacj i wyszukiwaniem
rozlegych zalenoci.
Nasza klasa ParamHandler zbiera wszystkie procedury zwizane z obsug plikw parametrw we wsplnym
kontekcie. Metody operujce na plikach XML dziel kontekst, w ramach ktrego mog dzieli rwnie dane
i w ramach ktrego zmiany jednej metody (np. zmiana nazw elementw formatu XML) mog by w razie
koniecznoci atwo odzwierciedlone w pozostaych metodach. Klasy hierarchii ParamHandler cechuj si wic
wysok spjnoci.
117
CZ II OBIEKTY
Z kolei podejcie proceduralne rozdziela powizane procedury. Kod obsugi XML jest rozproszony pomidzy
sabo powizanymi funkcjami.
Sprzganie
O cisym sprzganiu mwimy wtedy, kiedy oddzielne czci kodu systemu s ze sob zwizane tak,
e zmiany w jednej z nich wymuszaj zmiany w pozostaych. Tego rodzaju sprzganie jest charakterystyczne dla
kodu proceduralnego z racji jego sekwencyjnej natury.
Sprzganie to wida te dobrze w naszym przykadzie z podejciem proceduralnym. Funkcje writeParams()
i readParams() wykonuj na nazwie pliku ten sam test majcy na celu wykrycie formatu pliku parametrw i sposobu
jego obsugi. Wszelkie zmiany w logice, jakie wprowadzilibymy w jednej z funkcji, musielibymy zaimplementowa
rwnie w drugiej. Gdybymy, na przykad, zamierzali rozszerzy obsug plikw parametrw o nowy format
pliku, musielibymy zsynchronizowa zmiany w obu funkcjach, tak aby obie w ten sam sposb realizoway
test rozszerzenia pliku. Konieczno ta staje si jeszcze bardziej uciliwa w miar wzrostu liczby funkcji
zwizanych z obsug parametrw.
W przykadzie podejcia obiektowego rozdzielilimy od siebie poszczeglne klasy pochodne, izolujc je
rwnie od kodu uytkujcego. W obliczu potrzeby uzupenienia obsugi plikw parametrw o nowy format
pliku dodalibymy po prostu do hierarchii now klas pochodn, a jedyn tego reperkusj byaby konieczno
zmiany logiki testu w pojedynczej metodzie klasy bazowej getInstance().
Ortogonalno
Ortogonalno bdziemy tu rozumie (za Andrew Huntem i Davidem Thomasem i ich publikacj
The Pragmatic Programmer, Addison-Wesley Professional, 1999) jako poczenie cile zdefiniowanej
odpowiedzialnoci komponentw wspzalenych z ich niezalenoci od szerzej widzianego systemu.
Ortogonalno promuje moliwo ponownego wykorzystywania komponentw przez atwo ich wczania
do nowych systemw bez koniecznoci specjalnego przystosowywania ich w tym celu. Takie komponenty maj
cile i w sposb niezaleny od szerszego kontekstu zdefiniowane zbiory danych wejciowych i wyjciowych.
Kod ortogonalny uatwia wprowadzanie zmian, bo ogranicza oddwik zmian wprowadzanych w implementacji
komponentw. Wreszcie kod ortogonalny jest bezpieczniejszy, poniewa tak samo jak zakres oddwiku zmian
ograniczony jest zakres oddwiku ewentualnych bdw. Dla porwnania bd w kodzie cechujcym si wysok
wspzalenoci komponentw moe obejmowa swoimi negatywnymi efektami znaczne obszary systemu.
Nie istnieje co takiego jak automatyzm wicy osabienie sprzgania i wysok spjno z zastosowaniem
klasy. W kocu rwnie dobrze moglibymy w analizowanym przykadzie uj cao proceduralnego kodu
w pewnej klasie i nie zyska na takim pseudoobiektowym podejciu adnej z typowych dla niego zalet. W jaki
wic sposb osign podan rwnowag w kodzie? Osobicie starania rozpoczynam od analizy klas, ktre
miayby uczestniczy w systemie.
Zasig klas
Wyznaczanie granic odpowiedzialnoci i zakresu funkcji poszczeglnych klas systemu okazuje si zaskakujco
trudnym zadaniem, zwaszcza w obliczu rozwoju systemu.
Zadanie to wydaje si proste, kiedy system ma modelowa wiat materialny. Obiektowe systemy czsto
wykorzystuj programowe reprezentacje obiektw wiata materialnego w postaci klas Person (osoba), Invoice
(faktura) czy Shop (sklep). Sugeruje to, e wyznaczanie zasigu klas sprowadza si do rozpoznania i wytypowania
w systemie jego elementw oraz wyposaenia ich w moliwo wzajemnego oddziaywania za porednictwem
metod. Nie jest to spostrzeenie zupenie nieprawdziwe i stanowi znakomity punkt wyjcia w projektowaniu
systemu, nie wolno jednak przyjmowa go bezkrytycznie. Jeli bowiem klasy postrzega jako rzeczowniki, podmioty
dowolnej liczby czynnoci (czasownikw), moe si okaza, e w miar rozwoju projektu i zmian wymaga
natok czasownikw i zalenoci pomidzy rzeczownikami jest nie do opanowania.
118
ROZDZIA
6. OBIEKTY A PROJEKTOWANIE OBIEKTOWE
Polimorfizm
Polimorfizm, czyli przeczanie klas, to wsplna cecha systemw obiektowych. Zdylimy ju jej zreszt
dowiadczy.
Polimorfizm polega na utrzymywaniu wielu implementacji wsplnego interfejsu. Brzmi to moe
zawile, ale w istocie polimorfizm stosowalimy ju z powodzeniem w przykadach. Potrzeba polimorfizmu jest
czsto sygnalizowana w kodzie nadmiern liczb instrukcji warunkowych.
Tworzc w rozdziale 3. pierwsze wersje klasy ShopProduct, eksperymentowalimy z pojedyncz klas, prbujc
pomieci w niej funkcje pozwalajce na zarzdzanie nie tylko produktami pojmowanymi oglnie, ale rwnie
cakiem konkretnym asortymentem pytami CD i ksikami. Doprowadzio to do naszpikowania kodu
generujcego zestawienie informacji o produkcie instrukcjami warunkowymi:
function getSummaryLine() {
$base = "{$this->title} ({$this->producerMainName}, ";
$base .= "{$this->producerFirstName})";
if ($this->type == 'ksika') {
$base .= ": liczba stron - {$this->numPages}";
119
CZ II OBIEKTY
Instrukcje warunkowe sugeruj moliwo wydzielenia dwch klas pochodnych: CdProduct i BookProduct.
Podobnie w analizowanym niedawno proceduralnym kodzie obsugi plikw parametrw obecno instrukcji
warunkowych stanowia pierwszy sygna struktury obiektowej, do ktrej ostatecznie doszlimy. Mielimy tam
powtrzenie tych samych testw w dwch miejscach kodu:
function readParams($source) {
$params = array();
if (preg_match("/\.xml$/i", $source)) {
// odczyt parametrw z pliku XML
} else {
// odczyt parametrw z pliku tekstowego
}
return $params;
}
function writeParams($params, $source) {
if (preg_match("/\.xml$/i", $source)) {
// zapis parametrw do pliku XML
} else {
// zapis parametrw do pliku tekstowego
}
}
Naley zauway, e polimorfizm nie delegalizuje instrukcji warunkowych. Wykorzystywane s one choby
w ramach metody ParamHandler::getInstance() celem wyboru odpowiedniej klasy obiektu. Chodzi o to, aby
instrukcje decyzyjne byy skupione w jednym miejscu kodu i nie musiay by powtarzane w rnych jego
fragmentach.
Wiemy, e PHP wymusza definiowanie interfejsw wyznaczanych abstrakcyjnymi klasami bazowymi.
To korzystne, bo mamy dziki temu pewno, e wszystkie konkretne (nie abstrakcyjne) klasy pochodne bd
obsugiway metody o dokadnie takich sygnaturach, jak w abstrakcyjnej klasie nadrzdnej. Dotyczy to rwnie
sygnalizacji (wymuszania) typw obiektowych oraz ochrony dostpu. W kodzie klienckim mona wic
wymiennie stosowa wszystkie pochodne wsplnej klasy nadrzdnej (dopty, dopki kod kliencki odwouje
si wycznie do funkcjonalnoci zdefiniowanej w klasie bazowej). Od tej reguy jest jeden istotny wyjtek: nie
ma moliwoci ograniczenia i wymuszenia typu zwracanego przez metod klasy, niezalenie od definicji
metody w klasie nadrzdnej.
Uwaga W czasie przygotowywania tej ksiki mwio si o wczeniu wymuszania typw zwracanych do przyszych
wyda PHP, ale nie byo w tym wzgldzie ostatecznego postanowienia.
120
ROZDZIA
6. OBIEKTY A PROJEKTOWANIE OBIEKTOWE
Niemono okrelenia typw zwracanych oznacza, e wymienno typw pochodnych moe ulec zaburzeniu
przez zmienno typw wartoci zwracanych z metod, w zalenoci od implementacji klasy. Warto wic narzuci
sobie samemu dyscyplin polegajc na ujednolicaniu typw wartoci zwracanych. Niektre z metod mog
zreszt by tak definiowane, aby sab kontrol typw, charakterystyczn dla PHP, wykorzysta do zwracania
rnych typw wartoci w zalenoci od okolicznoci wywoania. Reszta metod zawiera z uytkownikami
hierarchii swego rodzaju kontrakt, obietnic co do typu zwracanego. Jeli kontrakt ten zostanie zawarty
w abstrakcyjnej klasie bazowej, powinien by respektowany w implementacjach wszystkich jej konkretnych
pochodnych, aby klienci byli pewni spjnego dziaania wywoa rozprowadzanych w hierarchii. Jeli zgodzimy
si na zwracanie obiektu pewnego typu, mona bdzie oczywicie zwrci specjalizacj tego typu w postaci
obiektu jego klasy pochodnej. Cho wic interpreter nie moe wymusi ujednolicenia typw wartoci zwracanych
z metod, nie powinno to by usprawiedliwieniem niekonsekwencji programisty. Typ wartoci zwracanych
z metod naleaoby te okrela w komentarzach dokumentujcych kod.
Hermetyzacja
Hermetyzacja (ang. encapsulation) oznacza proste ukrywanie danych i funkcji przed uytkownikiem. To kolejne
z kluczowych poj podejcia obiektowego.
Na najprostszym poziomie hermetyzacja danych polega na deklarowaniu skadowych klas jako prywatnych
bd zabezpieczonych. Ukrywajc skadowe przed uytkownikami obiektw klas, wymuszamy na nich stosowanie
pewnego interfejsu odwoa, zapobiegajc tym samym przypadkowym naruszeniom spjnoci danych obiektw.
Inn form hermetyzacji jest polimorfizm. Skrywajc za wsplnym interfejsem rozmaite jego implementacje,
ukrywamy strategie implementacji przed uytkownikami tego interfejsu. Dziki temu wszelkie zmiany
wprowadzane za oson interfejsu s dla jego uytkownikw transparentne. Oznacza to moliwo dodawania
i uzupeniania implementacji interfejsu bez wymuszania zmian w jego stosowaniu po stronie uytkownika.
Uytkownik posuguje si wycznie interfejsem i nie interesuj go skrywajce si za nim mechanizmy. Im
wiksza za niezaleno tych mechanizmw, tym mniejsze ryzyko, e wprowadzane w nich zmiany czy
poprawki odbij si na pozostaych czciach projektu.
Hermetyzacja jest w pewnym sensie kluczem do programowania obiektowego. Naszym celem powinno by
maksymalne uniezalenienie poszczeglnych elementw systemu. Klasy i metody powinny otrzymywa tylko
tyle informacji, ile im potrzeba do wykonywania ich cile ograniczonych i odpowiednio zawonych zada.
Wprowadzenie do jzyka PHP sw kluczowych private, protected i public znakomicie uatwia
hermetyzacj. Hermetyzacja jest jednak rwnie swego rodzaju stanem umysu projektanta. W PHP4 nie
mielimy do dyspozycji adnych formalnych rodkw ukrywania danych. Prywatno bya sygnalizowana
jedynie w dokumentacji i konwencji nazewniczej symptomem zamierzonej prywatnoci skadowej byo na
przykad rozpoczynanie jej nazwy od znaku podkrelenia:
var $_niedotykac;
Wymuszao to starann kontrol kodu, gdy respektowanie tak sygnalizowanej prywatnoci nie byo nijak
egzekwowane przez interpreter jzyka. Co ciekawe, bdy byy stosunkowo rzadkie, poniewa ju sama struktura
i styl kodu jasno wskazyway na to, ktre ze skadowych powinny by omijane w kodzie uytkujcym klasy.
Rwnie w PHP5 moemy zama t regu i odkry dokadny podtyp obiektu wykorzystywanego
w kontekcie przeczania klas wystarczy uy operatora instanceof.
function workWithProducts(ShopProduct $prod) {
if ($prod instanceof CdProduct) {
// operacje waciwe dla obiektw CdProduct
} else if ($prod instanceof BookProduct) {
// operacje waciwe dla obiektw BookProduct
}
}
By moe istnieje niekiedy wany powd do takiego postpowania, ale zazwyczaj nie jest ono dobrze widziane.
Zapytujc powyej o konkretny podtyp, tworzymy zaleno pomidzy kodem implementacji interfejsu a kodem
w interfejs wykorzystujcym. Jest to o tyle niebezpieczne, e hermetyzacja podtypw implementujcych interfejs
121
CZ II OBIEKTY
ma na celu ich separacj od uytkownika midzy innymi po to, aby da twrcom implementacji owych podtypw
swobod zmian i poprawek tutaj konkretnie chodzio za o moliwo modyfikowania hierarchii ShopProduct
bez propagowania zmian do kodu uytkujcego t hierarchi. Powyszy kod eliminuje t moliwo. Gdybymy
bowiem z jakich powodw zdecydowali o zmianie implementacji klas CdProduct i BookProduct, moglibymy
zaburzy zamierzone dziaanie funkcji workWithProducts().
Z powyszego przykadu wycigamy dwa wnioski. Po pierwsze, hermetyzacja pomaga w tworzeniu
ortogonalnego kodu. Po drugie za, stopie, do jakiego hermetyzacja daje si wymusi, a od jakiego moe by
utrzymana jedynie przy odpowiedniej dyscyplinie projektowej, jest zupenie bez znaczenia. Hermetyzacja
jest bowiem technik, ktra powinna znale poszanowanie tak twrcw klas, jak i ich uytkownikw.
Niewane jak
Jeli Czytelnik myli podobnie jak ja, to wzmianka o problemie wywouje u niego intelektualny wycig
w poszukiwaniu mechanizmw dajcych rozwizania. Zaczyna si wybr funkcji przydatnych w implementacji
rozwizania, przypominanie sobie co sprytniejszych wyrae regularnych i poszukiwanie w repozytorium
PEAR tudzie powroty do kodu napisanego wczeniej, a nadajcego si do wykorzystania w rozwizaniu
postawionego zadania. Jednak wszystko to naley na etapie projektowania odoy na bok. Trzeba oczyci umys
z mechanizmw i procedur.
Umys powinny zaprzta jedynie elementy uczestniczce w docelowym systemie: potrzebne w nim
typy i ich interfejsy. Oczywicie wiedza odoona na bok nie jest zupenie ignorowana. Wiemy dziki niej,
e klasa otwierajca plik bdzie potrzebowa cieki dostpu, kod komunikujcy si z baz danych bdzie musia
utrzymywa nazwy tabel oraz hasa i tak dalej. Gwn rol powinny jednak odgrywa struktury i zalenoci
pomidzy nimi. atwo si pniej przekona, e implementacja elegancko wpasowuje si w wyznaczone interfejsy,
a cao zyskuje elastyczno pozwalajc na atwe wymienianie, ulepszanie i rozszerzanie implementacji bez
zakcania wzajemnych zalenoci komponentw systemu i zaburzania go jako caoci.
Gdy pooy si nacisk na interfejs, naley myle kategoriami abstrakcyjnych klas bazowych, a nie ich
konkretnych pochodnych. Przykad mamy w naszym kodzie odczytujcym i zapisujcym parametry tutaj
interfejs jest najwaniejszym aspektem projektu. Potrzebujemy typu odczytujcego i zapisujcego pary klucz
i warto. I wanie to jest podstawowym zadaniem owego typu, a nie faktycznie stosowany nonik czy rodki
wykorzystywane w operacjach pozyskiwania i utrwalania danych. Projektujemy ten system na bazie abstrakcyjnej
klasy ParamHandler, uzupeniajc j potem jedynie konkretnymi strategiami implementacji waciwych operacji
odczytu i zapisu plikw parametrw. W ten sposb uwzgldniamy polimorfizm i hermetyzacj od samego pocztku
tworzenia systemu, zyskujc ostatecznie moliwo przeczania klas implementacji.
To powiedziawszy, naley przyzna, e od pocztku wiadomo byo, e zaistniej implementacje klasy
ParamHandler dla XML-a i plikw tekstowych, i e bez wtpienia wpyno to na ksztat interfejsu. I dobrze, bo nie
sposb definiowa interfejsw w cakowitym oderwaniu od wiadomych sobie aspektw systemu doprowadzioby
to najprawdopodobniej do zbytniej ich generalizacji.
Sawna Banda Czworga (autorzy klasycznej pozycji Design Patterns1) podsumowaa t zasad zdaniem:
Programuj pod ktem interfejsu, nie implementacji. Warto je doda do wasnego zbioru zotych myli.
Cztery drogowskazy
Mao kto nie myli si wcale na etapie projektowania. Wikszo z nas akceptuje fakt koniecznoci wprowadzania
w przyszoci poprawek, nieuniknionych w miar zdobywania lepszego rozeznania w rozwizywanym problemie.
Jasny pocztkowo kurs poprawek atwo zmieni w niekontrolowany dryf. Tu nowa metoda, tam dodatkowa
klasa i system chyli si ku upadkowi. Przekonalimy si ju, e sugestie co do ulepsze kodu wida czsto
w nim samym. Owe tropy mog wprost sugerowa konkretne poprawki albo choby skania do weryfikacji
projektu. W niniejszym podrozdziale sprbuj wyrni cztery oznaki mogce wiadczy o koniecznoci
zmian projektowych.
1
Wydanie polskie: Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego uytku, Helion, 2010 przyp. tum.
122
ROZDZIA
6. OBIEKTY A PROJEKTOWANIE OBIEKTOWE
Zwielokrotnianie kodu
Zwielokrotnianie kodu jest jednym z ciszych grzechw programowania. Uczucie dj vu przy programowaniu
procedury moe sygnalizowa problem projektowy.
Przyjrzyj si wtedy wystpieniom powtrzonego kodu. By moe uda si je scali. Zwielokrotnianie kodu
oznacza zasadniczo cise powizanie elementw projektu. Czy zmiana czego w jednej procedurze wymaga
powtrzenia zmian w podobnych procedurach? Jeli tak, to moe wszystkie je naleaoby uj we wsplnej klasie.
Przemdrzae klasy
Przekazywanie argumentw pomidzy metodami moe by uciliwe. Dlaczego nie oszczdzi sobie kopotu,
wykorzystujc zmienne globalne? Mona wtedy zrezygnowa z nucego przekazywania
Zmienne globalne maj swoje zastosowania, ale nie naley do ich wykorzystywania pochodzi bezkrytycznie.
Przeciwnie, kada zmienna globalna powinna by traktowana wyjtkowo podejrzliwie. Stosujc zmienne globalne
albo ujmujc w klasie wiedz wykraczajc poza dziedzin odpowiedzialnoci tej klasy, kotwiczymy klas
w kontekcie tej wiedzy i tym samym zmniejszamy jej uniwersalno klasa jest uzaleniona od kodu pozostajcego
poza jej kontrol. A przecie chodzi nam o rozlunianie, a nie zacienianie wspzalenoci pomidzy klasami
a procedurami. Wiedz uywan w klasie naleaoby ogranicza do kontekstu teje klasy strategie umoliwiajce
osignicie tego celu poznasz w dalszej czci ksiki.
Zota rczka
Czy nie kaemy klasie wykonywa zbyt wielu zada? Jeli tak, sprbuj rozpisa list tych zada. By moe
niektre z nich daoby si wyodrbni do osobnej klasy.
Obecno przeadowanych zadaniami klas utrudnia wyprowadzanie klas pochodnych. Ktre z zada
powinny by w ramach pochodnej specjalizowane? A jeli potrzebna bdzie pochodna specjalizujca wicej ni
jedno zadanie? Skoczy si albo na nadmiernej liczbie pochodnych, albo na duej liczbie instrukcji warunkowych
w hierarchii.
Za duo warunkw
Stosowanie instrukcji if i switch w kodzie projektu to jeszcze nic zego. Niekiedy jednak obecno takich
struktur warunkowych to niemy krzyk o polimorfizm.
Jeli zorientujesz si, e w ramach jednej klasy wci trzeba testowa jaki warunek, a zwaszcza jeli test
ten trzeba powtarza w wielu metodach klasy, najprawdopodobniej powiniene rozdzieli klas na dwie albo
wicej klas. Sprawd, czy struktura kodu warunkowego sugeruje rozrnianie zada i czy daoby si nimi obarczy
osobne klasy. Owe klasy powinny implementowa wspln abstrakcyjn klas bazow. Moe te pojawi si wtedy
kwestia przekazywania waciwej klasy do kodu uytkujcego tak powsta hierarchi. Mona wtedy wykorzysta
niektre z wzorcw projektowych z rozdziau 9., opisujcych generowanie obiektw.
Jzyk UML
Jak dotd projekt wyraalimy jedynie kodem, ilustrujc nim koncepcje dziedziczenia czy polimorfizmu.
Miao to swoje zalety, poniewa jzyk PHP jest naszym Czytelnika i moim jzykiem wsplnym (musi
tak by, skoro razem zabrnlimy a tutaj). W miar rozrastania si naszych przykadw pokazywanie kodu
rdowego przestanie wystarcza. Kilka wierszy kodu nie zawsze daje bowiem waciwy obraz koncepcji.
123
CZ II OBIEKTY
UML to skrt od Unified Modeling Language (ujednolicony jzyk modelowania). Wedug Martina
Fowlera (autora ksiki UML Distilled, Addison-Wesley Professional, 1999), UML doczeka si rangi standardu
dopiero po wieloletnich intelektualnych i biurokratycznych bataliach toczonych przez spoeczno zwolennikw
projektowania obiektowego; stronami byli zwolennicy dobrego i zwolennicy lepszego.
Z pobojowiska wyonia si niezwykle przydatna skadnia graficznego opisu systemw obiektowych. W tym
rozdziale zaledwie muniemy zagadnienie, wkrtce jednak Czytelnik przekona si, e odrobina jzyka UML
jest w tej ksice jak najbardziej na miejscu.
Przydatno UML-a przejawia si gwnie w opisach struktur i wzorcw, a to za spraw diagramw klas.
Uzyskiwana w tych diagramach przejrzysto intencji projektowych i podziau zada rzadko daje si rwnie
atwo wyrazi w przykadowym kodzie.
Diagramy klas
Cho diagramy klas to tylko jeden z wielu elementw jzyka UML, to wanie im jzyk zawdzicza powszechno
stosowania. Diagramy te s nieocenione w opisach relacji zachodzcych w systemach obiektowych. I wanie
z nich najczciej bdziemy korzysta w niniejszej ksice.
Reprezentowanie klas
atwo si domyli, e gwnymi skadnikami diagramw klas s same klasy. Klasa jest reprezentowana na
diagramie prostoktem opatrzonym nazw, jak na rysunku 6.1.
124
ROZDZIA
6. OBIEKTY A PROJEKTOWANIE OBIEKTOWE
Interfejsy obrazuje si na diagramie klas tak samo jak klasy, tyle e naley je uzupeni o stereotyp (element
zapewniajcy rozszerzalno jzyka UML), jak to zrobiono na rysunku 6.4.
Atrybuty
Oglnie rzecz ujmujc, atrybuty odwzorowuj skadowe klas.
Atrybuty klas wymieniane s w polu przylegajcym bezporednio do pola nazwy klasy patrz rysunek 6.5.
Widoczno
Znaczenie
Publiczna
Prywatna
Chroniona
Za symbolem widocznoci podaje si nazw atrybutu. W naszym przypadku opis dotyczy skadowej
ShopProduct::$price. Wystpujcy za ni znak dwukropka oddziela nazw atrybutu od jego typu (i opcjonalnie
Operacje
Operacje reprezentuj metody, a mwic cilej, opisuj wywoania, jakie mona inicjowa na rzecz klasy.
Na rysunku 6.6 wida element reprezentujcy klas ShopProduct, uzupeniony o dwie operacje:
125
CZ II OBIEKTY
Jak mona si spodziewa, skadnia ta jest do elastyczna. Mona na przykad pomin symbol widocznoci
czy typ zwracany. Parametry z kolei czsto reprezentuje si wycznie typami (bez nazw) w wikszoci jzykw
programowania nazwy argumentw przekazywanych w wywoaniu nie maj bowiem adnego znaczenia.
Powizania
Dziedziczenie to tylko jedna z wielu moliwych relacji, w jakie mog wchodzi klasy w systemie obiektowym.
Kolejn jest na przykad powizanie (ang. association), zachodzce, kiedy skadowa klasy przechowuje referencj
egzemplarza (albo egzemplarzy) innej klasy.
Relacj powizania pomidzy klasami Teacher (nauczyciel) i Pupil (ucze) modelujemy na rysunku 6.9.
Zatem troch na opak, bo programici mwi zazwyczaj o specjalizacji klasy bazowej w klasach pochodnych przyp. tum.
126
ROZDZIA
6. OBIEKTY A PROJEKTOWANIE OBIEKTOWE
Taki opis nie informuje jednoznacznie o rodzaju powizania. Wiadomo jedynie, e obiekt klasy Teacher bdzie
przechowywa referencj do jednego bd wielu obiektw klasy Pupil albo odwrotnie to obiekt klasy Pupil
bdzie przechowywa referencje obiektw klasy Teacher. Relacja powizania moe by rwnie dwustronna.
Do okrelenia kierunku relacji powizania su strzaki. Gdyby to obiekt klasy Teacher mia przechowywa
referencj obiektu klasy Pupil (ale nie odwrotnie), powinnimy poprowadzi strzak od klasy Teacher, a w kierunku
klasy Pupil. Takie powizanie nosi nazw jednokierunkowego (patrz rysunek 6.10).
Agregacja i kompozycja
Agregacja i kompozycja to relacje o charakterze zblionym do powizania. Wszystkie one opisuj bowiem
sytuacj, w ktrej klasa przechowuje trwa referencj do jednego albo wielu egzemplarzy innej klasy. Przy
agregacji i kompozycji owe obiekty wchodz jednak w skad obiektu biecej klasy.
W przypadku agregacji obiekt zawierajcy si w obiekcie danej klasy jest jego nieodczn czci, cho
moe rwnoczenie by zawierany w innych obiektach. Relacja agregacji jest obrazowana lini rozpoczynajc
si symbolem pustego rombu.
Rysunek 6.14 ilustruje dwie klasy: SchoolClass (grupa zajciowa) i Pupil (ucze). Klasa skada si tu z uczniw.
127
CZ II OBIEKTY
Relacja uycia
Relacja uycia jest w jzyku UML opisywana jako zaleno. To najsabsza z relacji omawianych w tym
podrozdziale nie opisuje bowiem adnego staego, a tylko przejciowe powizanie pomidzy klasami.
Obiekt klasy uywanej moe zosta przekazany do klasy uywajcej za porednictwem argumentu wywoania
metody, moe te zosta pozyskany jako warto zwracana z wywoania metody.
Z rysunku 6.16 wynika, e klasa Report uywa obiektu klasy ShopProductWriter. Relacja uycia jest
reprezentowana przerywan lini i otwart strzak czc dwie klasy. Nie oznacza to jednak, e klasa Report
przechowuje referencj obiektu (czy obiektw) klasy ShopProductWriter; z kolei obiekt klasy ShopProductWriter
przechowuje trwale tablic obiektw klasy ShopProduct.
Notki
Diagramy klas mog dobrze odzwierciedla struktur systemu obiektowego, nie daj jednak pogldu na proces
odbywajcy si w systemie.
Rysunek 6.16 ilustruje klasy uczestniczce w naszym systemie. Wida na nim, e klasa Report uywa obiektu
klasy ShopProductWriter, nie wiadomo jednak, na czym owo uycie polega. Sens tego uycia moemy przybliy
ogldajcemu diagram, umieszczajc na nim notki, jak na rysunku 6.17.
128
ROZDZIA
6. OBIEKTY A PROJEKTOWANIE OBIEKTOWE
Diagramy sekwencji
Diagram sekwencji operuje raczej obiektami ni klasami. Suy do modelowania poszczeglnych etapw
procesu przebiegajcego w systemie.
Sprbujmy skonstruowa prosty diagram modelujcy rodki, za pomoc ktrych obiekt klasy Report wypisuje
dane o produktach. Diagram sekwencji wymienia w poziomie uczestnikw systemu, jak na rysunku 6.18.
129
CZ II OBIEKTY
Czas ycia obiektw w modelowanym systemie prezentuje si w pionie, jak na rysunku 6.19.
130
ROZDZIA
6. OBIEKTY A PROJEKTOWANIE OBIEKTOWE
[okToPrint]
write()
oznacza, e wywoanie metody write() jest uzalenione od spenienia warunku okToPrint. Znak gwiazdki
oznacza z kolei powtrzenie, ktrego charakter powinien zosta wyjaniony w nawiasach prostoktnych:
*[dla kadego obiektu ShopProduct]
write()
Sprbujmy zatem dokona analizy procesu implementowanego w systemie, analizujc od gry do dou
diagram sekwencji. Na pocztku obiekt klasy Report pozyskuje list obiektw ShopProduct, wywoujc
stosown metod obiektu klasy ProductStore. List t przekazuje do obiektu ShopProductWriter, ktry
najprawdopodobniej zachowuje referencj obiektw wystpujcych na licie (cho trudno to wywnioskowa
z samego diagramu). Obiekt klasy ShopProductWriter wywouje nastpnie dla kadego otrzymanego obiektu
metod ShopProduct::getSummaryLine(), prowokujc wyprowadzenie na wyjcie kompletu danych o wszystkich
produktach.
Jak wida, przebieg procesu w systemie da si modelowa diagramem sekwencji, dobrze odzwierciedlajcym
dynamiczne interakcje i prezentujcym je w sposb nadspodziewanie czytelny.
Uwaga Spjrz na rysunki 6.16 i 6.20. Zauwa, w jaki sposb diagram klas ilustruje polimorfizm, pokazujc klasy
pochodne klas ShopProductWriter i ShopProduct. Zwr teraz uwag, e szczeg ten sta si niewidoczny przy
modelowaniu komunikacji pomidzy obiektami. Tam, gdzie to moliwe, chcemy bowiem operowa na obiektach
najbardziej oglnych z dostpnych typw, ukrywajc tym samym szczegy implementacji.
Podsumowanie
W rozdziale przeszlimy od niskopoziomowych szczegw programowania obiektowego do kwestii oglniejszych
projektowych. Przedstawiono pojcia hermetyzacji, spjnoci i osabiania zalenoci majce zasadnicze
znaczenie dla elastycznoci systemw obiektowych i moliwoci wielokrotnego wykorzystania ich komponentw.
Udao si te omwi podstawy jzyka UML, kadc tym samym fundament pod omwienie wzorcw
projektowych stanowicych temat kolejnej czci niniejszej ksiki.
131
Skorowidz
$_GET, 245
$_POST, 245
$_REQUEST, 198, 245
$_SESSION, 237
$this, 38, 58, 65
.htaccess, 94
/** */, 348
::, 50, 58
@author, 350
@copyright, 350
@license, 351
@link, 354, 355
@package, 348, 349, 351
@param, 353
@return, 353
@see, 354, 355
@uses, 355
@var, 351, 352
__autoload(), 95, 96
__call(), 73, 76, 77, 102
__clone(), 78, 79, 80, 175, 443
__construct(), 38, 39, 51, 68, 443
__destruct(), 77
__get(), 73, 74
__isset(), 73, 74
__NAMESPACE__, 91
__set(), 73, 74, 75
__sleep(), 239
__toString(), 34, 68, 80, 443
__unset(), 73, 75
__wakeup(), 239
==, 78
===, 78
->, 35, 37
A
abstract, 61
Abstract Factory, 136, 140, 168, 175, 176, 306
abstrakcyjne produkty, 169
abstrakcyjny wytwrca, 169
Factory Method, 171
implementacja, 169
konsekwencje, 171
problem, 168
Prototype, 172
abstrakcyjne klasy bazowe, 122
adres IP, 41
agregacja, 127
akcesory, 53, 74
aktualizacja pakietw PEAR, 346
aktualizacja zmian, 363
Alexander C., 136, 138
algorytmy, 207
aliasy nazw, 90
aliasy polece, 252
analiza leksykalna, 459
analizator leksykalny, 459, 466
AlternationParse, 470, 472
analizator agregatowy, 468
analizator kompozytowy, 468
analizator kocowy, 468
BooleanAndHandler, 476
BooleanOrHandler, 476
CharacterParse, 468
CollectionParse, 468, 469
Context, 463
dopasowania, 468
dopasowywanie w analizatorze kocowym, 468
drzewo obiektw, 466
EBNF, 472
elementy leksykalne, 459
EqualsHandler, 476
SKOROWIDZ
analizator leksykalny
getState(), 463
Handler, 475
klasy analizatorw, 472
konstruowanie drzewa obiektw, 466
MarkParse, 472
nextToken(), 463
odwzorowanie reguy produkcyjnej
w drzewie analizatorw, 475
Parser, 466
Reader, 464
RepetitionParse, 469, 472
Scanner, 459
ScannerState, 463
SequenceParse, 472
setState(), 463
skaner, 459, 463
StringLiteralHandler, 476
StringLiteralParse, 471
VariableExpression, 475
wczytywanie kolejnych znakw, 465
WordParse, 471
wycofanie z prb dopasowa, 469
anonimowe wywoania zwrotne, 183
Ant, 402, 430
any(), 385
aplikacje korporacyjne, 227
Application Controller, 249
Data Mapper, 276
Domain Model, 270
Domain Object Factory, 297
Front Controller, 240
Helper View, 263
Identity Map, 288
Identity Object, 300
Lazy Load, 295
Page Controller, 259
przetwarzanie da, 229
Registry, 231
Selection Factory, 306
Template View, 263
Transaction Script, 266
Unit of Work, 291
Update Factory, 306
warstwa danych, 229, 275
warstwa logiki biznesowej, 229, 266
warstwa polece i kontroli, 229
warstwa prezentacji, 229, 240
warstwa widoku, 229
warstwy, 228
aplikacje warstwowe, 227
aplikacje WWW, 21
testowanie, 389
AppController, 254
478
B
badanie
argumenty metod, 107
klasy, 98, 104
metody, 99, 106
obiekty, 98
relacje dziedziczenia, 100
skadowe, 100
wywoania metod, 101
SKOROWIDZ
C
cache, 291
call_user_func(), 82, 101
call_user_func_array(), 101, 102
catch, 69, 71
centralizacja konfiguracji systemu, 318
channel.xml, 341
checkout, 363
CI, 420
ciao klasy, 33
cig poczeniowy, 278
cigi znakw, 40
ciga integracja, 320, 419, 450
CruiseControl, 427
dokumentacja, 423
instalacja projektu, 430
kompilacje, 426
kontrola wersji, 421
phpUnderControl, 422, 427
pokrycie kodu testami jednostkowymi, 423
przygotowanie projektu, 421
standardy kodowania, 424
Subversion, 421
testy jednostkowe, 422
zalety stosowania, 420
class, 33
class type hints, 43
class_exists(), 97
class_implements(), 100
clone, 78, 172, 175
CodeSniffer, 424
Collection, 283, 284
Command, 222, 247, 248, 251, 257
implementacja, 222
inicjator, 222, 224
odbiorca, 222
problem, 222
uczestnicy, 226
CommandContext, 223
CommandResolver, 244, 248
Composite, 140, 179, 188
diagram klas, 182
drzewo dziedziczenia klas, 180
drzewo obiektw, 180
hierarchia dziedziczenia, 182
implementacja, 182
kaskadowy zasig operacji, 184
kompozyt, 182
konsekwencje, 185
kocwki, 182
koszt operacji, 187
licie, 182
problem, 180
trwao, 187
zalety wzorca, 184
ConfException, 70
Config, 328, 330
connect(), 150
const, 60
contains(), 383
Context, 231
Continous Integration, 420
ControllerMap, 253
CREATE TABLE, 59
create_function(), 82, 83, 183
CruiseControl, 427
artifact directory, 438
bdy stylu kodowania, 434
bdy testw, 435
build.xml, 430, 432
cc.pid, 429
CodeSniffer, 433
config.xml, 430, 431, 432
definiowanie publikatorw, 432
dodawanie projektu, 430
dodawanie zada kompilacji, 436
dostp do kodu rdowego projektu, 431
instalacja, 427
instalacja projektu do integracji cigej, 430
katalogi zestawie elementw, 438
kompilacja projektw, 430
konfiguracja oglna, 432
konfiguracja projektu, 430
mechanizm publikacji przez poczt elektroniczn, 435
phpUnderControl, 433
podsumowanie kompilacji, 433
479
SKOROWIDZ
D
dane, 229, 275
Data Access Object, 276
Data Mapper, 276, 309, 311
cig poczeniowy, 278
Collection, 284
DomainObject, 284
HelperFactory, 284
implementacja, 276
Iterator, 280
klasa odwzorowania, 276
konsekwencje, 287
Mapper, 276, 286, 287
obsuga wielu wierszy, 280
pozyskiwanie kolekcji, 286
pozyskiwanie narzdzi utrwalania danych, 284
problem, 276
wytwrnia, 284
zarzdzanie kolekcjami wielowierszowymi, 283
Data Source Name, 150, 161
Data Transfer Object, 300
Decorator, 188, 191
implementacja, 190
konsekwencje, 193
konstruowanie cigw dekoracji, 192
problem, 188
wbudowywanie modyfikacji cech w drzewo
dziedziczenia, 189
DeferredEventCollection, 296
definiowanie
destruktory, 77
kanay PEAR, 341
klasy pochodne, 206
skadowe, 35
testy WWW, 393
deklaracja
interfejsy, 62
klasy, 33
klasy abstrakcyjne, 61
klasy finalne, 72
metody, 37
metody abstrakcyjne, 61
metody statyczne, 57
480
skadowe, 35
skadowe stae, 60
skadowe statyczne, 57
zmienne, 40
dekorator, 188
delegowanie wywoa, 76
destruktory, 77
__destruct(), 77
diagnostyka, 69
diagramy klas, 124
#, 125
{abstrakcyjna}, 124
+, 125
agregacja, 127
atrybuty, 125
definiowanie krotnoci relacji powizania, 127
implementacja, 126
interfejsy, 125
kierunek relacji, 127
klasy, 124
klasy abstrakcyjne, 124
kompozycja, 127, 128
metody, 125
notki, 128, 129
ograniczenia, 124
operacje, 125
powizania, 126
powizanie jednokierunkowe, 127
relacja implementacji, 126
relacja realizacji, 126
relacja uycia, 128
relacja zalenoci, 129
relacje dziedziczenia, 126
skadowe, 125
widoczno atrybutw, 125
diagramy sekwencji, 129, 130
czas ycia obiektw, 130
kierunek przesyania komunikatw, 130
linie ycia obiektw, 130
obiekty, 129
die(), 62
DocBlock, 348
dokumentacja, 319, 345, 449, 451
brak dokumentacji, 346
ciga integracja, 423
generowanie, 347
klasy, 348, 349
komentarze DocBlock, 348
metody, 352
nota o sposobie licencjonowania, 351
odnoniki, 354
pliki, 351
skadowe, 351
dokumentowanie kodu, 346
dokumenty XML, 40, 62, 67
DokuWiki, 451
SKOROWIDZ
E
EBNF, 198, 472
echo, 414
egzemplarz klasy, 34
eksportowanie projektu, 369
elastyczno obiektw, 179
F
fabryka, 60, 160
Facade, 193, 266
implementacja, 195
konsekwencje, 195
problem, 193
punkt dostpu do warstwy czy podsystemu, 195
Factory Method, 164, 171
implementacja, 166, 167
klasy produktw, 166
klasy wytwrcw, 166
konsekwencje, 167
powielanie kodu, 167
problem, 164
fail(), 380
false, 40, 41
feedback form, 153
FileException, 70
FileSet, 410
FilterChain, 412
final, 72
Finder, 284
fixture, 379
fluent interface, 302
fopen(), 94
foreach, 280
Form Interpreter, 29
format INI, 330
format wzorca wedug Bandy Czworga, 138
formaty zapisu konfiguracji, 330
formularze, 29
formularze zwrotne, 153
Foswiki, 451
Fowler M., 136, 137, 230, 232
Front Controller, 141, 228, 240, 389
ApplicationHelper, 242
Command, 247
CommandResolver, 244
481
SKOROWIDZ
Front Controller
hierarchia klas polece, 241
implementacja, 241
klasa kontrolera, 241
konsekwencje, 248
podejmowanie decyzji o sposobie obsugi
dania HTTP, 244
polecenia, 247
problem, 240
strategia wyboru logicznego, 244
dania, 245
FrontController, 250
function, 37, 83
funkcje
__autoload(), 95, 96
array_slice(), 105
call_user_func(), 101
call_user_func_array(), 101, 102
class_exists(), 97
class_implements(), 100
create_function(), 82, 83
die(), 62
dostosowanie typu argumentu wywoania, 42
exit(), 260
fopen(), 94
get_class(), 98
get_class_methods(), 99
get_class_vars(), 100, 102
get_declared_classes(), 97
get_include_path(), 95
get_parent_class(), 100
is_a(), 98
is_array(), 40, 388
is_bool(), 40
is_callable(), 82, 83, 99
is_double(), 40
is_int(), 44
is_integer(), 40
is_null(), 40
is_object(), 40
is_resource(), 40
is_string(), 40
is_subclass_of(), 100
method_exists(), 99, 100
mysql_connect(), 149
mysql_query(), 149
print_r(), 99, 279
set_include_path(), 95
simplexml_load_file(), 41, 67
var_dump(), 34, 104
funkcje anonimowe, 81
ledzenie zmiennych z zewntrznego zasigu, 84
tworzenie, 83
use, 84
funkcje pomocnicze, 96
funkcje skadowe, Patrz metody
482
G
Gamma E., 23
garbage collection, 77
generalizacja, 126
generowanie
dokumentacja, 345, 347
obiekty klas pochodnych, 116
zapytania, 306
generowanie obiektw, 157
Abstract Factory, 168
Factory Method, 164
problemy, 157
rozwizania, 157
Singleton, 161
get_class(), 98
get_class_methods(), 99
get_class_vars(), 100, 102
get_declared_classes(), 97
get_include_path(), 95
get_parent_class(), 100
getBacktrace(), 330
getCode(), 68, 330
getEndLine(), 107
getErrorClass(), 331
getErrorData(), 331
getFile(), 68
getFileName(), 107
getInstance(), 116
getLine(), 68
getMessage(), 68, 330
getMethods(), 110
getMock(), 384
getParameters(), 108
getPrevious(), 68
getStartLine(), 107
getTrace(), 68
getTraceAsString(), 68
Git, 358, 449
globalna przestrze nazw, 92
gramatyka jzyka, 198
greaterThan(), 383
greaterThanOrEqual(), 383
Gutmans A., 30
H
Helm R., 23
Helper View, 263, 264
implementacja, 264
konsekwencje, 265
problem, 264
HelperFactory, 284
hermetyzacja, 121, 149, 444, 445
hierarchia klas, 48, 54, 145, 146, 182
SKOROWIDZ
hint, 43
historia jzyka PHP, 29
Hunt D., 232
I
identicalTo(), 383
Identity Map, 64, 288, 289, 312
identyfikacja obiektw, 289
implementacja, 288
konsekwencje, 291
Mapper, 290
problem, 288
przechowywanie informacji o obiektach, 288
Identity Object, 300, 312
implementacja, 301
konsekwencje, 305
problem, 300
zarzdzanie kryteriami zapyta, 301
if, 123
Image_GraphViz, 328
imitacje, 383, 397
implementacja, 151
implementacja interfejsu, 63
implementacja metody abstrakcyjnej, 61
implements, 63, 64
include(), 92, 93, 260
include_once(), 92
include_path, 94
infrastruktura testw, 320
INI, 330
inline tags, 354
instalacja, 401, 450
instalacja CruiseControl, 427
instalacja pakietw PEAR, 325
instalacja projektu, 318
integracja ciga, 430
instalatory, 318
instanceof, 48, 98, 100, 121, 187
instrukcje warunkowe, 152, 445
integer, 40
integracja, 419
integracja ciga, 450
interceptor methods, 73
interface, 62, 63
interfejs kaskadowy, 302, 305, 384
interfejs wiersza polece, 197
interfejs WWW, 197
interfejsy, 62, 73, 120, 151
deklaracja, 62
implementacja, 63
Iterator, 280
Reflection, 287
Interpreter, 197
implementacja, 198
problem, 197
wady, 204
invoke(), 111
inynieria oprogramowania, 22
is_a(), 98
is_array(), 40, 388
is_bool(), 40
is_callable(), 82, 83, 99
is_double(), 40
is_int(), 44
is_integer(), 40
is_null(), 40
is_object(), 40
is_resource(), 40
is_string(), 40
is_subclass_of(), 100
isError(), 330
isPassedByReference(), 108
isSubclassOf(), 110
Iterator, 280, 287
iteratory, 280
J
JAR, 324, 393
Java, 22, 393, 427
Java Archive, 324
JAVA_HOME, 427
jednostka pracy, 291, 312
jzyk DSL, 198
jzyk Java, 22, 393
jzyk MarkLogic, 198
jzyk o osabionej kontroli typw, 40
jzyk Perl, 29
jzyk PHP3, 30
jzyk PHP4, 21, 30
jzyk PHP5, 21, 31
jzyk programowania, 22, 197, 198
jzyk Selenese, 393
jzyk UML, 123
Johnson R., 23
JUnit, 23, 378
K
kanay PEAR, 327
channel.xml, 341
definiowanie kanau, 341
domylna strona interfejsu kanau, 343
konfiguracja, 340
PEAR2_SimpleChannelFrontend, 341
PEAR2_SimpleChannelServer, 341
zarzdzanie kanaem, 341
zarzdzanie pakietem w kanale, 342
kaskady operacji wczytywania, 287
kategoryzacja kodu, 87
key(), 280
483
SKOROWIDZ
484
SKOROWIDZ
L
Layer Supertype, 268, 273
Lazy Load, 295, 312
implementacja, 296
konsekwencje, 297
problem, 295
Lerdorf R., 29
lessThan(), 383
lessThanOrEqual(), 383
libxml_get_last_error(), 71
liczby, 39, 40
linie ycia obiektw, 130
listy dystrybucyjne, 450
Log, 326
logicalAnd(), 383
logicalNot(), 383
logicalOr(), 383
logika biznesowa, 229, 264, 266
lokalizowanie obiektw dziedziny, 300
acuchy znakw, 39
M
magiczne metody, 77
Mailman, 450
make, 402
makefile, 402
mapa tosamoci, 64, 288, 289, 312
Mapper, 276, 284, 286, 287, 290, 294, 297
mapy cieek projektu, 345
MarkLogic, 198, 459
Expression, 200
gramatyka, 199
nawiasy, 199
OperatorExpression, 202
VariableExpression, 201
wyraenia, 199
matchesRegularExpression(), 383
MDB2, 150
MDB2_Driver_Common, 150
MDB2_Driver_mysql, 150
MDB2_Driver_sqlite, 150
mechanizm cigej integracji, 420
mechanizm obserwacji, 214
mechanizm pnego wizania skadowych statycznych, 65
mechanizm sygnalizowania argumentw tablicowych, 44
mechanizm sygnalizowania oczekiwanego typu, 43
mechanizm wywoa zwrotnych, 82
Memcached, 291
Mercurial, 358
method_exists(), 99, 100
methodData(), 106
metoda szablonowa, 202
metoda wytwrcza, 164
metody, 37
__clone(), 78, 79, 80, 175, 443
__construct(), 38, 39, 51, 443
__destruct(), 77
__sleep(), 239
__toString(), 34, 80, 443
__wakeup(), 239
akcesory, 53
argumenty, 39
asercje, 379
badanie, 99, 101, 106
badanie argumentw, 107
deklaracja, 37
destruktory, 77
diagramy klas, 125
dokumentacja, 352
dostosowanie typu argumentu wywoania, 42
konstruktory, 38
metoda konstrukcji obiektu, 38
metody finalne, 72
metody magiczne, 77
metody testujce, 379
metody z ostrzeeniami, 62
odwoanie do egzemplarza klasy, 38
parametry, 43
PHP4, 37
polimorfizm, 120
typ wartoci zwracanej, 68
widoczno, 37
wskazwki parametrw, 43
wywoanie, 37
metody abstrakcyjne, 61
implementacja, 61
metody przechwytujce, 73
__call(), 73, 76
__get(), 73, 74
__isset(), 73, 74
__set(), 73, 74, 75
__unset(), 73, 75
metody statyczne, 57, 58, 64, 163
deklaracja, 57
generowanie obiektw klas pochodnych, 116
wywoanie, 58
minijzyk, 198
model dziedziny, 270
model obiektowy, 31
Module, 108, 110
modyfikatory dostpu, 35
montowanie dokumentu kompilacji, 403
MSSQL, 150
MySQL, 149, 150
mysql_connect(), 149
mysql_query(), 149
485
SKOROWIDZ
N
nadmiar wzorcw, 153
naduywanie wzorca Singleton, 447
namespace, 89
narzdzia, 448
narzdzia obiektowe, 87
nazwy, 32, 88, 319
klasy, 88
nazwy kwalifikowane, 89
PEAR, 93
wzorce projektowe, 136, 137
never(), 385
new, 34
newInstance(), 110, 111
next(), 280
niedopasowanie obiektowo-relacyjne, 276
Nock C., 297, 309
notacja EBNF, 198
notifyPasswordFailure(), 385
notki, 128
nowi programici, 345
null, 40
O
obiekt tosamoci, 300, 312
obiektowo, 29, 32
obiekty, 29, 30, 32, 33, 34, 179, 443
akcesory, 53
badanie, 98
destruktory, 77
diagramy sekwencji, 129
dostp do skadowych, 35
dynamiczne uzupenianie skadowych, 36
generowanie obiektw, 157
konkretyzacja, 34
kopiowanie, 78
metoda konstrukcji obiektu, 38
metody, 37
obsuga obiektw, 443
reprezentacja w cigach znakw, 80
skadowe, 34
skadowe dynamiczne, 36
tworzenie, 34
waciwoci, 34, 35
wypisywanie zawartoci, 34
obiekty danych, 59
obiekty PDO, 59, 268, 278
obiekty-atrapy, 229
object, 40
Object Mothers, 398
ObjectWatcher, 292
Observer, 210, 331
implementacja, 211, 215
komunikacja midzy klas obserwatora a podmiotem, 215
SPL, 214
486
obsuga bdw, 66
pakiety PEAR, 330
obsuga danych, 229
obsuga obiektw, 31, 443
obsuga PEAR, 324
obsuga sesji, 234
obsuga typw argumentw, 41
obsuga da, 240
odnoniki w dokumentacji, 354
odpowiedzialno, 117
odwoanie do plikw bibliotecznych, 94
odwoanie do przesonitej wersji metody, 58
odwzorowanie danych, 276, 311
odwzorowanie da do polece, 249
once(), 385
operatory
::, 50, 58
==, 78
===, 78
->, 35
dostp do skadowej, 35
instanceof, 48, 98, 121
new, 34
opis gramatyki jzyka, 198
opnione adowanie, 295, 296
organizacja obiektw i klas, 179
organizacja pakietw w konwencji systemu plikw, 92
ortogonalno projektu, 118, 210
oryginalno kodu, 317
osadzanie logiki biznesowej w warstwie prezentacji, 264
osabianie sprzenia, 150, 444
P
package.xml, 327, 333, 426
active, 334
channel, 334, 338
contents, 335, 336
date, 334
definiowanie plikw i katalogw, 335
dependencies, 338
description, 334
dir, 335
dookrelanie instalacji, 339
elementy, 334
email, 334
file, 335
identyfikator URI, 334
informacje o twrcach pakietu, 334
installconditions, 339
lead, 334
license, 335
name, 334
nazwa pakietu, 334
notes, 335
SKOROWIDZ
parent::__construct(), 50, 51
parsowanie, 459
PatternSet, 411
PDO, 59, 60, 149, 268, 278
prepare(), 269
PDOStatement, 286
execute(), 269, 279
pear, 324
PEAR, 31, 93, 141, 316, 323
definiowanie kanau, 341
instalacja pakietw, 325
kanay, 327
konfiguracja kanau, 340
miejsce instalowania pakietw, 324
obsuga bdw, 330
package.xml, 327, 333
pakiety rdzenia, 324
parametry konfiguracyjne, 324
PHP Foundation Classes, 324
przygotowanie pakietu do dystrybucji, 340
repozytorium, 323
skadniki pakietu, 333
tworzenie pakietw, 333
wersje PHP, 330
zalenoci pakietw, 326
zarzdzanie kanaem, 341
zarzdzanie pakietem w kanale, 342
pear channel-discover, 327
pear channel-info, 327
pear config-get, 324
pear config-get php_dir, 324
pear config-show, 324
pear install, 325, 327, 328, 346
pear package, 340
pear upgrade, 346
PEAR::getCause(), 331
PEAR::isError(), 330
PEAR::MDB2, 149
PEAR_Config, 328
PEAR_Error, 68, 330
getBacktrace(), 331
PEAR_Exception, 331, 332
getCause(), 333
PEAR2_SimpleChannelFrontend, 341
PEAR2_SimpleChannelServer, 341
Perl, 29
PersistenceFactory, 310
Personal Homepage Tools, 29
PHAR, 324
phar.readonly, 343
phing, 403
Phing, 401, 402
atrybuty elementu copy, 416
atrybuty elementu fileset, 411
atrybuty elementu input, 417
atrybuty elementu patternset, 412
487
SKOROWIDZ
Phing
atrybuty elementu project, 404
atrybuty elementu target, 408
build.xml, 403
copy, 415, 416
delete, 417
dokument kompilacji, 403
echo, 406, 414
env, 409
fileset, 410
filterchain, 412
filtry, 413
if, 407
input, 416
instalacja, 402
katalog domowy uytkownika, 409
katalog projektu, 409
kopiowanie, 415
lista zada, 405
montowanie dokumentu kompilacji, 403
nazwa projektu, 409
operacje, 414
override, 408
patternset, 411
phing.project.name, 409
pliki kompilacji, 403
pobieranie danych, 416
pobieranie pakietu instalacyjnego, 402
project, 403
project.basedir, 409
-projecthelp, 405
property, 406, 409
przeksztacanie zawartoci plikw tekstowych, 412
ReplaceTokens, 413
rnicowanie zada kompilacji, 404
StripLineBreak, 413
TabToSpaces, 413
target, 403, 404, 405, 407, 408
typy danych, 410
unless, 407
user.home, 409
ustawianie waciwoci, 409
usuwanie, 417
usuwanie znakw nowego wiersza, 413
waciwoci kompilacji, 406
waciwoci wbudowane, 409
XSLT, 413
XsltFilter, 413
zadanie kompilacji, 403, 404
zastpowanie znakw tabulacji znakami spacji, 413
zmienne rodowiskowe, 409
PHP, 22
PHP Data Object, 149
PHP Extension and Application Repository, 93, 316
PHP Foundation Classes, 324
488
SKOROWIDZ
TestCase, 383
testowanie, 386
testowanie wyjtkw, 380
testy, 378
tworzenie przypadku testowego, 378
uruchamianie zestaww testw, 381
zarzdzanie rodowiskiem testu, 384
PHPUnit_Framework_Constraint, 382
PHPUnit_Framework_MockObject_Builder_
InvocationMocker, 385
PHPUnit_Framework_MockObject_Matcher_Invocation, 385
PHPUnit_Framework_MockObject_Stub_Return, 386
PHPUnit_Framework_TestCase, 378, 382
assertThat(), 382
getMock(), 384
PHPUnit_Framework_TestSuite, 422
PHPUnit2, 378, 449
PHPUnit2_Framework_TestCase, 380
PhpWiki, 451
pinezki, 32
plik konfiguracji, 251
przetwarzanie, 252
utrwalanie danych konfiguracyjnych, 253
pliki
.htaccess, 94
makefile, 402
XML, 67
pytka kopia obiektu, 79
podejmowanie decyzji, 222
podzia klasy na podklasy, 205
pokrycie kodu testami, 423, 434
polimorfizm, 119, 152, 158, 166, 445
pomocnik widoku, 264
Portland Pattern Repository, 138
powizanie, 126
powizanie dwukierunkowe, 127
powizanie jednokierunkowe, 127
powielanie kodu, 123, 167, 323, 444
powierzchowna kopia obiektu, 79
pne wizanie statyczne, 64
praca w zespole programistycznym, 315
prawida projektowania obiektowego, 141
Preferences, 161
prepare(), 269
prepareStatement(), 268, 269
prezentacja, 229, 240
primitive types, 39
print_r(), 99, 279
private, 35, 37, 52, 121
productions, 198
programowanie, 315
programowanie ekstremalne, 23
programowanie obiektowe, 32, 114
programowanie pod ktem interfejsu, 448
programowanie proceduralne, 32, 114
projekt, 21, 361
489
SKOROWIDZ
R
RapidSVN, 358
reagowanie na dania uytkownikw, 222
realizacja zada, 197
redukcja masowych odwoa do bazy danych, 295
refaktoryzacja, 23
ReferenceClass::getMethods(), 110
referencje, 30, 78
Reflection, 102, 103, 287
export(), 103, 104
Reflection API, 97, 102, 244, 379
atrybuty klas, 103
badanie argumentw metod, 107
badanie klasy, 104
badanie metod, 106
dostp do rda klasy, 105
Reflection, 102, 103
ReflectionClass, 102, 103, 104, 110
ReflectionException, 102
ReflectionExtension, 102
ReflectionFunction, 102
ReflectionMethod, 102, 106, 110
ReflectionParameter, 102, 107
ReflectionProperty, 102
ReflectionUtil, 105
stosowanie, 108
ReflectionClass, 102, 103, 104, 110
getEndLine(), 105
getFileName(), 105
getMethod(), 106, 108
getMethods(), 106
getName(), 105
getStartLine(), 105
isAbstract(), 105
isInstantiable(), 105
isInternal(), 105
isSubclassOf(), 110
isUserDefined(), 105
newInstance(), 110, 111
ReflectionException, 102
ReflectionExtension, 102
ReflectionFunction, 102
ReflectionMethod, 102, 106, 110
getParameters(), 107
invoke(), 111
methodData(), 106
returnsReference(), 107
ReflectionParameter, 102, 107, 108
getClass(), 111
getName(), 108
ReflectionProperty, 102
ReflectionUtil, 105
getClassSource(), 105
getMethodSource(), 107
490
registerCallback(), 82, 83
Registry, 228, 231, 232, 389
ApplicationRegistry, 237
implementacja, 232
konsekwencje, 239
MemApplicationRegistry, 238
obiekty rejestru, 233
problem, 231
RequestRegistry, 236
SessionRegistry, 236
testowanie, 234
wytwrnie obiektw, 233
zasig, 234, 235
zasig aplikacji, 237
zasig sesji, 236
zasig dania, 235
reguy produkcyjne, 198
rejestr, 231, 232
rejestrowanie wywoa zwrotnych, 331
relacja dziedziczenia, 100
relacja uycia, 128
relacje, 276
relacyjne bazy danych, 276
ReplaceTokens, 413
repozytorium PEAR, 31, 93, 141, 316, 317, 318, 323
repozytorium Subversion, 318, 359
reprezentacja obiektu w cigach znakw, 80
reprezentacja zada, 197
Request, 264, 389
RequestHelper, 223
require(), 92, 93, 94
require_once(), 91, 92, 93, 94
resource, 40
RESTful API, 229
retrospekcja, 102, 108
rewind(), 280
rewizja kodu, 23
role plikw pakietu PEAR, 335
rozgazianie projektu, 369
rozprzenie, 149, 171, 444
rozszerzanie klasy bazowej, 44
rozszerzona notacja Backusa-Naura, 198
rwnolege instrukcje warunkowe, 152
RPC, 93
rzutowanie obiektu na cig znakw, 34
S
Scrum, 378
SELECT, 279
Selection Factory, 306, 312
implementacja, 306
konsekwencje, 309
problem, 306
Selenese, 393
SKOROWIDZ
Selenium, 393
akcesory, 394
akcje, 394
asercje, 394
instalacja, 393
polecenie testu, 394
Selenese, 393
tworzenie testu, 393
zmiana formatu zapisanego testu jednostkowego, 395
Selenium IDE, 393
Selenium RC, 393
self, 58, 65
separacja modelu dziedziny od warstwy danych, 273
serializacja, 238, 239
Service Layer, 266
serwer integracji cigej, 427
sesje, 234
inicjowanie, 237
Session Facade, 266
session_start(), 237
set_include_path(), 95
setExpectedException(), 381
SHM, 238
silne sprzenie, 444, 447
SimpleXml, 67
SimpleXML API, 41
simplexml_load_file(), 41, 67, 71
Singleton, 161, 175, 176, 447
ilustracja graficzna, 163
implementacja, 162
konsekwencje, 163
problem, 161
stosowanie, 163
skaner, 459, 463
skadnia wywoania statycznego, 58
skadowe, 34, 35
badanie, 100
definiowanie, 35
diagramy klas, 125
dokumentacja, 351
dostp do skadowych, 35
PHP4, 35
skadowe dynamiczne, 36
skadowe stae, 60
skadowe statyczne, 57
widoczno, 35
skrypt transakcji, 266
sowa kluczowe
abstract, 61
as, 90
catch, 69
class, 33
clone, 78, 172, 175
const, 60
extends, 49, 64
final, 72
foreach, 280
function, 37, 83
implements, 63
interface, 62, 63
namespace, 89
new, 34
parent, 50, 52, 58
private, 35, 52, 121
protected, 35, 52, 121
public, 35, 52, 121
self, 58, 65
static, 57, 64, 65
throw, 69
try, 69
use, 90
var, 35, 52
sownictwo, 140
SOAP, 229
specjalizacja klas abstrakcyjnych, 61
specjalizacja klas wyjtku, 70
spikes, 32
SPL, 214, 215
SplObjectStorage, 214, 215
SplObserver, 214, 215
SplSubject, 214, 215
spjno, 117
sprzenie, 118, 149, 444
osabianie sprzenia, 150
SQLite, 59, 150
SSH, 360
ssh-keygen, 360
stae skadowe, 60
Standard PHP Library, 100, 214
standardy kodowania, 424
PHP_CodeSniffer, 424
Zend, 424
static, 57, 64, 65
strategia, 147
Strategy, 147, 205
implementacja, 206
problem, 205
string, 40
stringContains(), 383
struktura dziedziczenia, 145
strukturalizacja klas pod ktem elastycznoci obiektw, 179
Subversion, 317, 357, 421, 449
aktualizacja zmian, 363
branch, 361
branches, 361, 368
checkout, 363
dodawanie katalogu, 367
dodawanie pliku, 367
dodawanie projektu, 361
dostp do repozytorium, 360
eksportowanie projektu, 369
etykietowanie projektu, 368
491
SKOROWIDZ
Subversion
ga gwna, 361, 368
gazie, 361, 368
importowanie, 361
instalacja, 358
komunikaty importu, 362
konfiguracja repozytorium, 359
konflikty zmian, 365
migawki, 361
organizacja wersjonowania, 361
projekt, 361
protokoy komunikacji, 360
przemieszczanie katalogw, 361
repozytorium, 318, 359
rozgazianie projektu, 369
rozwizywanie konfliktw, 366
scalanie, 372
SSH, 360
struktura katalogw projektu, 361
tag, 361
tags, 361, 368
trunk, 361, 368, 369
tworzenie repozytorium, 359
URL, 360
usuwanie katalogu, 368
usuwanie pliku, 367
wyciganie kopii roboczej projektu, 363
wyciganie nowej gazi kodu, 370
wysyanie nowej wersji pliku do repozytorium, 365
wysyanie zmienionego pliku do repozytorium, 364
zarzdzanie wieloma wersjami projektu, 361
zatwierdzanie zmian, 363
SUnit, 378
Suraski Z., 30
svn, 358, 360
add, 367, 368
checkout, 363, 370
commit, 364, 366, 367, 371
copy, 368, 370
export, 369
import, 361, 421
list, 369
merge, 372
remove, 367, 368
resolve, 366
status, 364
update, 364, 365, 366
svnadmin create, 359
switch, 123
sygnalizowanie argumentw tablicowych, 44
sygnalizowanie bdw, 69
sygnalizowanie oczekiwanego typu, 43
symbole kocowe, 198
symulowanie systemu pakietw na bazie systemu plikw, 92
system integracji cigej, 450
system kontroli wersji, 317, 357, 358, 421
492
cieki przeszukiwania, 93
cise sprzganie, 118, 149
rodowisko programistyczne, 425
T
tabele, 276
kolumny, 276
wiersze, 276
tablice, 40
Template Method, 202, 276
Template View, 228, 263
implementacja, 264
konsekwencje, 265
problem, 264
terminals, 198
test case, 376
TestCase, 383, 386
onConsecutiveCalls(), 386
returnValue(), 386
testowanie, 23, 320, 375, 397, 449
asercje, 379
atrapy, 383, 397
imitacje, 383, 397
koszt rozwoju projektu, 397
PHPUnit, 378
przypadek testowy, 376
testowanie rczne, 376
testowanie systemu, 229
wyjtki, 380
zarzdzanie rodowiskiem testu, 384
zestaw testw, 381
testowanie aplikacji WWW, 229, 389
przygotowanie do testw, 389
przypadki testowe, 391
testy, 320, 419, 420
testy funkcjonalne, 375
testy regresyjne, 388
testy warunkw, 445
testy jednostkowe, 375, 376
atrapy, 383
ciga integracja, 422
imitacje, 383
ograniczenia, 382
pokrycie kodu, 423
Thomas D., 232
throw, 69
tokens, 459
SKOROWIDZ
U
uchwyty, 40
udostpnianie obiektw danych, 231
ukrywanie danych, 121
ukrywanie implementacji, 149
ukrywanie skadowych, 53
UML, 123, 124
diagramy klas, 124
diagramy sekwencji, 129
dziedziczenie, 126, 144
Unified Modeling Language, 124
unikatowo nazw klas, 88
V
valid(), 280
var, 35, 52
var_dump(), 34, 104
View Helper, 264
Visitor, 140, 216
implementacja, 217
problem, 216
wady wzorca, 221
Vlissides J., 23
W
warstwa danych, 229, 275
warstwa logiki biznesowej, 229, 266
warstwa polece i kontroli, 229
warstwa prezentacji, 229, 240
warstwa trwaoci, 311
warstwa widoku, 229
warstwy systemu korporacyjnego, 228
wartoci logiczne, 39, 41
warto pusta, 40
wdraanie, 318
WebDav, 360
WHERE, 302
wizanie statyczne, 64
widoczno, 52
widoczno metod, 37
widoczno skadowych, 35
widok, 229, 240
493
SKOROWIDZ
494
X
Xdebug, 423
XML, 40, 67
XML_Feed_Parser, 331, 332
SKOROWIDZ
XML_RPC_Server, 93
XmlException, 70
XP, 23, 153
XSLT, 413
XsltFilter, 413
xUnit, 378
Z
zadanie kompilacji, 403, 404
zagniedanie przestrzeni nazw, 89
zalenoci pakietw PEAR, 337
zaleno systemu od platformy zewntrznej, 149
zapytania SQL, 264, 268, 279
zarzdzanie dostpem do klasy, 52
zarzdzanie grupami obiektw, 180
zarzdzanie kanaem PEAR, 341
zarzdzanie kolekcjami wielowierszowymi, 283
zarzdzanie relacjami zachodzcymi pomidzy daniami,
logik dziedziny a prezentacj, 259
zarzdzanie serializacj, 239
zarzdzanie rodowiskiem testu, 384
zarzdzanie wersjami, 357, 449
zarzdzanie wieloma wersjami projektu, 361
zasady projektowe, 447
zasig, 32, 35, 234
zasig aplikacji, 234
zasig klas, 118
495