Programowanie obiektowe w PHP 5 cz. 3

Autor: Tomasz Jędrzejewski
Data publikacji: 02.01.2005, 16:56 | Ostatnia modyfikacja: 19.11.2006, 17:36

Trzecia część artykułu o programowaniu obiektowym w PHP 5 poświęcona jest interfejsom, iteratorom oraz wykorzystaniu wszystkiego w praktyce.

Spis treści

Trzecia część artykułu o programowaniu obiektowym w PHP 5 poświęcona jest prawie w całości interfejsom oraz tworzonym przy ich pomocy iteratorom. Ponadto omówimy sobie zagadnienie serializacji obiektów, porównamy OOP w PHP 4 z tym z "piątki" oraz spróbujemy przedstawić praktyczne wykorzystanie zdobytej wiedzy. A więc zaczynamy.

Interfejs - z czym to się je?

Interfejsem nazywamy zbiór nagłówków metod (czyli bez konkretnej zawartości), który mogą wykorzystać klasy do realizacji własnych celów. Załóżmy, że mamy sobie jakiś tam algorytm, który działa z obiektami dowolnych klas, pod warunkiem, że posiadają one metody X, Y oraz Z. Moglibyśmy stworzyć tutaj abstrakcyjną klasę bazową, ale wtedy uniemożliwilibyśmy programistom dziedziczenie z innych klas. Tu na scenę wkraczają interfejsy. Tworzymy sobie taki jeden z nagłówkami żądanych metod. Jeżeli programista zażyczy sobie możliwości użycia jego klasy w naszym algorytmie, po prostu doda do jej deklaracji ciąg implements NaszInterfejs i po sprawie. Algorytm natomiast może przy użyciu znanego nam już instanceof sprawdzić, czy nasz interfejs rzeczywiście jest implementowany.

<?php
 
   interface nasz_interfejs{
      public function zwroc_id_obiektu();
   }
 
   class nasza_klasa implements nasz_interfejs{
 
      public function __construct(){
         echo 'Tworzymy `nasza_klasa`<br/>';
      } // end __construct();
 
      public function zwroc_id_obiektu(){
         return (int) substr((string)$this, 11, strlen((string)$this) - 11);
      } // end zwroc_id_obiektu();
 
   }
 
   class nasza_inna_klasa implements nasz_interfejs{
 
      public function __construct(){
         echo 'Tworzymy `nasza_inna_klasa`<br/>';
      } // end __construct();
 
      public function zwroc_id_obiektu(){
         return (int) substr((string)$this, 11, strlen((string)$this) - 11);
      } // end zwroc_id_obiektu();
 
   }
 
   class jakas_klasa{
 
      public function __construct(){
         echo 'Tworzymy `jakas_klasa`<br/>';
      } // end __construct();
 
   }
 
   function algorytmus(){
      $args = func_get_args();
      $suma = 0;
      foreach($args as $arg){
         if($arg instanceof nasz_interfejs){
            $suma += $arg -> zwroc_id_obiektu();
         }else{
            echo 'Ostrzeżenie: Wprowadzono klase nieobslugujaca interfejsu `nasz_interfejs`!<br/>';
         }
      }
      return $suma;
   } // end algorytmus();
 
   $obj1 = new nasza_klasa;
   $obj2 = new nasza_klasa;
   $obj3 = new nasza_inna_klasa;
   $obj4 = new jakas_klasa;
 
   echo 'Suma ID obiektow wynosi '.algorytmus($obj1, $obj2, $obj3, $obj4).'<br/>';
?>

Przykład ten można zaliczyć do tzw. mocno alternatywnych, gdyż liczy... sumę ID obiektów implementujących interfejs nasz_interfejs :). Mamy sobie trzy klasy, z czego dwie implementują to nasze cudeńko. Tworzymy cztery obiekty, wprowadzamy je do algorytmu umieszczonego w funkcji algorytmus(). Ten, wykorzystując instanceof sprawdza, czy można wywołać naszą metodę zwroc_id_obiektu(). To cała filozofia.

Interfejsy mają nad klasami abstrakcyjnymi jeszcze jedną przewagę - dana klasa może ich implementować kilka naraz, podczas gdy normalnie byłaby ograniczona do jednej abstrakcyjnej. Nazwy poszczególnych interfejsów oddzielamy przecinkami:

class klasa implements interfejs1, interfejs2, interfejs 3

Do góry

Obiekty a pętla foreach

Nowością w PHP 5 jest możliwość potraktowania obiektów pętlą foreach. Zwracane są wtedy wartości wszystkich ich publicznych pól, włącznie z nazwą. Jest to przydatne zwłaszcza wtedy, gdy pola tworzymy dynamicznie.

<?php
 
   class magazyn{
      private $pole_pryw = 24;
 
      public function dodaj_pole($nazwa, $wartosc){
         // dynamiczne tworzenie pola - jak zwykla zmienna
         $this -> {$nazwa} = $wartosc;
      } // end dodaj_pole();
 
   }
 
   $magazyn = new magazyn;
   $magazyn -> dodaj_pole('pole1', time());
   $magazyn -> dodaj_pole('pole2', rand(0,100));
   $magazyn -> dodaj_pole('pole3', 13);
 
   foreach($magazyn as $nazwa => $wartosc){
      echo $nazwa.' => '.$wartosc.'<br/>';
   }
?>

Zauważ, że zawartość pola $pole_pryw zdefiniowanego jako prywatne, nie została zwrócona.

To jednak nie wszystko... PHP 5 daje nam możliwość pełnej manipulacji tym, co zwróci obiekt potraktowany pętlą foreach! Jak? Przy pomocy dwóch predefiniowanych interfejsów - Iterator oraz IteratorAggregate...

Do góry

Piszemy iterator

Obsługą iteracji w klasie X zajmują się interfejsy Iterator, IteratorAggregate oraz specjalna klasa pomocnicza. Cała sztuczka polega na tym, że implementujemy w tejże klasie pierwszy z interfejsów. Dostarcza on metody w stylu rewind(), next() itd. pozwalających przesuwać się po rekordach i pobierać ich zawartości. Następnie we właściwej klasie implementujemy drugi interfejs. Mamy dzięki temu dostęp do jednej metody - getIterator(), której zadaniem jest utworzenie obiektu klasy pomocniczej obsługującej pętlę. Może brzmi to skomplikowanie, ale w ten sposób kilka klas może łatwo korzystać z tego samego iteratora. Możemy np. stworzyć klasę iteratora do obsługi pobierania przetworzonych danych. Następnie kilka klas obrabiających te dane użyje jej i tak ominiemy konieczność powtarzania tego samego kodu do obsługi pętli dla np. 20 klas.

Praktycznie pokażę to na podstawie obiektowej nakładki na funkcję file(). Wykorzystywany przez nią iterator użyję następnie w drugiej klasie.

<?php
 
   class nasz_iterator implements Iterator{
      private $i;
      private $obj;
 
      public function __construct($obiekt){
         $this -> obj = $obiekt;
         $this -> i = 0;
      } // end __construct();
 
      public function rewind(){
         $this -> i = 0;
      } // end rewind();
 
      public function valid(){
         return $this -> obj -> key_exists($this -> i);
      } // end valid();
 
      public function key(){
         return $this -> i;
      } // end key();
 
      public function current(){
         return $this -> obj -> get_item($this -> i);
      } // end current();
 
      public function next(){
         $this -> i++;
      } // end next();
   }
 
   class x_file implements IteratorAggregate{
      protected $plik;
 
      public function __construct($plik){
         if(file_exists($plik)){
            $this -> plik = file($plik);
         }else{
            $this -> plik = array(0 => '');
         }
      } // end __construct();
 
      public function getIterator(){
         return new nasz_iterator($this);
      } // end getIterator();
 
      public function get_item($i){
         return trim($this -> plik[$i]);
      } // end get_item();
 
      public function key_exists($i){
         return isset($this -> plik[$i]);
      } // end key_exists();
   }
 
   class x_list extends x_file{
      public function __construct(){
         $this -> plik = array();
      } // end __construct();
      
      public function add($item){
         $this -> plik[] = $item;
         return count($this -> plik) - 1;
      } // end add();
   }
 
   $plix = new x_file('test.txt');
   foreach($plix as $lnum => $linia){
      echo $lnum.' - '.$linia.'<br/>';
   }
 
   $lista = new x_list;
   $lista -> add('pozycja 1');
   $lista -> add('pozycja 2');
   $lista -> add('pozycja 3');
 
   echo '<br/>';
 
   foreach($lista as $id => $pozycja){
      echo $id.' - '.$pozycja.'<br/>';
   }
?>

Przyjrzyjmy się najpierw klasie nasz_iterator. Do czego służą poszczególne metody? Oto ich opis:

rewind()
Ustawia iterator na pierwszym elemencie do pobrania

valid()
Sprawdza, czy ID aktualnej pozycji jest poprawny.

key()
Zwraca ID aktualnej pozycji

current()
Zwraca wartość aktualnej pozycji

next()
Przesuwa wskaźnik na następną pozycję

Z kolei w klasach korzystających z iteratora mamy jedną metodę: getIterator(). Musi ona zwrócić obiekt iteratora, którego chcemy użyć. PHP nie może go sobie utworzyć samodzielnie, ponieważ:

nie wie, czego chcielibyśmy użyć
zainicjowanie może wymagać dodatkowych parametrów, jak w naszym przypadku - do iteratora musi powędrować referencja obiektu, który chce go użyć ($this). Dzięki temu będzie wiedzieć, skąd ma czerpać dane.

Przyjrzyj się dobrze iteratorowi i klasie x_file(). Obie współpracują ze sobą poprzez udostępnienie odpowiednich metod do sprawdzania poprawności i przetwarzania poszczególnych elementów tablicy. Iterator nie tylko sucho prosi: podaj mi referencję do tablicy, a ja już się zajmę wszystkim. On chciałby dostać referencję do samego obiektu. Prosi: daj mi siebie :) i przygotuj dla mnie metody do sprawdzania poprawności ID i przetwarzania danych do pobrania - być może przy ich pobieraniu będziesz chciał coś w nich zmodyfikować?

Widzimy więc, że takie podejście do sprawy daje nam dużą swobodę - możemy dowolnie eksperymentować ze współpracą pomiędzy iteratorem, a klasami tak, by uzyskać jak największą elastyczność. Widać to z resztą na przykładzie - nasz_iterator chciałby mieć dostarczane metody, które obrobią dane za niego. W ten sposób będzie go można również wykorzystać z inną klasą, pragnącą jeszcze inaczej przetwarzać informacje.

Dodatkowo przykład ujawnił ciekawą cechę interfejsów - jeśli klasa jest pochodną od klasy implementującej jeden z nich, sama też go implementuje. U nas jest to IteratorAggregate - pomimo, że w x_list wcale nie zadeklarowaliśmy żadnego interfejsu do implementacji, nie utworzyliśmy żadnej z jego metody, on również poprawnie działa z pętlą foreach, gdyż wszystko sobie już odziedziczył.

Do góry

Rzutowanie typów

Jak wiadomo, zmienne w PHP nie mają przypisanego na stałe żadnego typu. Programowanie obiektowe w wersji 5 wprowadza jednak pewną furtkę - jako, że jest całkowicie niezależne od strukturalnego modelu, możemy w pewnych sytuacjach określać typ parametrów wprowadzanych do metod! To dobra wiadomość. Zła jest taka, że można to zastosować wyłącznie do obiektów, a mianowicie do sprawdzenia, czy wprowadzony obiekt jest instancją jakiejś konkretnej klasy/interfejsu. Zapis wygląda w ten sposób:

function funkcja_lub_metoda(jakas_klasa $parametr){
    // tresc
}

W ten sposób określiliśmy, że wprowadzony parametr musi być obiektem klasy jakas_klasa. W praktyce zapis ten jest skrótem od czegoś takiego:

function funkcja_lub_metoda($parametr){
   if(!($parametr instanceof jakas_klasa)){
      die('Nieprawidłowy typ zmiennej $parametr');
   }
   // dalsza tresc
}

Tak więc zostało to wprowadzone dla ułatwienia życia programistom i skrócenia kodu.

Do góry

Zmienne obiektowe cd.

W pierwszej części serii wspomniałem, że powrócimy jeszcze do tego, że zmienna obiektowa jest jedynie referencją do obiektu. Co tu jednak jest jeszcze do pisania? Ano, dużo. Przede wszystkim - zwracanie obiektów poprzez instrukcje return nie stanowi żadnego problemu. Możemy zatem pokusić się o stworzenie czegoś, co zwie się fabryką klas. Jest to zwyczajna funkcja/metoda, pozwalająca nam tworzyć obiekty od różnych klas. Dodatkowo wykonywać może ona za nas rozmaite dodatkowe czynności związane z inicjacją. Rozwiązanie to możemy wykorzystać np. podczas pisania systemu modułów:

   function fabryka_modulow($modul){
      static $call;
      if(file_exists('./moduly/'.$modul.'.php')){
         require_once('./moduly/'.$modul.'.php');
 
         $m = new $modul;
 
         if($m instanceof modul_interface && $call != 1){
            $m -> set_action($_GET['cmd']);
            $call = 1;
         }
         return $m;
      }
      return modul_domyslny;
   } // end fabryka_modulow();

Używać tego można w ten sposób:

   $news = fabryka_modulow('news');
   $artykuly = fabryka_modulow('artykuly');

Ze zwracaniem obiektu przez funkcje/metody związana jest jeszcze jedna ciekawa sztuczka. Oto, co można zrobić przy odrobinie chęci:

$zwierzyniec -> zwroc_zwierze(15) -> daj_glos();

Taki łańcuszek można nadal rozszerzać. Problem pojawi się, gdy naszej metodzie nie uda się zwrócić obiektu z powodu jakiegoś błędu.

Do góry

PHP 5 vs. PHP 4

Na koniec pozostawiłem sobie omówienie różnic między programowaniem obiektowym w PHP 4 i 5. Nie będę wymieniać, czego nie było, bowiem o wiele krótsza lista będzie, gdy powiem, co było. A więc:

Były klasy i można je było rozszerzać poprzez dziedziczenie.
Pola w klasach deklarowało się słowem kluczowym var, jako że nie było podziału na publiczne/prywatne/chronione elementy.
Zmienna obiektowa była jednocześnie obiektem. To uniemożliwia robienie rzeczy, o jakich była mowa w poprzednim rozdziale.
Metody zaczynały się bezpośrednio od słowa function.
Konstruktor nazywał się tak samo, jak klasa, do której przynależał.

I to w zasadzie wszystko! Poprzednie wersje PHP traktowały programowanie obiektowe po macoszemu, stąd też tak mizerna liczba możliwości. Oczywiście dla jako takiej kompatybilności zachowano część zmienionych elementów. Tak więc nadal można używać słowa var jako substytutu public (ale tylko przy polach), metody zaczynające się od razu od function są domyślnie publiczne, a w przypadku nieznalezienia konstruktora __construct(), szukany jest ten o nazwie takiej samej, jak klasa.

Główne niekompatybilności wynikają ze zmiany zachowania się zmiennych obiektowych.

Do góry

Programowanie obiektowe w praktyce

Na końcu pokrótce powiem, do czego może się przydać programowanie obiektowe w codziennej praktyce. Jako programista, będziesz zapewne pisać dalej oskryptowanie dla stron WWW. Dotychczas cały kod był pisany po prostu ciurkiem i był w nim (krótko mówiąc) burdel. OOP da Ci możliwość napisania silnika, którego klasy i obiekty będą zarządzały wszystkimi podstawowymi mechanizmami serwisu. Tobie pozostanie już tylko napisać odpowiednie moduły, w dodatku w o wiele krótszym czasie - silnik część zadań wykona za Ciebie.

Ważne jest, aby pojedyncza klasa opisywała jedną logicznie powiązaną całość. Zatem powstanie klasa "session" odpowiedzialna za sesję, "io" do obsługi systemu wejścia/wyjścia, klasy jakichś maperów do kontroli danych z formularzy. Tu wkracza na scenę projektowanie - dobrze jest rozrysować sobie zależność między poszczególnymi obiektami, sposób dostępu do nich oraz udostępniane API. W ten sposób nie stwierdzisz w połowie roboty, że wszystko musisz zaczynać od początku. Dobre rozdzielenie zadań i planowanie to połowa sukcesu.

Jako że w OOP liczy się logika i porządek, będziesz tracić znacznie mniej czasu na zaczęcie poszczególnych projektów. Zamiast pracowicie wycinać co drugą linijkę (albo i pisać od zera, by się nie męczyć), przeniesiesz do nowego zadania część klas z wcześniejszych. Po co wyważać otwarte drzwi? Zyskujesz kompletny i (mam nadzieję, że) dobrze zaplanowany interfejs. Wszystko trzeba będzie już tylko połączyć.

Powyższe zasady sprawdzają się bardzo dobrze. Sam mam zaprojektowany niewielki (zaledwie 50 kb) silnik stworzony w oparciu o OOP z PHP 5, który realizuje wszystkie zadania związane z wewnętrzną mechaniką serwisu WWW. Nie jest on jeszcze kompletny, lecz w bieżących projektach używam niektórych jego klas, by zaoszczędzić sobie czasu i pracy. Gdybyś chciał zobaczyć, jak ta poznana wiedza wygląda i sprawdza się, przeczytaj inne artykuły na Webcity.pl. Polecam również poszukanie informacji o singletonach oraz modelu MVC. Obie te rzeczy związane są z programowaniem obiektowym i czasami one lub niektóre ich założenia mogą być bardzo przydatne przy projektowaniu własnych rozwiązań.

Do góry

Zakończenie

Na tym kończę trzyczęściową serię o programowaniu obiektowym w PHP 5. Mam nadzieję, że wyraźnie wytłumaczyłem wszystkie jego elementy, jak i sam mechanizm działania. Jakby co, moje doświadczenie jest do dyspozycji na naszym forum Webcity.pl. Tam też ciekawscy mogą zadać dodatkowe pytania.

Programowanie obiektowe jest złożoną dziedziną. Opisem jej właściwego wykorzystania oraz projektowania aplikacji z jej użyciem bez problemu można zapełnić kilka opasłych książek i, rzecz oczywista, nie da się tego skompresować w tak niewielkim (stosunkowo) tekście. Miał on pokazać jedynie narzędzia oraz absolutne podstawy - reszta już należy do Ciebie. Samodzielne ćwiczenia i praktyka to podstawy sukcesu.

Autor: Tomasz "Zyx" Jędrzejewski, www.zyxist.com

Do góry