You are on page 1of 38

IDZ DO

PRZYKADOWY ROZDZIA
SPIS TRECI

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

Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl

PHP5. Zaawansowane
programowanie
Autorzy: Edward Lecky-Thompson, Heow
Eide-Goodman, Steven D. Nowicki, Alec Cove
Tumaczenie: Adam Byrtek,
Jarosaw Dobrzaski, Pawe Gonera
ISBN: 83-7361-825-2
Tytu oryginau: Professional PHP5
Format: B5, stron: 664
PHP to jzyk umoliwiajcy tworzenie aplikacji sieciowych uruchamianych po stronie
serwera. Jego najnowsza wersja, oznaczona numerem 5, to w peni obiektowy jzyk,
za pomoc ktrego mona budowa nawet najbardziej zoone systemy portalowe,
intranetowe i ekstranetowe. Dziki nowym funkcjom wprowadzonym w PHP 5 moliwe
jest korzystanie z plikw XML i protokou SOAP, wydajna komunikacja z baz danych
i stosowanie technik obiektowych znacznie uatwiajcych i przyspieszajcych tworzenie
rozbudowanych aplikacji.
PHP5. Zaawansowane programowanie to ksika przedstawiajca potne
moliwoci i elastyczno najnowszej wersji tej popularnej platformy programistycznej.
Opisuje podstawowe zasady programowania obiektowego i prowadzenia
rozbudowanych projektw informatycznych. Zawiera informacje o modelowaniu
aplikacji w jzyku UML, stosowaniu wzorcw projektowych i tworzeniu narzdzi,
ktre bdzie mona wykorzysta w kadym projekcie. Przedstawia rwnie analiz
prawdziwego przypadku systemu automatyzujcego prac dziau sprzeday
w przedsibiorstwie handlowym.
Programowanie obiektowe
Jzyk UML i modelowanie systemw
Wzorce projektowe
Tworzenie prostych narzdzi obiektowych
Poczenia z bazami danych
Model MVC
Stosowanie protokou SOAP
Komunikacja z uytkownikiem i mechanizmy sesji
Testowanie aplikacji
Studium przypadku automatyzacja pracy dziau sprzeday

Jeli chcesz pozna zaawansowane moliwoci PHP 5, signij po t ksik

Spis treci
O Autorach ................................................................................................................................................ 13
Wstp ....................................................................................................................................................... 15

Cz I Technologia obiektowa

21

Rozdzia 1. Wprowadzenie do programowania obiektowego ................................................................23


Czym jest programowanie obiektowe? .......................................................................... 23
Zalety programowania obiektowego ......................................................................... 24
Przykad z ycia ..................................................................................................... 25
Pojcia zwizane z programowaniem obiektowym ........................................................... 25
Klasy ................................................................................................................... 26
Obiekty ................................................................................................................ 27
Dziedziczenie ........................................................................................................ 36
Interfejsy .............................................................................................................. 45
Hermetyzacja ........................................................................................................ 48
Zmiany w PHP5 dotyczce programowania obiektowego .................................................. 49
Podsumowanie .......................................................................................................... 50

Rozdzia 2. Unified Modeling Language (UML) ........................................................................................ 51


Zbieranie wymaga ..................................................................................................... 51
Rozmowa z klientem .............................................................................................. 52
Diagramy przypadkw uycia ................................................................................... 53
Diagramy klas ............................................................................................................ 54
Modelowanie dziedziny .......................................................................................... 55
Relacje ................................................................................................................ 56
Implementacja ...................................................................................................... 58
Diagramy aktywnoci .................................................................................................. 61
Diagramy przebiegu .................................................................................................... 63
Diagramy stanw ........................................................................................................ 65
Diagram komponentw i instalacji ................................................................................ 66
Podsumowanie .......................................................................................................... 67

PHP5. Zaawansowane programowanie


Rozdzia 3. Obiekty zaczynaj dziaa ....................................................................................................69
Tworzenie menedera kontaktw .................................................................................. 69
Diagramy UML dla menedera kontaktw ................................................................. 70
Klasa PropertyObject ............................................................................................. 74
Klasy z informacjami kontaktowymi ......................................................................... 76
Klasa DataManager ............................................................................................... 80
Klasy Entity, Individual i Organization ....................................................................... 81
Uycie systemu ..................................................................................................... 88
Podsumowanie .......................................................................................................... 90

Rozdzia 4. Wzorce projektowe .............................................................................................................. 91


Wzorzec zoony ......................................................................................................... 92
Implementacja ...................................................................................................... 93
Przemylenia ........................................................................................................ 97
Wzorzec obserwatora .................................................................................................. 98
Widget ................................................................................................................. 98
Przemylenia ...................................................................................................... 104
Wzorzec dekoratora .................................................................................................. 104
Implementacja .................................................................................................... 106
Korzystanie z dekoratora ...................................................................................... 107
Przemylenia ...................................................................................................... 108
Wzorzec fasady ........................................................................................................ 109
Wzorzec budowniczego .............................................................................................. 111
Implementacja .................................................................................................... 111
Przemylenia ...................................................................................................... 115
Podsumowanie ........................................................................................................ 115

Cz II Tworzenie obiektowego zestawu narzdziowego. Proste klasy i interfejsy

117

Rozdzia 5. Klasa Collection ...........................................................................................................................119


Zaoenia klasy Collection ............................................................................................. 119
Projektowanie klasy Collection ....................................................................................... 120
Fundamenty klasy Collection ......................................................................................... 121
Metoda addItem ...................................................................................................... 122
Metody getItem i removeItem ................................................................................... 123
Pozostae metody .................................................................................................... 123
Uycie klasy Collection ............................................................................................. 124
Implementacja leniwej konkretyzacji .............................................................................. 125
Funkcje zwrotne ...................................................................................................... 126
Metoda setLoadCallback w klasie Collection ............................................................. 130
Wykorzystanie klasy Collection ...................................................................................... 133
Ulepszanie klasy Collection ........................................................................................... 139
Podsumowanie ............................................................................................................. 139

Rozdzia 6. Klasa CollectionIterator .............................................................................................................141


Interfejs Iterator ............................................................................................................ 141
Klasa CollectionIterator ........................................................................................... 143
Interfejs IteratorAggregate ............................................................................................. 144
Ochrona zawartoci iteratora ......................................................................................... 146
Podsumowanie ............................................................................................................. 147

Spis treci

Rozdzia 7. Klasa GenericObject ..................................................................................................................149


Klasa GenericObject ..................................................................................................... 149
Kiedy korzysta z GenericObject? ............................................................................. 150
Na co pozwala GenericObject? ................................................................................. 150
Decyzje w sprawie implementacji ............................................................................. 151
Typowa implementacja GenericObject ....................................................................... 152
Poznawanie rodzica ................................................................................................. 154
Wsppraca z baz danych ....................................................................................... 157
Metody i wasnoci GenericObject ............................................................................ 159
Zalety klasy GenericObject ....................................................................................... 161
Klasa GenericObjectCollection ....................................................................................... 162
Tradycyjna implementacja ........................................................................................ 163
Kiedy tradycyjna implementacja zawodzi ................................................................... 163
Dziaanie klasy GenericObjectCollection .................................................................... 164
Kod klasy ................................................................................................................ 165
Typowa implementacja GenericObjectCollection ........................................................ 167
Prba ...................................................................................................................... 168
Jak to dziaa? .......................................................................................................... 168
Podsumowanie klasy GenericObjectCollection ........................................................... 170
Podsumowanie ............................................................................................................. 171

Rozdzia 8. Warstwa abstrakcji dla bazy danych ....................................................................................173


Czym jest warstwa abstrakcji? ....................................................................................... 174
Prosta implementacja ................................................................................................... 174
Plik konfiguracyjny ................................................................................................... 174
Nawizywanie poczenia ......................................................................................... 175
Pobieranie danych ................................................................................................... 175
Modyfikacja danych ................................................................................................. 176
Korzystanie z klasy Database ................................................................................... 178
Wprowadzenie do PEAR DB ........................................................................................... 180
Nawizywanie poczenia za pomoc DB .................................................................. 181
Pobieranie danych ................................................................................................... 182
Inne uyteczne funkcje ............................................................................................. 183
Wicej informacji ..................................................................................................... 186
Gotowa warstwa abstrakcji ............................................................................................ 186
Obsuga transakcji ................................................................................................... 189
Wzorzec projektowy Singleton .................................................................................. 191
Podsumowanie ............................................................................................................. 193

Rozdzia 9. Interfejs fabryki ........................................................................................................................195


Wzorzec fabryki ............................................................................................................. 195
Przykad interfejsu fabryki .............................................................................................. 196
Rozwizanie staromodne ......................................................................................... 196
Wykorzystanie interfejsu fabryki ............................................................................... 197
Zastosowanie wzorca w abstrakcji bazy danych ......................................................... 198
Wiksza liczba fabryk .................................................................................................... 200
Wykorzystanie klas istniejcych ..................................................................................... 201
Podsumowanie ............................................................................................................. 201

PHP5. Zaawansowane programowanie


Rozdzia 10. Programowanie oparte na zdarzeniach .............................................................................203
Czym s zdarzenia? ...................................................................................................... 204
Obiektowa obsuga zdarze ........................................................................................... 205
Projekt rozwizania .................................................................................................. 205
Implementacja rozwizania ...................................................................................... 207
Implementacja zabezpiecze .................................................................................... 211
Chwila zastanowienia .............................................................................................. 213
Podsumowanie ............................................................................................................. 214

Rozdzia 11. Pliki dziennika i debugowanie .................................................................................................215


Tworzenie mechanizmu logowania ................................................................................. 215
Proste logowanie do pliku ........................................................................................ 215
Przykadowa struktura katalogw .............................................................................. 216
Klasa Logger ........................................................................................................... 217
Rozbudowa klasy Logger .......................................................................................... 221
Mechanizm debugowania .............................................................................................. 231
Podsumowanie ............................................................................................................. 234

Rozdzia 12. SOAP ..........................................................................................................................................235


SOAP i PHP5 ................................................................................................................ 235
Rozszerzenie PHP5 SOAP ........................................................................................ 236
Klient SOAP .................................................................................................................. 239
Za kulisami ............................................................................................................. 241
Obsuga wyjtkw w kliencie SOAP ........................................................................... 245
Serwer SOAP ................................................................................................................ 246
Podsumowanie ............................................................................................................. 248

Cz III Tworzenie zestawu narzdzi do wielokrotnego wykorzystania.


Narzdzia zoone (cho nieskomplikowane)

249

Rozdzia 13. Model, widok, kontroler (MVC) ..............................................................................................251


Wprowadzenie do MVC .................................................................................................. 252
Model ..................................................................................................................... 253
Widok ..................................................................................................................... 253
Kontroler ................................................................................................................. 253
Infrastruktura .......................................................................................................... 253
MVC w aplikacjach WWW ......................................................................................... 253
MVC w PHP ............................................................................................................. 254
May zestaw narzdzi MVC ............................................................................................ 256
Prezentacja zestawu narzdzi ................................................................................... 256
Korzystanie z zestawu narzdzi ................................................................................ 268
Zestaw narzdzi a praktyka ...................................................................................... 275
Prawdziwe szablony ...................................................................................................... 275
Powtrka z szablonw macierzystych PHP ................................................................. 275
Wady szablonw macierzystych ................................................................................ 276
Prawdziwe szablony a szablony pakietu Smarty ......................................................... 276
Instalowanie pakietu Smarty .................................................................................... 277
Korzystanie z pakietu Smarty ................................................................................... 278
Zaawansowane moliwoci pakietu Smarty ............................................................... 283
Kiedy korzysta z pakietu Smarty, a kiedy z tradycyjnych szablonw? ......................... 285
Podsumowanie ............................................................................................................. 285

Spis treci

Rozdzia 14. Komunikacja z uytkownikami ..............................................................................................287


Po co si komunikowa? ............................................................................................... 287
Powody komunikowania si z uytkownikiem ............................................................. 288
Mylenie wykraczajce poza przegldark WWW ....................................................... 290
Formy komunikacji ........................................................................................................ 291
Wszystkie formy komunikacji maj ........................................................................ 291
Nie wszystkie formy komunikacji maj ................................................................... 291
Co z adresatami? .................................................................................................... 291
Komunikacja jako hierarchia klas ................................................................................... 292
Klasa adresata szybki sprawdzian z mylenia obiektowego ................................... 292
Klasa Communication .............................................................................................. 296
Wysyanie wiadomoci do uytkownikw naszej witryny ................................................... 298
Tworzenie wersji testowej ........................................................................................ 298
Wysyanie wiadomoci ............................................................................................. 302
Zastosowanie szablonw przy wykorzystaniu pakietu Smarty ..................................... 307
Korzystanie z MIME ................................................................................................. 309
Inne podklasy klasy Communication .............................................................................. 309
Wiadomoci tekstowe SMS ...................................................................................... 309
Faks ....................................................................................................................... 310
Podsumowanie ............................................................................................................. 310

Rozdzia 15. Sesje i uwierzytelnianie ...........................................................................................................311


Wprowadzenie do sesji .................................................................................................. 312
Krtka powtrka z protokou HTTP ............................................................................ 312
Definicja sesji ......................................................................................................... 314
Cigo sesji .......................................................................................................... 314
Bezpieczestwo sesji ............................................................................................... 317
Jak PHP implementuje sesje? ........................................................................................ 324
Podstawowy mechanizm sesji w PHP ........................................................................ 324
Ograniczenia podstawowego mechanizmu sesji w PHP .............................................. 326
Tworzenie klasy Authentication ...................................................................................... 327
Poczenie zarzdzania sesjami PHP z baz danych .................................................. 327
Klasa UserSession .................................................................................................. 329
Schemat bazy danych .............................................................................................. 329
Kod usersession.phpm ....................................................................................... 330
Kod testowanie klasy UserSession ...................................................................... 334
Jak to dziaa klasa UserSession .......................................................................... 336
Co otrzymalimy? .................................................................................................... 339
Podsumowanie ............................................................................................................. 339

Rozdzia 16. Szkielet do testowania moduw ...........................................................................................341


Metodologia i terminologia ............................................................................................ 341
Projektowanie interfejsu klasy .................................................................................. 342
Tworzenie pakietu testowego dla klasy ..................................................................... 343
Pisanie implementacji naszej klasy .......................................................................... 344
Druga tura ............................................................................................................... 345
Wprowadzenie do PHPUnit ............................................................................................. 345
Instalacja PHPUnit ................................................................................................... 345
Korzystanie z PHPUnit ................................................................................................... 346
Przypadki testowania ............................................................................................... 346
Pakiet testujcy ....................................................................................................... 349

PHP5. Zaawansowane programowanie


Czy warto? .................................................................................................................... 349
Powtrne testy ........................................................................................................ 350
Uyteczno szkieletu .............................................................................................. 350
Demonstrowalny mechanizm zapewniania jakoci ..................................................... 350
Redukcja obcienia testami funkcjonalnymi ............................................................ 351
Praktyczny przykad ....................................................................................................... 351
Podsumowanie ............................................................................................................. 356

Rozdzia 17. Automat skoczony i modyfikowalne pliki konfiguracyjne ...............................................357


Koncepcja automatu skoczonego ................................................................................. 358
Prosty AS kalkulator ONP .................................................................................... 359
Teoretyczna implementacja AS ................................................................................. 360
Implementacja automatw skoczonych w PHP ......................................................... 361
Analiza przykadu z kalkulatorem ONP ....................................................................... 363
Przykady automatw skoczonych w praktyce ........................................................... 366
Modyfikowalne pliki konfiguracyjne ................................................................................ 367
Zastosowanie PHP .................................................................................................. 367
Zastosowanie XML-a ................................................................................................ 368
Korzystanie z plikw INI ........................................................................................... 369
Klasa Config z PEAR ................................................................................................ 371
Zalecane praktyki zwizane z plikami konfiguracyjnymi .............................................. 372
Podsumowanie ............................................................................................................. 373

Cz IV Studium przypadku automatyzacja dziau sprzeday

375

Rozdzia 18. Przegld projektu ...................................................................................................................377


Artykulandia ................................................................................................................. 378
Krajobraz Artykulandii .................................................................................................... 380
Wymiar techniczny ................................................................................................... 380
Wymiar finansowy .................................................................................................... 380
Wymiar polityczny .................................................................................................... 380
My .......................................................................................................................... 380
Czy rzeczywicie chodzi o technologi? ..................................................................... 381
Podejcie do budowy oprogramowania ........................................................................... 381
Jakie konsekwencje ma to dla nas? ......................................................................... 383
Technologia ............................................................................................................ 384
Podsumowanie ............................................................................................................. 385

Rozdzia 19. Metody zarzdzania projektami ...........................................................................................387


Wstpne rozeznanie ...................................................................................................... 387
Dlaczego realizujemy projekt? .................................................................................. 388
Dla kogo realizujemy projekt? ................................................................................... 388
Jaka jest historia projektu? ...................................................................................... 390
Jakie s oczekiwane warunki wstpne projektu? ....................................................... 390
Odbieranie formalnych wytycznych ................................................................................. 391
Wymogi obszaru dziaalnoci .................................................................................... 392
Zakres .................................................................................................................... 393
Harmonogramy ........................................................................................................ 394
Budet .................................................................................................................... 395
Warunki handlowe ................................................................................................... 397
Plany na przyszo ................................................................................................. 398

Spis treci

Wygld i obsuga ..................................................................................................... 398


Technologia ............................................................................................................ 398
Obsuga .................................................................................................................. 399
Co dalej? ................................................................................................................ 399
Konstruowanie oferty .................................................................................................... 399
Konspekty kontra oferty cenowe ............................................................................... 399
Oferty w formie konspektu a specyfikacje ................................................................. 400
Kogo zaangaowa w tworzenie oferty? ..................................................................... 401
Kiedy mona da z siebie wicej? ............................................................................. 401
Kiedy powiedzie nie? .......................................................................................... 402
Struktura oferty ....................................................................................................... 402
Wybieranie ludzi ............................................................................................................ 404
Meneder projektu ................................................................................................... 404
Account manager .................................................................................................... 404
Gwny architekt ...................................................................................................... 405
Architekci i inynierowie oprogramowania .................................................................. 406
Programici interfejsu klienckiego ............................................................................ 406
Starsi projektanci .................................................................................................... 406
Graficy .................................................................................................................... 406
Podwjne role ......................................................................................................... 407
Sposb pracy .......................................................................................................... 407
Rola klienta ............................................................................................................. 407
Podsumowanie ............................................................................................................. 408

Rozdzia 20. Planowanie systemu ..............................................................................................................409


Wybr procesu .............................................................................................................. 409
Proces kaskadowy ................................................................................................... 409
Proces spiralny ........................................................................................................ 410
Wybr procesu ........................................................................................................ 412
Praktyki wsplne dla obydwu procesw .......................................................................... 412
Faza specyfikacji ..................................................................................................... 412
Faza projektowania .................................................................................................. 415
Faza budowy ........................................................................................................... 416
Faza testowania ...................................................................................................... 417
Odbir .................................................................................................................... 418
Metodyki i praktyki programowania ................................................................................ 418
Programowanie inicjowane testami ........................................................................... 418
Programowanie ekstremalne .................................................................................... 419
Zarzdzanie zmianami ................................................................................................... 422
Rewizje specyfikacji ................................................................................................. 422
Zmiany w specyfikacji, ktre pojawiaj si po jej podpisaniu ...................................... 422
Dyskusje wynikajce z rnych interpretacji ............................................................... 423
Bdy zgoszone przez klienta ................................................................................... 423
Podsumowanie ............................................................................................................. 423

Rozdzia 21. Architektura systemw .........................................................................................................425


Czym jest architektura systemu? ................................................................................... 425
Dlaczego to takie wane? ........................................................................................ 426
Co musimy zrobi? .................................................................................................. 426
Efektywne tumaczenie wymaga ................................................................................... 427
Hosting, cza, serwery i sie ................................................................................... 427
Nadmiarowo i elastyczno .................................................................................. 428

10

PHP5. Zaawansowane programowanie


Utrzymanie .............................................................................................................. 428
Bezpieczestwo ....................................................................................................... 429
Projektowanie rodowiska ............................................................................................. 429
Hosting i cza ........................................................................................................ 429
Obliczanie parametru CIR ......................................................................................... 430
Serwery .................................................................................................................. 432
Sie ........................................................................................................................ 434
Zapis nadmiarowy ................................................................................................... 434
Utrzymanie .............................................................................................................. 435
Bezpieczestwo ....................................................................................................... 435
Podsumowanie ............................................................................................................. 436

Rozdzia 22. Tworzenie aplikacji automatyzujcej prac zespou sprzeday ....................................437


Rozpoczynamy projekt poniedziaek ........................................................................... 438
Zamieniamy si w such ........................................................................................... 438
Oszacowanie wagi scenariuszy ................................................................................. 440
Planowanie wersji .................................................................................................... 447
Rozpoczynamy prac ..................................................................................................... 448
Opis szczegw scenariusza nr 9 ............................................................................ 448
Tworzenie testw ..................................................................................................... 449
PHPUnit .................................................................................................................. 450
Tworzenie ekranu logowania .................................................................................... 457
Nastpny scenariusz ............................................................................................... 460
Ponowne oszacowanie ............................................................................................. 469
Porzdki ....................................................................................................................... 471
Refaktoring kodu ..................................................................................................... 472
Koczenie iteracji ......................................................................................................... 478
Scenariusz nr 14. Zmiana tygodnia powoduje odczytanie poprzedniego ...................... 478
Scenariusz nr 15. Tygodniowe pola na raporcie wizyt klienta ...................................... 480
Raport kosztw podry ................................................................................................ 487
Skadnik kosztw podry ........................................................................................ 489
Tygodniowe koszty podry ...................................................................................... 492
Narzut ..................................................................................................................... 494
Kolejne testy tygodniowych kosztw podry ............................................................. 495
Wypenianie testw tygodniowego arkusza kosztw podry ....................................... 498
Zakoczony raport kosztw podry ............................................................................... 510
Obiekty fikcyjne ............................................................................................................ 522
Podsumowanie ............................................................................................................. 527

Rozdzia 23. Zapewnienie jakoci ..............................................................................................................529


Wprowadzenie do QA .................................................................................................... 529
Dlaczego warto si stara? ...................................................................................... 530
Co to jest jako? ................................................................................................... 531
Wymierna jako ..................................................................................................... 532
Testowanie ................................................................................................................... 534
Testowanie moduw ............................................................................................... 535
Testowanie funkcjonalne ......................................................................................... 535
Testowanie obcienia ............................................................................................. 537
Testowanie uytecznoci .......................................................................................... 537
ledzenie bdw .......................................................................................................... 538
Efektywne ledzenie bdw z wykorzystaniem systemu Mantis ................................. 539
Wykorzystanie wszystkich moliwoci Mantis ............................................................ 546
Podsumowanie ............................................................................................................. 546

Spis treci

11

Rozdzia 24. Instalacja .................................................................................................................................549


Opracowywanie rodowiska programistycznego .............................................................. 549
Firmowe rodowisko rozwojowe ................................................................................ 550
Firmowe rodowisko testowe ................................................................................... 551
rodowisko testowe klienta ..................................................................................... 551
rodowisko produkcyjne klienta ............................................................................... 552
Rozwojowe bazy danych ........................................................................................... 553
Organizacja wdroenia ................................................................................................... 554
Automatyczne pobieranie z repozytorium kontroli wersji ............................................. 556
Zastosowanie rsync ................................................................................................. 557
Synchronizacja serwerw za pomoc rsync ............................................................... 559
Podsumowanie ............................................................................................................. 561

Rozdzia 25. Projektowanie i tworzenie solidnej platformy raportujcej ..........................................563


Wprowadzenie do danych roboczych ............................................................................... 563
Poznajemy potrzeby klienta ...................................................................................... 564
Zarzdzanie daniami klientw ............................................................................... 564
Dostarczanie raportw ............................................................................................. 566
Projektowanie raportu .............................................................................................. 566
Architektura generatora raportw ................................................................................... 569
Generowanie raportw w tle ..................................................................................... 571
Interfejs raportw .................................................................................................... 573
Interfejs nowego raportu .......................................................................................... 574
Skrypt procesora raportw ....................................................................................... 578
Proces .................................................................................................................... 578
Skrypty obsugi raportw .......................................................................................... 579
Strona Moje raporty ................................................................................................. 581
Skrypty tumaczce .................................................................................................. 581
Przykad uycia platformy raportowej ......................................................................... 583
Wizualizacja ............................................................................................................ 584
Podsumowanie ............................................................................................................. 585

Rozdzia 26. Co dalej? ..................................................................................................................................587


Motywacja .................................................................................................................... 587
Twoja kariera programisty .............................................................................................. 588
Wicej ni tylko programowanie WWW ...................................................................... 588
Umiejtnoci mikkie .............................................................................................. 589
Umiejtnoci teoretyczne ......................................................................................... 589
Umiejtnoci spoeczne ........................................................................................... 589
Podsumowanie ............................................................................................................. 590

Dodatki

591

Dodatek A Dlaczego warto korzysta z kontroli wersji .........................................................................593


Dodatek B IDE dla PHP ...................................................................................................................................607
Dodatek C Strojenie wydajnoci PHP ..........................................................................................................621
Dodatek D Najlepsze praktyki przy instalacji PHP ..................................................................................633
Skorowidz ............................................................................................................................................. 645

1
Wprowadzenie
do programowania obiektowego
Programowanie obiektowe moe wprowadza zamieszanie w gowach programistw tworzcych gwnie kod proceduralny. Moe, ale nie musi. W niniejszym rozdziale omwimy
podstawowe zagadnienia teoretyczne zwizane z technologi obiektow i poznamy obowizujc w tej dziedzinie terminologi (pen odstraszajcych czasem wielosylabowcw).
Powiemy, dlaczego warto interesowa si technikami obiektowymi i w jaki sposb mog
one znacznie przyspieszy proces programowania rozbudowanych aplikacji oraz uatwi ich
pniejsze modyfikacje.
W dwch nastpnych rozdziaach bdziemy poszerza t wiedz i wgbia si w nieco bardziej
zaawansowane tematy. Ci, ktrzy maj wczeniejsze dowiadczenia z programowaniem obiektowym poza rodowiskiem PHP5, mog te dwa rozdziay pomin. Z drugiej strony, materia
ten moe stanowi dobr powtrk, wic mimo wszystko zachcamy do jego przeczytania.

Czym jest programowanie obiektowe?


Programowanie obiektowe wymaga innego sposobu mylenia przy tworzeniu aplikacji. Obiekty
umoliwiaj blisze odwzorowanie za pomoc kodu, rzeczywistych zada, procesw i idei,
ktre maj realizowa aplikacje. Zamiast traktowa aplikacj jako wtek sterowania, ktry
przesya dane pomidzy funkcjami, modelujemy j jako zbir wsppracujcych z sob obiektw, ktre niezalenie realizuj pewne zadania.
Analogi moe by przykad budowy domu. Hydraulicy zajmuj si instalacj wodn, a elektrycy instalacj elektryczn. Hydraulicy nie musz wiedzie, czy obwd w sypialni jest
10-amperowy czy 20-amperowy. Interesuje ich tylko to, co ma jaki zwizek z instalacj
wodn. Generalny wykonawca dopilnowuje tego, by kady z podwykonawcw zrobi to, co
do niego naley, ale przewanie nie interesuj go szczegy kadego pojedynczego zadania.

24

Cz I n Technologia obiektowa
Podejcie obiektowe jest podobne w tym sensie, e obiekty ukrywaj przed sob szczegy
swojej implementacji. Sposb wykonania zadania nie jest istotny dla innych komponentw
systemu. Liczy si to, jakie usugi obiekt moe wykona.
Pojcia klas i obiektw oraz sposoby korzystania z nich przy pisaniu programw to fundamentalne zagadnienia programowania obiektowego. S one w pewnym sensie sprzeczne
z zasadami programowania proceduralnego, czyli programowania korzystajcego z funkcji
i globalnych struktur danych. Jak zobaczymy, podejcie obiektowe ma kilka ogromnych
zalet w porwnaniu z proceduralnym, a nowa implementacja moliwoci programowania
obiektowego w PHP5 przynosi rwnie znaczne korzyci w wydajnoci.

Zalety programowania obiektowego


Jedn z gwnych zalet programowania obiektowego jest atwo przekadania poszczeglnych wymogw z obszaru zastosowania na poszczeglne moduy kodu. Poniewa podejcie
obiektowe pozwala na modelowanie aplikacji na podstawie obiektw z otaczajcej nas
rzeczywistoci, czsto moliwe jest odnalezienie bezporedniego przeoenia ludzi, rzeczy
i poj na odpowiadajce im klasy. Klasy te charakteryzuj si takimi samymi waciwociami i zachowaniami jak rzeczywiste pojcia, ktre reprezentuj, co pomaga w szybkim ustaleniu, jaki kod trzeba napisa i w jaki sposb zachodzi ma interakcja pomidzy poszczeglnymi czciami aplikacji.
Drug zalet programowania obiektowego jest moliwo wielokrotnego wykorzystania kodu.
Czsto potrzebujemy tych samych typw danych w rnych miejscach tej samej aplikacji.
Na przykad w aplikacji, ktra umoliwia szpitalowi zarzdzanie kartami swoich pacjentw,
z pewnoci potrzebna bdzie klasa  (osoba). W systemie opieki szpitalnej wystpuje
wiele rnych osb pacjent, lekarze, pielgniarki, czonkowie administracji szpitala itp. Na
kadym etapie zajmowania si pacjentem, wymagane jest odnotowanie w jego karcie osoby,
ktra wykonaa dan czynno (np. przepisaa lek, oczycia ran lub wystawia rachunek za
opiek medyczn), i zweryfikowanie, czy osoba jest do tej czynnoci uprawniona. Definiujc
ogln klas , ktra obejmuje wszystkie waciwoci i metody wsplne dla wszystkich
ludzi, otrzymujemy moliwo wykorzystania tego fragmentu kodu na naprawd olbrzymi
skal, co nie zawsze jest moliwe przy proceduralnym podejciu do programowania.
A co z innymi zastosowaniami? Czy moemy wyobrazi sobie inne aplikacje, ktre przetwarzaj informacje o osobach? Prawdopodobnie tak i to niemao. Dobrze napisana klasa 
mogaby by przenoszona z jednego projektu do drugiego z minimalnymi zmianami lub wrcz
bez zmian, udostpniajc od rki due moliwoci funkcjonalne stworzone przy okazji wczeniejszych prac. Moliwo wielokrotnego wykorzystania kodu zarwno w obrbie jednej
aplikacji, jak i od projektu do projektu, to jedna z wikszych zalet podejcia obiektowego.
Inna zaleta programowania obiektowego wynika z modularnoci klas. Jeeli odkryjemy bd
w klasie  albo bdziemy chcieli zmieni sposb jej dziaania czy te rozbudowa j,
to wszelkich zmian dokonujemy tylko w jednym miejscu. Wszystkie cechy funkcjonalne
klasy znajduj si w jednym pliku. Dokonane zmiany od razu odzwierciedlaj si we wszystkich procesach aplikacji, ktre bezporednio opieraj si na klasie . Znacznie upraszcza to szukanie bdw i czyni rozbudow klasy zabiegiem w miar bezbolesnym.

Rozdzia 1. n Wprowadzenie do programowania obiektowego

25

Przykad z ycia
Korzyci wynikajce z modularnoci mog wydawa si niewielkie w przypadku prostych
aplikacji, ale podczas wykorzystywania zoonych architektur oprogramowania bywaj potne. Jeden z autorw ksiki pracowa ostatnio nad projektem obejmujcych 200 tysicy
wierszy proceduralnego kodu PHP. Co najmniej 65% czasu powiconego na poprawianie
bdw zmarnowano na wyszukiwanie pewnych funkcji i sprawdzanie, jakie funkcje korzystaj z jakich danych. Pniej stworzono now wersj tego oprogramowania, tym razem
o architekturze obiektowej, ktra okazaa si skada z o wiele mniejszej iloci kodu. Gdyby
aplikacja od pocztku bya pisana w taki sposb, to nie tylko trwaoby to krcej, ale uniknito
by wielu bdw (im mniejsza ilo kodu, tym mniejsza ilo bdw), a proces ich usuwania byby znacznie szybszy.
Jako e podejcie obiektowe zmusza do zastanowienia si nad organizacj kodu, poznawanie struktury istniejcej aplikacji jest o wiele atwiejsze, kiedy doczamy jako nowy do
zespou programistw. Poza tym dysponujemy wwczas szkieletem pomocnym w ustalaniu,
gdzie powinny znale si nowo dodawane cechy funkcjonalne.
Nad wikszymi projektami czsto pracuj wieloosobowe zespoy programistw o rnych
umiejtnociach. Tutaj rwnie podejcie obiektowe ma znaczn przewag nad proceduralnym. Obiekty ukrywaj szczegy implementacyjne przed swoimi uytkownikami. Zamiast
koniecznoci zrozumienia zoonych struktur danych i pokrtnej logiki rzdzcej obszarem
zastosowania aplikacji mniej dowiadczeni czonkowie zespou mog na podstawie skromnej
dokumentacji zacz uywa obiektw stworzonych przez bardziej dowiadczonych programistw. Same obiekty s odpowiedzialne za dokonywanie zmian w danych oraz zmian stanu
systemu.
Kiedy wczeniej wspomniana aplikacja wci jeszcze bya pisana kodem proceduralnym,
nowi programici w zespole czsto musieli powici do dwch miesicy na nauk szczegw zwizanych z aplikacj, zanim stali si produktywni. Po przerobieniu aplikacji na
obiektow nowi czonkowie zespou mogli ju po kilku dniach tworzy obszerne dodatki
do istniejcej bazy kodu. Byli w stanie szybko nauczy si korzysta nawet z najbardziej
skomplikowanych obiektw, poniewa nie musieli w peni rozumie wszystkich szczegw
implementacji reprezentowanych przez nie cech funkcjonalnych.
Teraz, gdy ju wiemy, dlaczego naley rozway zastosowanie paradygmatu obiektowego
jako metody programowania, powinnimy przeczyta kilka nastpnych podrozdziaw, aby
lepiej zrozumie koncepcje lece u podstaw obiektowoci. Potem, ju w trakcie lektury
dwch kolejnych rozdziaw, powinnimy na wasnej skrze odczu zalety tego podejcia.

Pojcia zwizane z programowaniem obiektowym


W niniejszym podrozdziale wprowadzimy podstawowe pojcia ze wiata programowania
obiektowego i poznamy zalenoci miedzy nimi. W rozdziale 3., Obiekty zaczynaj dziaa, omwiono specyfik implementacji tych poj w PHP5. Poznamy tu midzy innymi:

26

Cz I n Technologia obiektowa
n

Klasy wzorce dla obiektw i kod definiujcy waciwoci i metody.

Obiekty stworzone egzemplarze klasy, ktre przechowuj wszelkie wewntrzne


dane i informacje o stanie potrzebne dla funkcjonowania aplikacji.

Dziedziczenie moliwo definiowania klas jednego rodzaju jako szczeglnego


przypadku (podtypu) klasy innego rodzaju (na podobnej zasadzie jak kwadrat
okrelany jest jako szczeglny przypadek prostokta).

Polimorfizm umoliwia zdefiniowanie klasy jako czonka wicej ni jednej


kategorii klas (tak jak samochd, ktry jest czym, co ma silnik oraz czym,
co ma koa).

Interfejsy stanowi umow na podstawie ktrej obiekt moe implementowa


metod, nie definiujc rzeczywistego sposobu implementacji.

Hermetyzacja moliwo zastrzeenia dostpu do wewntrznych danych obiektu.

Nie naley si przejmowa, jeeli ktry z tych terminw wydaje si trudny do zrozumienia.
Wszystkie zostan wyjanione dalej. Nowo zdobyta wiedza moe cakowicie zmieni nasze
podejcie do realizacji przedsiwzi programistycznych.

Klasy
W otaczajcej nas rzeczywistoci obiekty maj pewn charakterystyk i zachowania. Samochd ma kolor, wag, mark oraz bak paliwowy o pewnej pojemnoci. To jest jego charakterystyka. Samochd moe przyspiesza, zatrzyma si, sygnalizowa skrt lub trbi klaksonem. To s jego zachowania. Te cechy i zachowania s wsplne dla wszystkich samochodw.
Co prawda rne samochody maj rne kolory, ale kady samochd ma jaki kolor. W programowaniu obiektowym klasa umoliwia ustanowienie pojcia samochodu jako czego
posiadajcego wszystkie cechy uznane za wsplne. Klasa to zamknity fragment kodu zoony ze zmiennych i funkcji, ktre opisuj cechy oraz zachowania wsplne dla wszystkich
elementw pewnego zbioru. Klasa o nazwie  (samochd) opisywaaby waciwoci i metody wsplne dla wszystkich samochodw.
W terminologii obiektowej charakterystyki klasy okrela si mianem waciwoci. Waciwoci maj nazw i warto. Wartoci niektrych mona zmienia, a innych nie. Na przykad
w klasie  wystpiyby zapewne takie waciwoci jak 
 (kolor) czy   (waga).
Kolor samochodu moe ulec zmianie po lakierowaniu, ale waga samochodu (bez pasaerw
i bagau) jest wartoci sta.
Niektre waciwoci reprezentuj stan obiektu. Stan odnosi si do tych charakterystyk,
ktre ulegaj zmianie w efekcie pewnych zdarze, a niekoniecznie mona je modyfikowa
bezporednio. W aplikacji, ktra symuluje funkcjonowanie samochodu, klasa  moe mie
waciwo 
  (prdko). Prdko nie jest wartoci, ktr mona zmieni tak po
prostu, lecz kocowym efektem iloci paliwa przesanej do silnika, osigw tego silnika oraz
terenu, po jakim porusza si samochd.
Zachowania klas s okrelane mianem metod. Metody klas s skadniowymi odpowiednikami funkcji z tradycyjnych programw proceduralnych. Podobnie jak funkcje, metody mog
pobiera dowoln ilo parametrw, z ktrych kady jest pewnego dopuszczalnego typu.

Rozdzia 1. n Wprowadzenie do programowania obiektowego

27

Niektre metody przetwarzaj zewntrzne dane, przesane jako parametry, ale mog rwnie
dziaa na waciwociach wasnych obiektw, odczytujc ich wartoci na potrzeby wykonywanych dziaa (na przykad metoda  
, ktra symuluje nacinicie pedau gazu,
moe sprawdza ilo pozostaego paliwa, by ustali, czy przyspieszenie jest moliwe) albo
zmieniajc stan obiektw poprzez modyfikacj takich wartoci jak prdko samochodu.

Obiekty
Na pocztek klas mona potraktowa jako wzorzec, na postawie ktrego konstruowany jest
obiekt. Podobnie jak na podstawie tego samego projektu (wzorca) mona zbudowa wiele
domw, tak samo moliwe jest stworzenie wielu egzemplarzy obiektw jednej klasy. Jednak
projekt domu nie precyzuje takich szczegw jak kolor cian czy rodzaj posadzki, ustalajc
jedynie, e takie rzeczy istniej. Klasy funkcjonuj podobnie, okrelajc zachowania i charakterystyki obiektu, nie przesdzajc o ich konkretnej wartoci lub stanie. Obiekt to element
konkretny skonstruowany na podstawie wzorca dostarczonego przez klas. Oglne pojcie
dom mona porwna do klasy. Z kolei nasz dom (okrelony reprezentant pojcia dom)
mona porwna do obiektu.
Majc projekt czy wzorzec i jakie materiay budowlane, moemy zbudowa dom. W programowaniu obiektowym, aby zbudowa obiekt, posugujemy si klas. Proces ten nazywa
si tworzeniem egzemplarza i wymaga dwch rzeczy:
n

Miejsca w pamici przeznaczonego dla obiektu. Tym akurat PHP zajmie si


automatycznie.

Danych, ktre zostan przypisane wartociom waciwoci. Dane te mog pochodzi


z bazy danych, pliku tekstowego, innego obiektu lub jeszcze innego rda.

Sama klasa nie moe mie przypisanych wartoci do waciwoci albo by w jakim stanie.
Mog to jedynie obiekty. Aby zbudowa dom, trzeba posuy si projektem. Dopiero potem
moemy pomyle o tapetowaniu i panelach zewntrznych. Podobnie konieczne jest stworzenie egzemplarza obiektu klasy, zanim bdziemy mogli operowa na jego waciwociach
lub wywoywa jego metody. Klasami manipulujemy w czasie pisania programu, modyfikujc kod metod i waciwoci. Obiektami manipulujemy w trakcie wykonywania programu,
przypisujc wartoci waciwociom i wywoujc metody. Pocztkujcy adepci programowania obiektowego czsto nie s pewni, kiedy powinni posugiwa si pojciem klasy, a kiedy
obiektu.
Po utworzeniu obiektu mona go przystosowa tak, by implementowa wymogi obszaru
zastosowania aplikacji. Przyjrzyjmy si dokadnie, jak to si robi w PHP.

Tworzenie klasy
Zacznijmy od prostego przykadu. Zapisz poniszy kod w pliku o nazwie class.Demo.php:

 




28

Cz I n Technologia obiektowa
I ju. Wanie stworzylimy klas . Co prawda nie wyglda imponujco, ale to nic innego
jak podstawowa skadnia deklarowania nowej klasy w PHP. Uywamy sowa kluczowego

, aby poinformowa PHP, e mamy zamiar zdefiniowa now klas. Po nim podajemy
nazw klasy, a tre klasy zawieramy pomidzy klamr otwierajc a zamykajc.
Wane jest zdefiniowanie jasnej konwencji organizowania plikw z kodem rdowym.
Dobr zasad jest umieszczanie kadej klasy w osobnym pliku i nadanie mu nazwy
class.[NazwaKlasy].php.

Obiekt typu  mona utworzy tak:



     

 
 



Aby utworzy obiekt, najpierw naley si upewni, czy PHP wie, gdzie odnale deklaracj
klasy poprzez doczenie pliku z treci klasy (w tym przykadzie jest to class.Demo.php),
potem wywoa operator  i poda nazw klasy oraz par nawiasw. Warto zwracana
przez t instrukcj zostaje przypisana do nowej zmiennej . Teraz mona ju wywoywa metody obiektu  i odczytywa lub ustawia jego waciwoci o ile zosta
w takowe wyposaony.
Mimo e klasa, ktr wanie stworzylimy, w zasadzie nic nie robi, wci stanowi poprawn
definicj klasy.

Dodawanie metody
Klasa  nie bdzie zbyt przydatna, jeeli nie bdzie nic robi. Przyjrzyjmy si wic, jak
stworzy metod. Pamitajmy, e metoda klasy to po prostu funkcja. Piszc tre funkcji pomidzy klamrami otwierajcymi i zamykajcymi definicj klasy, dodajemy do klasy now
metod. Oto przykad:

 

!"  #$   
"%&' ()* +%




Obiekt stworzony na postawie klasy moe teraz wywietli pozdrowienia dla kadego, kto
wywoa metod 

. Aby wywoa t metod na obiekcie , konieczne jest


zastosowanie operatora  umoliwiajcego dostp do utworzonej funkcji:

     

 
 

 
, #$  -" !


Obiekt jest teraz w stanie wywietli tekst przyjaznego pozdrowienia. Operator  suy do
dostpu do wszystkich metod i waciwoci obiektw.

Rozdzia 1. n Wprowadzenie do programowania obiektowego

29

Tym, ktrzy mieli do czynienia z programowaniem obiektowym w innych jzykach, zwracamy


uwag, e dostp do metod i waciwoci obiektu jest realizowany za pomoc operatora
. Operator kropki () nie wystpuje w skadni PHP w ogle.

Dodawanie waciwoci
Dodawanie waciwoci do klasy jest rwnie proste jak dodawanie metody. Wystarczy
zadeklarowa zmienn w obrbie klasy, ktra bdzie przechowywa warto waciwoci.
W kodzie proceduralnym, jeeli chcielimy przechowa jak warto, to przypisywalimy
j zmiennej. W programowaniu obiektowym do przechowywania wartoci waciwoci rwnie uywamy zmiennej. Zmienna ta jest deklarowana na pocztku deklaracji klasy, w obrbie klamer, ktre zamykaj w sobie kod klasy. Nazwa zmiennej jest nazw waciwoci.
Jeeli zmienna nazywa si  
, to tworzymy waciwo zwan 
.
Otwrzmy plik class.Demo.php i zastpmy jego tre nastpujcym kodem:

 

 
!"  #$  
"%&' ()*" , +%




Deklaracja nowej zmiennej  to wszystko, czego trzeba, by stworzy waciwo klasy
 zwan . Dostp do tej waciwoci wymaga posuenia si tym samym operatorem
() co w poprzednim przykadzie oraz nazw waciwoci. Nowa wersja metody 


ukazuje, jak realizujemy dostp do tej waciwoci.
Stwrzmy nowy plik o nazwie testdemo.php i wpiszmy w nim nastpujcy kod:

     

 
 

 
, -" !
 . " 
 

 . " 
, /0 1
 
, #$  
 . " 
, #$  


Po zapisaniu pliku otwrzmy go w przegldarce WWW. Na ekranie wywietl si cigi


Cze, Stefan! i Cze, Edek!.
Sowo kluczowe 
suy do okrelania, e chcemy mie dostp spoza klasy do nastpujcej po nim zmiennej. Niektre zmienne skadajce si na klas istniej tylko na potrzeby
samej klasy i nie powinny by dostpne z poziomu zewntrznego kodu. W tym przykadzie

30

Cz I n Technologia obiektowa
chcemy mie moliwo ustawiania i pobierania wartoci waciwoci . Jak wida, sposb dziaania metody 

 nieco si zmieni. Zamiast pobiera parametr, pobiera ona


teraz warto  wprost z waciwoci.
Posugujemy si zmienn  , aby obiekt pobiera informacj dotyczc jego samego.
Czasami istnieje kilka obiektw danej klasy i, jako e nie znamy z gry nazwy zmiennej
reprezentujcej obiekt, zmienna   pozwala na odwoanie si do biecego egzemplarza.
W poprzednim przykadzie pierwsze wywoanie 

 wywietla imi , a drugie


 !. To dlatego, e zmienna   umoliwia kademu obiektowi dostp do wasnych
waciwoci i metod bez znajomoci nazwy, ktra reprezentuje ten obiekt na zewntrz klasy. Wczeniej wspomnielimy, e niektre waciwoci maj wpyw na dziaanie pewnych
metod, powoujc si na przykad metody  
 w klasie , ktra sprawdza ilo
pozostaego paliwa. W treci metody  
 dostp do odpowiedniej waciwoci zrealizowano by zapewne wywoaniem  "#
.
Dostp do waciwoci wymaga tylko jednego . Skadnia to  !
  , a nie
 !
  . Czsto myli to stawiajcych pierwsze kroki w PHP. Zmienna reprezentujca waciwo jest deklarowana jako 
$
  , a dostp wymaga
wywoania postaci  !
  .

Poza zmiennymi przechowujcymi wartoci waciwoci klasy mona deklarowa inne zmienne przeznaczone do wewntrznego uytku w klasie. Obydwa rodzaje danych s wsplnie
nazywane wewntrznymi zmiennymi skadowymi klasy. Cz z nich jest dostpna spoza
klasy jako waciwoci, a inne nie s dostpne i su tylko wewntrznym potrzebom klas.
Jeeli, na przykad, klasa  musiaaby pobra z jakiego powodu informacj z bazy danych, mogaby zachowywa uchwyt do poczenia z baz danych w wewntrznej zmiennej
skadowej. Sam uchwyt do poczenia z baz danych trudno nazwa waciwoci samochodu jest jedynie czym, co umoliwia klasie wykonanie pewnych operacji.

Ochrona dostpu do zmiennych skadowych


Jak ukazuje poprzedni przykad, waciwoci  mona przypisa, co tylko zechcemy,
w tym obiekt, tablic liczb cakowitych, uchwyt pliku lub kad inn bezsensown warto.
Nie mamy jednak moliwoci przeprowadzenia jakiejkolwiek kontroli poprawnoci danych
ani zaktualizowania jakichkolwiek innych wartoci w chwili ustawiania wartoci waciwoci .
Aby to obej, naley zawsze implementowa waciwoci jako funkcje wywoywane jako
%&' (
  ) i %&' (
  ). Funkcje te znane s jako metody dost-

powe zostan zaprezentowane w poniszym przykadzie.


Wprowadmy w pliku class.Demo.php nastpujce zmiany:

 

2"  
!"  #$  

Rozdzia 1. n Wprowadzenie do programowania obiektowego

31

"%&' ()*" ,3 "4 +%



!" 3 "4 
 "" , 

!"  "4  
!+  "3 55 "  6
"  /7 " %4    " ()'    %

" ,  




Plik testdemo.Php zmodyfikujmy nastpujco:



     

 
 

 
, "4 -" !
 
, #$  
 
, "4 89//wygeneruje bd


Jak wida, status dostpu do skadnika zmieni si z 


na  , a jego nazwa zostaa
poprzedzona podkreleniem. Podkrelenie jest zalecan konwencj nazewnicz zmiennych
prywatnych i funkcji skadowych, ale tylko konwencj i PHP nie wymaga jej stosowania.
Sowo kluczowe   uniemoliwia modyfikacj tej wartoci spoza poziomu tego obiektu.
Prywatne, wewntrzne zmienne skadowe nie s dostpne spoza klasy. Poniewa nie ma bezporedniego dostpu do zmiennych, trzeba zda si na porednictwo metod dostpowych
&*+ i &*+, dziki czemu klasa bdzie moga sprawdzi prawidowo wartoci,
zanim zostanie ona przypisana. W tym przykadzie, w przypadku przesania nieprawidowej
wartoci dla , generowany jest wyjtek. Dodano te specyfikator 
dla funkcji.
Poziom publiczny to domylny poziom dostpnoci dla kadej funkcji lub zmiennej skadowej, ktre jawnie go nie ustawiaj, ale dobrym nawykiem jest jawne podawanie statusu
dostpnoci dla wszystkich skadowych klasy.
Zmienna skadowa lub metoda moe mie trzy rne poziomy dostpnoci: publiczny, prywatny i chroniony. Skadowe publiczne s dostpne z poziomu dowolnego kodu, a skadowe
prywatne dostpne s tylko z poziomu klasy. Te ostatnie to zwykle elementy o zastosowaniu wewntrznym, takie jak uchwyt poczenia z baz danych czy informacje konfiguracyjne.
Skadowe chronione s dostpne dla samej klasy oraz dla klas jej potomnych (dziedziczenie
zostao zdefiniowane i opisane w dalszej czci rozdziau).
Dziki stworzeniu metod dostpowych dla wszystkich waciwoci o wiele atwiej doda
testowanie prawidowoci danych, now logik obszaru zastosowania lub inne przysze zmiany w obiektach. Nawet jeeli biece wymogi wobec aplikacji nie narzucaj koniecznoci

32

Cz I n Technologia obiektowa
sprawdzania prawidowoci danych dla pewnej waciwoci, naley mimo to zaimplementowa j, posugujc si funkcjami  i , aby moliwe byo dodanie takiego sprawdzania,
albo zmian logiki obszaru zastosowania w przyszoci.
Zawsze uywajmy metod dostpowych dla waciwoci. Uatwi to implementacj przyszych
zmian w wymaganiach logiki obszaru zastosowania aplikacji i kontroli prawidowoci
zmiennych.

Inicjalizacja obiektw
Dla wielu stworzonych klas potrzebna bdzie specjalna procedura inicjalizacyjna wykonywana w chwili tworzenia egzemplarza obiektu tej klasy. Konieczne moe by, na przykad,
pobranie jakich danych z bazy lub zainicjalizowanie jakich waciwoci. Tworzc specjaln
metod, zwan konstruktorem, zaimplementowan w PHP funkcj ,,  *+, moemy
wykona wszelkie czynnoci konieczne dla zainicjalizowania obiektu. PHP automatycznie
wywoa t funkcj w chwili tworzenia egzemplarza obiektu.
Moemy, na przykad, napisa nastpujc, now wersj klasy :

 

2"  
!"   "" 
" ,  

!"  #$  
"%&' ()*" , +%




Funkcja ,,   zostanie automatycznie wywoana w chwili tworzenia nowego egzemplarza klasy .
Uwaga dla uytkownikw PHP4: w PHP4 konstruktory obiektw byy funkcjami o nazwach
takich samych jak nazwa klasy. W PHP5 zdecydowano si na zastosowanie jednorodnej
formy konstruktora. Dla zachowania kompatybilnoci wstecz PHP najpierw szuka funkcji
o nazwie ,,  , po czym, jeeli takiej nie znajdzie, szuka jeszcze funkcji o nazwie takiej samej jak nazwa klasy (w poprzednim przykadzie byaby to 
$  
*+).

Jeeli mamy klas, ktra nie wymaga adnej szczeglnej procedury inicjalizacyjnej, aby mc
normalnie dziaa, nie trzeba tworzy konstruktora. Jak widzielimy w pierwszej wersji klasy
, PHP automatycznie robi wszystko, co potrzeba, by utworzy sam obiekt. Konstruktory
naley pisa tylko wtedy, gdy s potrzebne.

Rozdzia 1. n Wprowadzenie do programowania obiektowego

33

Likwidowanie obiektw
Zmienne obiektw, ktre tworzymy, s usuwane z pamici systemowej w chwili zakoczenia wykonywania kodu biecej strony, kiedy zmienna zniknie z biecego zakresu lub kiedy
jawnie zostanie jej przypisana warto pusta. W PHP5 mona uchwyci moment likwidacji
obiektu, by wykona w tym czasie pewne czynnoci. W tym celu naley stworzy funkcj
zwan ,,   nie pobierajc parametrw. Funkcja ta, o ile istnieje, jest wywoywana,
zanim obiekt zostanie zlikwidowany.
Poniszy przykad zapisuje w chwili likwidacji obiektu informacj w pliku dziennika zdarze
o tym, jak dugo obiekt istnia. Jeeli mamy obiekty, ktre szczeglnie obciaj pami lub
procesor, to taka technika moe przyda si w analizie wydajnoci systemu i przy szukaniu
sposobw redukcji nadmiernego obcienia.
Tak jak w wikszoci podanych w tej ksice przykadw korzystajcych z baz danych
platform jest tu PostgreSQL. Zdaniem autorw zaawansowane funkcje, obsuga transakcji
i sprawny mechanizm procedur skadowanych tej bazy czyni z niej lepsz alternatyw dla
MySQL-a i innych relacyjnych baz danych typu open-source przeznaczonych do tworzenia
duych, profesjonalnych baz danych. Czytelnicy, ktrzy nie dysponuj rodowiskiem PostgeSQL, mog dokona odpowiednich modyfikacji dostosowujcych do uywanej platformy
bazodanowej.
Stwrzmy tabel, zwan !
, posugujc si nastpujc instrukcj SQL:
&:/.;/;.<=/%"#1%
%"#1%-/:>.=?:>@.:AB/A4C;4D==*
%' %2EFF4C;4D==*
%  %" 7"


Wprowadmy do niej jakie dane:


>4-/:;>4;C%"#1%%' %*%  %
G.=D/-B  *B  1  1  3 

Utwrzmy plik o nazwie class.Widget.php i wprowadmy w nim nastpujcy kod:



 H03 "
2" 0
2"  
2" 0 " 2" 
<
2"  0 D0"3! 
!"   "" 03 ">

//Parametr widgetID to klucz gwny rekordu
//w bazie danych zawierajcego dane
//tego obiektu
//Tworzy uchwyt poczenia i zachowuje go w prywatnej zmiennej skadowej
" ,
<3  "0 "   "3 
!+   " ,
<

34

Cz I n Technologia obiektowa
"  /7 " 4  I JK'#) L''K0#

 %-/=/&;M%' M%*M%  M%N:C@"#1H$/:/"#1 03 ">
%
 3 #" ,
<* 
!+    
"  /7 " %<JK0'# #1 #  "1 # %

!+3   
"  /7 " -'1 3 "#1J   ' +

0"3! "# 
" ,0 03 ">

" , 0"O' P
" ,0 " 0"O  P

!" 3 "4 
 "" , 

!" 3 "
" 
 "" ,0 " 

!"  "4  
" ,  
" , 0 D0"3" 

!"  "
" 0 " 
" ,0 " 0 " 
" , 0 D0"3" 

!" 0 ""
!+" , 0 D0"3
 "

 D?
.;/%"#1%-/;
 %M%' M%%3   "3" , %*%
 %M%  M%%3   "3" ,0 " %%
 %H$/:/"#1%" ,0
 3 #" ,
<* 
!+    
"  /7 " H# "KJJK0 0' 1"''#0#

//Koniec operacji na bazie danych. Zamknicie poczenia.
3 " ,
<




Rozdzia 1. n Wprowadzenie do programowania obiektowego

35

Konstruktor tego obiektu nawizuje poczenie z baz danych , posugujc si kontem
domylnego superuytkownika  . Uchwyt do tego poczenia zostaje zachowany
jako prywatna zmienna skadowa do pniejszego uycia. Warto  - przesana jako
parametr do konstruktora suy do skonstruowania instrukcji SQL, ktra pobiera informacje
o artykule przechowywanym w bazie pod podan wartoci klucza gwnego. Dane z bazy
s wwczas przypisywane do prywatnych zmiennych skadowych, z ktrych mona korzysta za pomoc funkcji  i . Zwrmy uwag, e w razie jakiegokolwiek niepowodzenia konstruktor generuje wyjtek, naley wic pamita o zawieraniu wszelkich prb konstruowania obiektw (  w blokach   .
Dwie metody dostpowe, &*+ i    *+, umoliwiaj pobieranie wartoci
prywatnych zmiennych skadowych. Podobnie &*+ i    *+ umoliwiaj
przypisywanie im nowych wartoci. Zauwamy, e w chwili przypisywania nowej wartoci
zmienna  .   jest ustawiana na . Jeeli nie nastpiy adne zmiany, nic nie
musi by aktualizowane.
Dla testu stworzymy plik o nazwie testWidget.php i wpiszemy do niego nastpujc tre:

     H03 "
"#
 H03 " H03 "Q
"%4' "#1JR% H03 ",3 "4 %M%
"%C "#1JR% H03 ",3 "
" %M%
 H03 ", "4 ; 1
 H03 ", "
" ; 1 0I# '  3+
"/7 "  
0 %H# "KJ  R% ,3 "@ 3 



Sprbujmy uruchomi ten plik w przegldarce WWW. Po pierwszym wywoaniu powinien


wygenerowa nastpujc tre:
4' "#1JRB 
C "#1JRB  1  1  3

Kade kolejne wywoanie powinno wywietli:


4' "#1JR; 1
C "#1JR; 1 0I# '  3+

Zobaczmy, jak ogromne moliwoci ma ta technika. Pobieramy obiekt z bazy danych, zmieniamy waciwo tego obiektu i automagicznie zapisujemy zmienione dane w bazie za
pomoc kilku zaledwie wierszy kodu w testWidget.php. Jeeli nic si nie zmienia, powrt do
bazy danych nie jest potrzebny i dziki temu zmniejszamy obcienie serwera bazy danych
i zwikszamy wydajno aplikacji.

36

Cz I n Technologia obiektowa
Korzystajcy z obiektu niekoniecznie musz zna wewntrzny sposb jego dziaania. Jeeli
bardziej dowiadczony programista w zespole napisze klas ( , moe przekaza j nowicjuszowi, ktry, na przykad, nie zna SQL-a, a ten moe uy tego obiektu bez wiedzy, skd
pobierane s dane i w jaki sposb dokonuje si w nich zmian. Mona nawet zmieni rdo
pochodzenia danych z PostgeSQL na MySQL albo nawet na plik XML bez wiedzy modego programisty, ktry nie musi ani o tym wiedzie, ani modyfikowa jakiegokolwiek kodu,
w ktrym wykorzystuje t klas.
Ta doskonaa technika zostanie zaprezentowana szerzej w rozdziale 7., w ktrym natrafimy
na uoglnion wersj powyszej klasy, zwan / " , ktrej moemy bez adnych
modyfikacji uywa w praktycznie kadym projekcie.

Dziedziczenie
Gdyby zdarzyo si nam tworzy aplikacj obsugujc stan magazynowy w komisie samochodowym, prawdopodobnie potrzebne byyby nam klasy typu  ,  ! i 0  1, ktre
odpowiadayby takim wanie typom pojazdw bdcych na stanie komisu. Nasza aplikacja
musiaaby nie tylko pokazywa ilo tego rodzaju pojazdw na stanie, ale rwnie charakterystyk kadego z nich, aby handlowcy mogli informowa klientw.
Sedan to samochd czterodrzwiowy i najprawdopodobniej zapisa trzeba by liczb miejsc
oraz pojemno baganika. Pikap nie posiada baganika, ale ma pak o okrelonej pojemnoci, a cay samochd ma pewn dopuszczaln adowno (maksymalna waga adunku, jaki
moe bezpiecznie przewozi). W przypadku samochodu typu minivan przyda si liczba drzwi
przesuwnych (jedne lub dwoje) oraz liczba miejsc w rodku.
Jednak wszystkie te pojazdy s tak naprawd tylko pewnymi typami samochodw i jako takie
bd miay wiele wsplnych cech w naszej aplikacji, takich jak kolor, producent, model, rok
produkcji, numer identyfikacyjny samochodu itp. Aby wszystkie klasy miay te wsplne waciwoci, mona by po prostu skopiowa kod, ktry je tworzy, do kadego z plikw z definicjami klas. Jak wspomniano wczeniej w tym rozdziale, jedn z zalet podejcia obiektowego jest moliwo wielokrotnego wykorzystania kodu, nie musimy wic kopiowa kodu, bo
moemy ponownie skorzysta z waciwoci i metod tych klas w ramach procesu zwanego
dziedziczeniem. Dziedziczenie to zdolno jednej klasy do przejmowania metod i waciwoci klasy nadrzdnej.
Mechanizm dziedziczenia pozwala na zdefiniowanie klasy bazowej, w tym przypadku 2

, i okrelenie, e inne klasy s typu 2
 i std maj takie same waciwoci
i metody co wszystkie obiekty klasy 2
. Moemy ustali, e   jest klas typu
2
 i dlatego automatycznie dziedziczy wszystko, co zostao zdefiniowane w klasie
2
 bez koniecznoci kopiowania kodu. Potem wystarczy napisa jedynie te waciwoci i metody klasy  , ktre nie s wsplne dla wszystkich obiektw klasy 2
.
Pozostao wic jedynie zdefiniowa rnice podobiestwa midzy klasami zostan odziedziczone po klasie bazowej.
Moliwo wielokrotnego wykorzystania kodu to jedna zaleta dziedziczenia, ale jest te druga, bardzo wana. Powiedzmy, e mamy klas  z metod 2
. Metoda
ta pobiera tylko jeden parametr, obiekt klasy 2
, a w wyniku jej dziaania wydrukowane zostan wszystkie papiery dokumentujce transakcj sprzeday, a samochd zosta-

Rozdzia 1. n Wprowadzenie do programowania obiektowego

37

nie usunity z listy pojazdw na stanie. Poniewa wszystkie obiekty typu  ,  ! czy
0  1 to obiekty typu 2
, mona przesa kady z nich do funkcji oczekujcej
obiektu 2
. Z uwagi na to, e trzy szczeglne typy s potomkami bardziej oglnej
klasy nadrzdnej, wiemy, e bd miay ten sam podstawowy zbir waciwoci i metod.
Dopki potrzebne s tylko metody i waciwoci wsplne dla wszystkich obiektw 2

, moemy zaakceptowa obiekty kadej klasy, ktra jest potomkiem 2
.
Przeanalizujmy przykad kotw. Wszystkie koty maj pewne wsplne zachowania. Jedz,
pi, mrucz i poluj. Maj te wsplne waciwoci wag, dugo wsw i szybko
biegania. Z kolei lwy maj grzywy pewnej wielkoci (a przynajmniej samce) i rycz. Gepardy
maj ctki. Udomowione koty nie maj adnej z tych rzeczy, tym niemniej wszystkie wymienione zwierzta to koty.
W PHP definiujemy klas jako podzbir innej klasy, uywajc sowa kluczowego 3 ,
ktre mwi PHP, e deklarowana wanie klasa powinna odziedziczy wszystkie waciwoci i metody po swej klasie bazowej oraz e chcemy doda nowe cechy funkcjonalne lub
wyspecjalizowa now klas.
Gdyby naszym zadaniem byo napisanie aplikacji udostpniajcej dane o zwierztach w zoo,
prawdopodobnie potrzebowalibymy klas  (kot), 4  (lew) i  (gepard). Zanim
przejdziemy do pisania kodu, warto zaplanowa hierarchi klas za pomoc diagramw UML,
aby mie jaki punkt wyjcia przy pisaniu kodu i tworzeniu dokumentacji klas (diagramom
UML przyjrzymy si dokadniej w rozdziale 2., wic nie obawiajmy si, jeeli nie do koca
rozumiemy to, co tutaj pokazano). Nasz diagram klas powinien ukazywa klas bazow 
oraz podklasy  i 4  bdce jej potomkami (patrz rysunek 1.1).
Rysunek 1.1.

Klasy 4  i  dziedzicz wszystko po klasie , ale klasa 4  dodaje implementacj
waciwoci 4  (dugo grzywy) oraz metod *+ (ryczenie), a klasa 
dodaje waciwo " (ilo ctek).
Implementacja klasy  powinna wyglda nastpujco:

 &"
 3"//w kg
!&  

38

Cz I n Technologia obiektowa
  1 = 3"
 7- 0//w km/h
!"  "
//kod realizujcy jedzenie

!"   
//kod realizujcy spanie

!" "? # ? #
//kod realizujcy polowanie na obiekty typu Prey (ofiara),
//ktrych nie bdziemy definiowa

!" 
"% %%M%




Ta prosta klasa definiuje wszystkie waciwoci i metody wsplne wszystkim kotom. Aby
stworzy klasy 4  (lew) i  (gepard), mona by skopiowa cay kod z klasy 
do tych klas. Stwarzamy jednak wtedy dwa problemy. Po pierwsze, jeeli znajdziemy bd
w klasie , bdziemy musieli pamita o tym, aby poprawi go rwnie w klasach 4 
i . I tak oto do zrobienia mamy wicej, a nie mniej (a w kocu zmniejszenie nakadu
pracy jest pono jedn z podstawowych zalet metody obiektowej).
Po drugie, wyobramy sobie, e istnieje metoda jakiego innego obiektu, ktra wyglda
nastpujco:
!"  "; B""#&" &"
 &",


Co prawda gaskanie () lwa lub geparda moe nie by rozsdnym pomysem, ale jeeli
uda si nam podej na tyle blisko, eby to zrobi, zapewne zaczn mrucze (). Przesanie obiektu klasy 4  i  do metody 56 *+ powinno by moliwe.
Potrzeba wic innego sposobu na stworzenie klas 4  i , a sposobem tym jest wanie
dziedziczenie. Posugujc si sowem kluczowym 3  i okrelajc nazw klasy rozszerzanej, moemy w prosty sposb stworzy dwie nowe klasy, ktre maj te same waciwoci
co klasa , uzupeniajc je o swoje wasne. Na przykad:

     &"
 =  7" 0 &"
  = 3"//w cm
!"  
"%: +%




Rozdzia 1. n Wprowadzenie do programowania obiektowego

39

I to wszystko! Majc klas 4  rozszerzajc klas , moemy zrobi co takiego:



0  = 
 =  = 
 = , 3"E66//kg
 = ,!&  K'
 = ,  = 3"8S//cm
 = , "
 = , 
 = ,  


Moemy wic wywoywa waciwoci i metody klasy bazowej  bez koniecznoci przepisywania jej kodu. Pamitajmy, e sowo kluczowe 3  nakazuje PHP automatyczne
doczenie wszystkich cech funkcjonalnych klasy  do metod i waciwoci specyficznych
dla klasy 4 . Poza tym informuje PHP, e obiekty klasy 4  s rwnie obiektami klasy
 i e moliwe jest wywoywanie funkcji 56 *+ z obiektem klasy 4 , nawet
jeeli w deklaracji funkcji uyto nazwy  jako wskazwki dla parametru:

0  = 
 =  = 
 ? ""  &"
 ? "" , "; B""# = 


W ten sposb wszelkie zmiany dokonane w klasie  zostaj automatycznie uwzgldnione
w klasie 4 . Poprawki, zmiany wewntrznego sposobu dziaania funkcji albo nowe metody
i waciwoci s przesyane dalej do podklas klasy nadrzdnej. W duej, dobrze zaprojektowanej hierarchii obiektw moe to znacznie uatwi poprawianie bdw i dodawanie ulepsze. Drobna zmiana w jednej klasie nadrzdnej, moe mie ogromny wpyw na dziaanie
caej aplikacji.
W kolejnym przykadzie zobaczymy, jak mona rozszerza i specjalizowa klas za pomoc
specjalnego konstruktora.
Utwrzmy nowy plik o nazwie class.Cheetah.php i wprowadmy do niego nastpujcy kod:

     &"
 & " 7" 0 &"
  C!- " 
!"   ""
" , 7- 0Q66




40

Cz I n Technologia obiektowa
Poniszy kod wpiszmy w pliku testcats.php:

     & "
!"  "; B""#&" &"
! &", 7- 0F
 &",
  
"%4 0 L 3J 1)1 "1, 00 L'L01 (K%
 &", 7- 0%1 "T 3 0'L+%


 & " & "
 "; B""# & "
 &" &"
 "; B""# &"


Klasa  dodaje now publiczn zmienn skadow " (ilo ctek) oraz
konstruktor, ktry nie wystpowa w nadrzdnej klasie . Teraz, kiedy stworzymy nowy
obiekt , waciwo 3 (odziedziczona po klasie ) zostanie zainicjalizowana
wartoci 100 kilometrw na godzin, co jest w przyblieniu maksymaln prdkoci osigan przez gepardy na krtkich dystansach. Zauwamy, e niepodanie wartoci domylnej dla
klasy  sprawia, e warto zmiennej 3 dla funkcji 56 *+ wynosi 0 (a dokadnie warto pusta, czyli 

). Jak wiedz ci, ktrzy kiedykolwiek mieli kota domowego,


czas jaki ten powica na spanie, sprawia, e jego maksymalna prdko jest bliska zeru!
Dodajc nowe funkcje, waciwoci, a nawet konstruktory i destruktory, podklasy klasy nadrzdnej mog atwo rozszerza swoje moliwoci funkcjonalne i tym samym minimaln iloci
kodu uzupenia aplikacj o nowe elementy.
Jeeli mona powiedzie, e jedna klasa jest szczeglnym typem innej klasy, to naley
wykorzysta dziedziczenie w celu maksymalnego skorzystania z potencjalnej moliwoci
wielokrotnego wykorzystania kodu i uelastycznienia aplikacji.

Zastpowanie metod
To, e klasa jest potomkiem innej klasy, nie oznacza, i zawsze musi korzysta z implementacji funkcji pochodzcej od przodka. Gdybymy pisali aplikacj, ktra oblicza pola rnych
figur geometrycznych, mogyby pojawi si w niej klasy 7 
 (prostokt) i 5 

(trjkt). Obydwie figury s wieloktami i jako takie bd potomkami klasy 
  (wielokt).
Klasa 
  bdzie miaa waciwo "  (ilo bokw) oraz metod 2
(zwr pole). Obliczenie pola jest moliwe dla kadego wielokta, ale metoda jego obliczania
bdzie dla kadego wielokta inna (istnieje oglne rwnanie pola wielokta, ale czsto okazuje si mniej wydajne ni rwnania dla konktretnych figur w tym przypadku prostych
wieloktw). Wzr na pole prostokta to $8$, gdzie  jest szerokoci prostokta, a  jego
wysokoci. Pole trjkta to 9:;$8$$8$, gdzie  to jego podstawa, a  to wysoko. Rysunek 1.2 przedstawia niektre przykady obliczania pl rnych wieloktw.

Rozdzia 1. n Wprowadzenie do programowania obiektowego

41

Rysunek 1.2.

Dla kadej utworzonej podklasy klasy 


  bdziemy prawdopodobnie chcieli uy
rwnania innego ni w domylnej implementacji metody obliczajcej pole posugujcej si
rwnaniem specyficznym dla oglnych wieloktw. Poprzez redefinicj metody klasy moemy wprowadzi wasn wersj implementacji.
W przypadku klasy 7 
 stworzylibymy dwie nowe waciwoci   (wysoko)
i  (szeroko) i zastpili implementacj 2*+ pochodzc z klasy 
  inn
wersj. W przypadku klasy 5 
 dodalibymy zapewne waciwoci przechowujce dane
trzech ktw, dugo odcinka podstawy i wysoko trjkta i take zastpili metod 2*+.
Posugujc si dziedziczeniem i zastpowaniem metod klas nadrzdnych, moemy tworzy
wyspecjalizowane implementacje tych metod na poziomie klas potomnych.
Funkcja, ktra pobiera 
  jako parametr i wywietla pole tego wielokta, bdzie wwczas automatycznie wywoywa metod 2*+ przynalen podklasie klasy 
 
zgodnej z typem obiektu do niej przesanego (czyli np. 7 
 albo 5 
). Zdolno
jzyka obiektowego do automatycznego okrelania w trakcie wykonywania programu, ktra metoda 2*+ ma zosta wywoana, nazywana jest polimorfizmem. Polimorfizm to
zdolno aplikacji do robienia rnych rzeczy w zalenoci od obiektu odniesienia. W tym
przypadku sprowadza si to do wywoywania rnych wersji metod 2*+.
Metody w podklasach naley zastpowa, kiedy implementacja pochodzca z klasy
nadrzdnej rni si od tej wymaganej w podklasie. Pozwala to na wyspecjalizowanie
operacji danej podklasy.

Czasami chcemy zachowa implementacj pochodzc z klasy nadrzdnej, wykonujc jedynie


pewne dodatkowe czynnoci w metodzie podklasy. W aplikacji, ktra wspomaga zarzdzanie organizacj charytatywn, prawdopodobnie wystpowaaby klasa 1
 (wolontariusz) z metod  .*+, ktra umoliwiaaby wolontariuszowi na przystpienie do jednej
z organizowanych akcji i dopisywaaby go do listy osb, ktre zgosiy ch uczestnictwa.
Zamy, e niektrym uytkownikom przypisane s pewne ograniczenia, takie jak bycie
karanym, zakazujce im uczestnictwa w pewnych przedsiwziciach. W takim przypadku
polimorfizm umoliwia stworzenie klasy 7  . (uytkownik o ograniczonych prawach) wprowadzajcej wasn wersj metody  .*+, ktra w pierwszym kroku konfrontuje
ograniczenia na koncie uytkownika z waciwociami danego przedsiwzicia i uniemoliwia przystpienie do niego, jeeli ograniczenia zakazuj uczestnictwa w pewnego rodzaju
akcjach. Jeeli ograniczenia nie uniemoliwiaj uczestnictwa, naley wywoa odpowiednie
metody klasy nadrzdnej, ktre pozwol dopeni rejestracji.
Zastpujc metod klasy nadrzdnej, nie trzeba pisa jej zupenie od nowa. Mona wci
korzysta z implementacji pochodzcej od przodka, uzupeniajc j o pewne specjalizujce
elementy na poziomie podklasy. W taki sposb moemy wielokrotnie wykorzystywa kod
i dostosowywa go do wymaga obszaru zastosowania.

42

Cz I n Technologia obiektowa
Zdolno jednej klasy do dziedziczenia metod i waciwoci innej klasy jest jedn z najbardziej pocigajcych cech systemw obiektowych, pozwalajc na uzyskanie niesamowicie
wysokiego poziomu efektywnoci i elastycznoci aplikacji.
W naszym przykadzie stworzymy dwie klasy 7 
 (prostokt) i < (kwadrat).
Kwadrat to szczeglny przypadek prostokta. Wszystko, co mona zrobi z prostoktem,
mona rwnie zrobi z kwadratem, ale z uwagi na to, e w prostokcie wystpuj dwie dugoci bokw, a w kwadracie tylko jedna, niektre operacje trzeba wykona inaczej.
Stwrzmy plik class.Rectangle.php i dodajmy do niego nastpujcy kod:

 : "3 
 3"
 0"
!"   "" 0"* 3"
" , 0" 0"
" , 3" 3"

!" 3 ". 
  "" , 3"U" , 0"




Jest to w miar oczywista implementacja klasy modelujcej prostokt. Konstruktor pobiera


szeroko i wysoko jako parametry, a funkcja 2*+ oblicza pole prostokta, mnoc
te wartoci przez siebie.
Spjrzmy teraz na tre klasy opisujcej kwadrat (class.Square.php):

     : "3 
 -  7" 0 : "3 
!"   "" ' 
" , 3" ' 
" , 0" ' 

!" 3 ". 
 " " , 3"*E




W kodzie tym zastpiony zosta zarwno konstruktor, jak i metoda 2*+. Aby kwadrat
mg by kwadratem, wszystkie boki musz by tej samej dugoci. W efekcie konstruktor
potrzebuje tylko jednego parametru. Jeeli do funkcji przesanych zostanie wicej parametrw, to wszystkie oprcz pierwszego zostan zignorowane.

Rozdzia 1. n Wprowadzenie do programowania obiektowego

43

PHP nie generuje bdu, jeeli liczba parametrw przekazanych do funkcji zdefiniowanej
przez uytkownika jest wiksza ni liczba ustalona w treci deklaracji. W wielu przypadkach takie zachowanie jest podane. Wicej na ten temat mona wyczyta z dokumentacji wbudowanej funkcji  , , *+.

Funkcja 2*+ rwnie zostaa zastpiona. Implementacja w klasie 7 


 dawaaby
co prawda prawidowe wyniki dla obiektw <, ale zostaa zastpiona w celu poprawienia
wydajnoci aplikacji (chocia w tym akurat przypadku poprawa jest symboliczna). W PHP
pobranie jednej wartoci waciwoci i podniesienie jej do kwadratu trwa krcej ni pobranie dwch wartoci i ich pomnoenie.
Zastpujc konstruktory, destruktory i metody, moemy modyfikowa rne aspekty funkcjonowania podklas.

Zachowywanie moliwoci funkcjonalnych przodka


Czasami chcemy zachowa pewne moliwoci funkcjonalne odziedziczone po przodku. Funkcji nie potrzeba zawsze zastpowa w caoci mona jedynie co do nich doda. Mona by
skopiowa kod z metody przodka, ale jak ju widzielimy, metoda obiektowa daje nieco lepsze
moliwoci ni kopiowanie kodu.
Aby wywoa moliwoci funkcjonalne zaimplementowane u przodka, naley posuy si
skadni ==%PC\YCHWPMELK). Kiedy chcemy jedynie uzupeni metod przodka o pewne zachowania, wystarczy wywoa ==%PC\YCHWPMELK), po czym doda uzupeniajcy kod. Rozbudowujc funkcj w ten sposb, zawsze na pocztku naley wywoa metod
przodka. W ten sposb sprawimy, e wszelkie zmiany implementacji przodka nie zaburz
dziaania kodu u potomka.
Poniewa klasa przodka moe oczekiwa pewnego stanu od obiektu albo zmienia go,
modyfikowa wartoci waciwoci albo manipulowa wewntrznymi danymi obiektu,
naley podczas rozbudowy metody odziedziczonej zawsze wywoywa metod przodka
przed kodem rozbudowujcym.

W poniszym przykadzie wystpuj dwie klasy:  (klient) i  !


(klient w czasie promocji). W supermarkecie dziaa aplikacja, ktra w czasie trwania pewnych promocji zamienia klasy uywane przez aplikacj zarzdzajc kasami. Kady klient
przechodzcy przez kas ma swj wasny numer identyfikacyjny (ktry pochodzi z bazy
danych) oraz numer klienta, ktry wskazuje, ilu klientw przeszo przed nim przez kas.
Promocja polega na tym, e milionowy klient wygrywa nagrod.
Stwrzmy plik o nazwie class.Customer.php i wpiszmy w nim nastpujcy kod:

 & " 
0
 " 4  
 
!"   "" " >

//pobiera dane klienta z bazy
//

44

Cz I n Technologia obiektowa
//Tutaj akurat wartoci wpisano na stae,
//ale normalnie powinny pochodzi z bazy danych
0"#
0"O " 4  PQ666666
0"O PV@  ''1
//Przypisuje wartoci z bazy danych do obiektu
" ,0 " >

" , 0"O P
" , " 4  0"O " 4  P




Utwrzmy plik o nazwie class.SweepstakesCustomer.php i wpiszmy w nim nastpujcy kod:



     & " 
 -  "1 & "  7" 0 & " 
!"   "" " >

 "RR  "" " >

!" , " 4  Q666666
"%W" " , +V " ( 'K   K1 "1K+%
%H#3J( '#'   I #! "T '  ''1+%





Jak dziaa dziedziczenie?


Klasa  inicjalizuje wartoci zmiennych danymi z bazy na podstawie identyfikatora
klienta. Taki numer najczciej mona uzyska, odczytujc dane z karty programu lojalnociowego wydawanej przez wikszo sieci supermarketw. Majc identyfikator klienta,
moemy pobra dane osobowe klienta z bazy (w tym przykadzie zostay zapisane na stae
w kodzie) oraz liczb reprezentujc ilo klientw, jaka wesza do sklepu przed tym klientem. Wszystkie te informacje zostaj zachowane w publicznych zmiennych skadowych.
Klasa  ! dodaje pewn moliwo funkcjonaln do konstruktora. Na pocztku wywoywany jest kod konstruktora pochodzcy od przodka poprzez ==,,  
i przesyane s do niego oczekiwane parametry.. Nastpnie sprawdzana jest warto waciwoci &. Jeeli dany klient jest klientem milionowym, to generowany jest
komunikat o wygranej.
Aby przetestowa dziaanie tej klasy, stwrzmy plik o nazwie testCustomer.php i wpiszmy
w nim nastpujcy kod:

     -  "1 & " 
//poniewa plik ten zawiera ju w sobie class.Customer.php,

Rozdzia 1. n Wprowadzenie do programowania obiektowego

45

//nie ma potrzeby dodatkowego doczania tego pliku.


!" 3 "& " & "  & "
"% & ", * " #&L     '#  1  +%

//Zmiana tej wartoci powoduje zmian klasy, z ktrej stworzony zostanie obiekt klienta
 " & "#:3" 
! " & "#:3
 & " -  "1 & " QE8XF
  
 & " & " QE8XF

3 "& "  & "


Teraz moemy uruchomi testCustomer.php w przegldarce ze zmienn  

7  ustawion najpierw na 


, a potem na . Kiedy ustawimy t warto na
, ukae si komunikat o wygranej.

Interfejsy
Czasami mamy grupy klas powizane relacjami niekoniecznie polegajcymi na dziedziczeniu. Zdarza si, e zupenie odmienne klasy maj pewne wsplne zachowania. Na przykad
zarwno soik, jak i drzwi mona otworzy i zamkn, mimo e poza tym faktem nie maj
ze sob nic wsplnego. Niezalenie od rodzaju soika i drzwi obydwu tym rzeczom mona
przypisa te same operacje, ale poza tym nic ich nie czy.

Co robi interfejsy?
Taka sama idea jest obecna w programowaniu obiektowym. Interfejs pozwala na okrelenie,
e obiekt jest w stanie wykona pewn funkcj bez koniecznoci tumaczenia, w jaki sposb
si to odbywa. Interfejs to swoista umowa pomidzy niepowizanymi obiektami zawizana
w celu wykonania wsplnej funkcji. Obiekt, ktry implementuje dany interfejs, gwarantuje
uytkownikom, e potrafi wykona wszystkie funkcje wymienione w specyfikacji interfejsu.
Rowery i piki to zupenie rne rzeczy, a mimo to obiekty reprezentujce te rzeczy w oprogramowaniu sklepu sportowego musz prowadzi interakcj z tym systemem.
Deklarujc interfejs, po czym implementujc go w obiektach, moemy umoliwi zupenie
rnym klasom dostp do wsplnych funkcji. Przedstawiony tu przykad opiera si na raczej
prozaicznej analogii do drzwi i soika.
Stwrzmy plik o nazwie interface.Opener.php:

" ! C  
 ""!"   

46

Cz I n Technologia obiektowa
 ""!"  



Analogicznie do konwencji nazywania plikw z klasami wg wzorca class.[Nazwa klasy].php


powinnimy zastosowa co podobnego dla plikw interfejsw i nazywa je wg wzorca inter
face.[Nazwa interfejsu].php.
Deklarujemy interfejs 
, posugujc si skadni podobn do skadni klasy; poza tym,
e sowo
 zastpujemy sowem  . Interfejs nie posiada zmiennych skadowych
i nie precyzuje implementacji swoich funkcji skadowych.
Poniewa nie podaje si tu adnej implementacji, funkcje s deklarowane jako abstrakcyjne
( ). Informuje to PHP, e kada klasa implementujca ten interfejs jest odpowiedzialna za dostarczenie implementacji wystpujcych w nim funkcji. Jeeli nie zostan dostarczone implementacje wszystkich abstrakcyjnych metod interfejsu, PHP wygeneruje bd po
uruchomieniu programu. Nie mona wybirczo implementowa niektrych metod abstrakcyjnych konieczne jest zaimplementowanie wszystkich.

Jak dziaaj interfejsy?


Interfejs 
 to umowa z innymi czciami aplikacji mwica, e kada klasa implementujca ten interfejs dostarczy dwch metod, zwanych *+ i
*+, ktre nie pobieraj
parametrw. Majc uzgodniony zestaw metod, moemy sprawi, by zupenie rne obiekty
byy przekazywane do tych samych funkcji bez potrzeby tworzenia midzy nimi relacji opartych na dziedziczeniu.
Utwrzmy kilka plikw. Zacznijmy od class.Door.php:

    " ! C  
 
  " C  
2"  1 0! 
!"   
!" , 1 0
"%4  I " '#)0' -K' 1L" 1'%
  
 "% 1'####%


!"  
"%;++%

!"  1

" , 1 0" 


Rozdzia 1. n Wprowadzenie do programowania obiektowego

47

!"  1

" , 1 0! 



nastpnie class.Jar.php:

    " ! C  
 V  " C  
2"  " " 
!"   "" " " 
" , " "  " " 

!"   
"% J 1' "J " "#%

!"  
"% J 1' "J' 1L"#%




Aby skorzysta z tych plikw, stworzymy w tym samym katalogu jeszcze jeden plik o nazwie
testOpenable.php:

     

     V
!"   - "3C   
 ,  

 
 

 V V%3 "1%
  - "3 

  - "3 V


Poniewa zarwno klasa , jak i > implementuj interfejs "


, mona przesa
obiekty kadej z tych klas do funkcji   *+. Poniewa funkcja ta akceptuje tylko
co, co implementuje interfejs "
, wiemy, e moemy w jej ramach wywoa funkcje
*+ i
*+. Nie naley jednak prbowa dostpu do waciwoci  (zawarto)
soika ani uywa funkcji
 !*+ lub 
 !*+ otwierajcych zamek drzwi w klasie 
z poziomu funkcji   *+, poniewa ta waciwo i te metody nie s czci interfejsu. Zgodnie z umow interfejsu moemy jedynie otwiera funkcj *+ i zamyka funkcj
*+.

48

Cz I n Technologia obiektowa
Stosujc interfejsy w aplikacji, moemy urzeczywistni komunikacj pomidzy dwoma zupenie niepowizanymi z sob obiektami z gwarancj, e ich interakcja bdzie odbywa si
w ramach warunkw okrelonych w interfejsie. Interfejs jest umow udostpniajc pewne
metody.

Hermetyzacja
Jak wspomniano wczeniej w tym rozdziale, obiekty pozwalaj na ukrycie szczegw ich
implementacji przed ich uytkownikami. Nie musimy wiedzie, czy wspomniana wczeniej
klasa 1
 (wolontariusz), zachowuje informacje w bazie danych, w zwykym pliku
tekstowym czy w dokumencie XML lub innym mechanizmie przechowywania danych, aby
mc wywoa metod  .*+. Podobnie nie musimy wiedzie, czy dane wolontariusza
przechowywane w obiekcie s reprezentowane jako pojedyncze zmienne, tablica czy moe
inny obiekt. Zdolno do ukrywania implementacji to hermetyzacja. Oglnie rzecz biorc,
hermetyzacja ma dwa aspekty ochrona wewntrznych danych klasy przed zewntrznym
kodem oraz ukrywanie szczegw implementacji.
Sowo encapsulate oznaczajce hermetyzowanie w jzyku angielskim oznacza dosownie
umieszczenie w kapsule lub w innym wyodrbnionym pojemniku. Dobrze zaprojektowana
klasa, buduje szczeln barier wok swego wntrza i udostpnia dla zewntrznego kodu
interfejs, ktry jest cakowicie odseparowany od tego wntrza. Ma to dwie zalety: moemy
w kadej chwili zmienia szczegy implementacji, nie wywierajc wypywu na dziaanie
kodu korzystajcego z klasy, a take mamy pewno, e nic spoza klasy nie moe niepostrzeenie zmodyfikowa wartoci okrelajcych stan i waciwoci obiektu zbudowanego z klasy
i tym samym ufa, e stan obiektu i wartoci waciwoci bd prawidowe.
Zmienne i funkcje skadowe klasy maj okrelon widzialno. Widzialno odnosi si do
tego, co jest widoczne dla kodu spoza klasy. Prywatne funkcje i zmienne skadowe nie s
dostpne dla kodu zewntrznego i su potrzebom wewntrznej implementacji klasy. Skadowe chronione s widoczne tylko z poziomu podklas danej klasy. Skadowe publiczne
mog by wykorzystywane z poziomu kadego kodu, z wntrza i spoza klasy.
Oglnie rzecz biorc, wszystkie wewntrzne skadowe klasy powinny by deklarowane jako
prywatne. Kady dostp do tych zmiennych dla kodu spoza klasy powinien by realizowany poprzez metody dostpowe. Nikt z nas nie zgodziby si zapewne na degustacj nowej
potrawy z zawizanymi oczami i przez karmienie na si. Wolelibymy przyjrze si daniu
i zadecydowa, czy naprawd chcemy je zje. Podobnie, kiedy obiekt chce dopuci moliwo zmiany swoich waciwoci lub innego rodzaju wpywu na wewntrzne dane z poziomu
zewntrznego kodu, to dziki hermetyzacji dostpu do tych danych za porednictwem funkcji
publicznych (i zachowaniu prywatnoci wewntrznych danych) zyskujemy moliwo weryfikacji zmian i ich akceptacji bd odrzucenia.
Jeeli, na przykad, tworzymy aplikacj dla banku, ktra obsuguje szczegy zwizane z rachunkami klientw, to by moe bdziemy mieli obiekt 2  (rachunek) z waciwoci

?
  (saldo kocowe) oraz metod ! *+ realizujc wpat i metod !
(   
*+ realizujc wypat. Waciwo reprezentujca bilans powinna by tylko
do odczytu. Jedynym sposobem na zmian salda jest dokonanie wpaty lub wypaty. Gdyby
zaimplementowa waciwo 
?
  jako skadow publiczn, to moliwe byoby
napisanie kodu, ktry zwikszaby warto tej zmiennej bez koniecznoci dokonywania wpaty.

Rozdzia 1. n Wprowadzenie do programowania obiektowego

49

Takie podejcie nie byoby zbyt dobre dla banku. Lepiej wic zaimplementowa t waciwo jako prywatn zmienn skadow i udostpni publiczn metod zwan 5
?

 *+, ktra zwraca warto prywatnej zmiennej skadowej. Poniewa zmienna przechowujca warto salda rachunku jest prywatna, nie mona bezporedni ni manipulowa.
Z uwagi na to, e jedynymi publicznymi metodami, ktre maj wpyw na saldo rachunku,
s !(   
*+ i ! *+, zwikszenie salda rachunku bdzie wymagao dokonania wpaty.
Umoliwiajc ukrycie szczegw implementacji i ochron dostpu do wewntrznych zmiennych skadowych, programowanie obiektowe pozwala na tworzenie stabilnych i elastycznych
aplikacji.
Hermetyzacja danych wewntrznych i implementacji metod umoliwia systemowi oprogramowania obiektowego ochron i kontrol dostpu do danych oraz ukrywanie szczegw
implementacji.

Zmiany w PHP5
dotyczce programowania obiektowego
Obiekty byy obsugiwane w PHP ju od wersji PHP3. Nie wizao si to jednak z intencj
obsugi idei klas i obiektw dodano jedynie pewn ograniczon obsug, bardziej w formie
dodatku dostarczajcego skadniow osod (posugujc si sowami Zeeva Suraskiego)
tablicom asocjacyjnym. Obsuga obiektw w PHP pierwotnie stanowia wygodny sposb
grupowania danych i funkcji, ale uwzgldniaa tylko niewielki podzbir cech funkcjonalnych,
jakie posiaday jzyki w peni obiektowe. W miar wzrostu popularnoci PHP stosowanie
podejcia obiektowego stawao si coraz powszechniejsze w duych aplikacjach. Saba implementacja obiektowoci zacza krpowa ruchy.
Co najwaniejsze, nie byo adnej obsugi prawdziwej hermetyzacji. Nie mona byo opisywa zmiennych czy metod jako prywatnych lub chronionych. Wszystko byo publiczne, co,
jak widzielimy, bywa rdem problemw.
Nie byo te obsugi abstrakcyjnych interfejsw i metod. Metody i zmienne skadowe nie
mogy by deklarowane jako statyczne. Nie istniay destruktory. Wszystkie te pojcia byy
znane kademu, kto mia do czynienia z innym jzykiem obiektowym i brak tych moliwoci w modelu obiektowym PHP utrudnia przejcie do PHP z takich jzykw jak Java (ktra
obsuguje wszystkie te aspekty). Ci, ktrzy mieli wczeniej dowiadczenia z PHP4, mog
z poniszej tabeli wyczyta nowe cechy modelu obiektowego wprowadzone w PHP5.
Nowa cecha

Korzyci

Prywatne i chronione
Od tej chwili rwnie PHP umoliwia pen hermetyzacje i ochron danych.
zmienne i funkcje skadowe.
Ulepszona obsuga
usuwania porednioci.

Mona stosowa takie instrukcje jak  ,3 "- "3,0 - "3.

50

Cz I n Technologia obiektowa

Nowa cecha

Korzyci

Zmienne i metody
skadowe mog by
statyczne.

Metody, ktre mog by wywoywane statycznie, s teraz jasno identyfikowalne.


Stae na poziomie klasy pomagaj ogranicza zanieczyszczenie globalnej
przestrzeni nazw.

Jednorodna posta
konstruktorw.

Konstruktory klasy oznaczamy teraz jako   "". Pomaga to


w hermetyzacji zastpionych konstruktorw podklas i uatwia zmian
dziedziczenia, kiedy struktura dziedziczenia skada si z wielu klas.

Obsuga destruktorw.

Dziki metodzie 0 "" klasy w PHP mog mie ju destruktory.


Umoliwiaj one wykonywanie okrelonych czynnoci w chwili
likwidacji obiektu.

Obsuga abstrakcyjnych
klas i interfejsw.

Mona definiowa potrzebne metody w klasie przodka, wstrzymujc si


z implementacj i wprowadzajc j dopiero w podklasie. Nie mona tworzy
egzemplarzy klas abstrakcyjnych, tylko ich skonkretyzowanych podklas.

Sugestie typw
parametrw.

Mona wskaza klas dla tych parametrw funkcji, ktre oczekuj obiektu.
Piszc !" ! < <, mamy pewno, e typ parametru
jest zgodny z naszymi oczekiwaniami

Podsumowanie
W rozdziale omwilimy koncepcj programowania obiektowego. Opisalimy klas jako
wzorzec dla tworzenia obiektw. Obiekty to istniejce w czasie egzekucji zbiory funkcji i danych stworzone na podstawie definicji klas. Obiekty maj cechy charakterystyczne zwane
waciwociami i zachowania zwane metodami. Waciwoci mona postrzega jako zmienne,
a metody jako funkcje.
Niektre klasy maj wsplnego przodka. Kwadraty s prostoktami. Kiedy deklarujemy klas
jako podtyp klasy nadrzdnej, dziedziczy ona metody i waciwoci klasy nadrzdnej. Moliwe jest zastpowanie metod odziedziczonych. Mona napisa zupenie now implementacj lub zdecydowa si na uycie implementacji pochodzcej od przodka i dodanie do niej
kodu specjalizujcego charakterystycznego dla danej podklasy. Mona te w ogle nie zastpowa metody.
Hermetyzacja to wane pojcie w programowaniu obiektowym. Oznacza ono zdolno klasy
do ochrony dostpu do swoich wewntrznych zmiennych skadowych i odgrodzenia uytkownikw klasy od szczegw implementacyjnych. Metody i waciwoci maj trzy poziomy
widzialnoci prywatny, chroniony i publiczny. Skadowe prywatne mog by uywane
wycznie przez wewntrzne operacje klasy. Skadowe chronione s widoczne z poziomu
podklas. Skadowe publiczne mog by uywane przez kod spoza klasy.
Obsuga programowania obiektowego w PHP ulega powanej modernizacji w PHP5 i module Zend Engine 2. Nowe cechy i znaczne zwikszenie wydajnoci czyni PHP jzykiem
obiektowym w penym tego sowa znaczeniu.

You might also like