Dekorator: wzorzec projektowy na każdą bolączkę

Transkrypt

1 Techniki Dekorator: wzorzec projektowy na każdą bolączkę Paweł Kozłowski Stopień trudności: Nazwa wzorca projektowego dekorator jest nieco myląca, ponieważ sugeruje, że będziemy coś wzbogacać, dekorować czy upiększać. Nic bardziej błędnego! Omawiany wzorzec znajduje szerokie zastosowanie, niezależnie od tego, czy projektujemy warstwę dostępu do bazy danych, logikę biznesową lub kontroler MVC. W SIECI budowany przez nas framework Ports Pico articles/injection.html ciekawe artykuły ciekawe artykuły Jednym z najczęściej omawianych i używanych wzorców projektowych jest dekorator. Z punktu widzenia programisty ma same zalety: jest bardzo użyteczny, nieskomplikowany w implementacji i łatwy do przyswojenia. Obok singletona jest to prawdopodobnie jeden z pierwszych wzorców, z którymi stykamy się, gdy zaczynamy studiować przykłady i literaturę poświęconą zasadom projektowania. O ile jednak singleton jest obwiniany (często słusznie!) o promowanie fatalnych rozwiązań, to dokładne poznanie dekoratora przyczyniło się do powstania wielu ciekawych rozwiązań architektonicznych. Nazwa wzorca projektowego "dekorator" jest nieco myląca, ponieważ sugeruje, że będziemy coś wzbogacać, dekorować czy upiększać. Stąd może powstać błędne przeświadczenie, że mamy do czynienia z tworem przydatnym jedynie w warstwie prezentacji. Nic bardziej błędnego! Omawiany wzorzec znaj- duje szerokie zastosowanie, niezależnie od tego, czy projektujemy warstwę dostępu do bazy danych, logikę biznesową lub kontroler MVC. Jego istotą jest możliwość wzbogacenia funkcjonalności obiektów danych klas w sposób dynamiczny, bez konieczności modyfikowania oryginalnych obiektów. Definicje jak zwykle brzmią zbyt sucho, spójrzmy więc na Listing 1, gdzie Co należy wiedzieć... Przydatna będzie znajomość dwóch poprzednich artykułów z naszej serii Wzorce projektowe. Czytelnik powinien mieć wiedzę z obiektowych technik projektowania aplikacji. Co obiecujemy... Z artykułu dowiesz się, kiedy i dlaczego warto stosować wzorzec projektowy dekorator. Na przykładach pokażemy, jak stosując dekorator, bardzo łatwo i w elegancki sposób dodać nową funkcjonalność do aplikacji bez zbędnej modyfikacji kodu. 2

2 Wzorce projektowe: dekorator Techniki znajduje się elementarny przykład użycia dekoratora. W przedstawionym przypadku użyliśmy dekoratora do wzbogacenia istniejącej funkcjonalności. Nie musimy jednak zbyt ściśle sugerować się nazwą wzorca projektowego i spokojnie możemy pozwolić sobie na całkowitą zmianę funkcjonalności dekorowanego obiektu. Dwa proste przykłady, przedstawione na wspomnianych listingach, obrazują praktycznie wszystkie istotne cechy wzorca, z którym się zaznajamiamy. Szczególne istotny do odnotowania jest jeden fakt: dla klienta korzystającego z udekorowanego (często mówimy również - "opakowanego") obiektu obecność dekoratora jest zupełnie przezroczysta! Klient nie jest w stanie stwierdzić, czy korzysta z usług oryginalnego obiektu, czy też z jego udekorowanej wersji. Jest to możliwe dzięki zachowaniu przez dekorator interfejsu oryginalnego obiektu. Jeśli chcielibyśmy zapamiętać jakąś jedną zasadę czy zdanie opisujące dekoratory, mogłoby to być: Dokorator zachowuje interfejs oryginalnego obiektu i najczęściej przyjmuje dekorowany obiekt jako parametr w swoim konstruktorze. Kolejną bardzo miłą cechą dekoratora jest możliwość użycia więcej niż jednego "opakowania" dla podstawowego obiektu. Oznacza to, iż możemy składać nową funkcjonalność z wielu już istniejących elementów, bez konieczności ingerencji w raz stworzony kod. Jest to dokładnie ta sama filozofia, jaką spotykamy przy pracy z powłoką w systemach uniksowych. Doskonale wiemy, jak wiele pożytecznych operacji można wykonać, zaprzęgając do wspólnej pracy elementarne narzędzia. To samo odnosi się do dekoratorów: sprytnie łącząc wiele prostych dodatków możemy uzyskać funkcjonalność, o której nie śniło się nawet twórcom piszącym klasy czy też dekoratory (Listing 2). Zanim przejdziemy do omówienia bardziej skomplikowanych przykładów, zatrzymajmy się jeszcze na chwilę nad własnością dekoratorów, dzięki której klient nie jest w stanie rozróżnić, czy ma do czynienia z obiektem podstawowym, czy też z opakowaną jego wersją. Uważny Czytelnik zauważy, że ta nierozróżnialność jest możliwa, ponieważ pomiędzy dekoratorem i obiektem dekorowanym zachodzi taka sama relacja ("jest", Listing 1. Prosty przykład użycia dekoratora ang. IS-A), jak przy dziedziczeniu. Istotnie, przykład z Listingu 2 można by zapisać tylko i wyłącznie przy pomocy tworzenia nowych podklas (Listing 3). Jaki jest więc sens wprowadzania zupełnie nowej konstrukcji programistycznej i opisywania jej jako wzorca projektowego? Przecież to samo można uzyskać przy użyciu podstawowych konstrukcji programowania obiektowego. Jest jedna, dosyć istotna różnica pomiędzy dwoma wspomnianymi podejściami. Aby ją łatwo pokazać, przemodelujmy przykład z Listingu 2, zmieniając kolejność zastosowanych dekoratorów (Listing 4). Proszę bardzo: cała operacja była wyjątkowo prosta, odbyła się bez konieczności modyfikowania istniejącego kodu i doprowadziła do powstania nowej funkcjonalności. Niestety, w przypadku dziedziczenia mamy dużo trudniejsze zadanie: nie obędzie się bez dosyć istotnego przemeblowania napisanego kodu. Powodem jest fakt, iż formując hierarchię dziedziczenia tworzymy dość sztywne, statyczne powiązanie pomiędzy poszczególnymi klasami. W przypadku dekoratorów nie mamy takiego ograniczenia: możemy dowolnie przestawiać kolejność, dodawać nowe elementy do łańcucha i usuwać już istniejące. Takie zamiany są możliwe nie tylko w momencie ustalania struktury kodu, ale w dowolnym momencie, nawet w czasie wykonywania skryptu. Dzięki dekoratorom można uzyskać wszystkie dobrodziej- /** *interfejs, ktory może być implementowany przez wiele klas *ponieważ dekoratory również implementują ten interfejs *klient korzystający z udekorawanej klasy nie jest w stanie *rozróżnić, czy ma do czynienia z pierwotną, czy udekorowaną wersją */ interface UserDAO { public function save(user $user); public function findbyloginnamepassword($loginname, $password); class UserDAOImpl implements UserDAO { // standardowa funkcjonalność zapisywania // danych użytkowników do DB public function findbyloginnamepassword($loginname, $password){ // standardowa funkcjonalność odnajdywania // danych użytkowników po nazwie class UserDAOUpperCaseLoginDecorator implements UserDAO { private $_decorateddao; public function construct(userdao $decorateddao){ $this->_decorateddao = $decorateddao; //zadaniem dekoratora jest zapisywanie loginów //tylko wielkimi literami $user->setloginname(strtoupper($user->getloginname())); //wywołanie oryginalnej funkcjonalności $this->_decorateddao->save($user); public function findbyloginnamepassword($loginname, $password) { //implementacja wyszukiwania pozostaje bez zmian return $this->_decorateddao->findbyloginnamepassword( $loginname, $password); //konstruowanie udekorowanej wersji obiektu $dao = new UserDAOUpperCaseLoginDecorator(new UserDAOImpl()); 3

3 Techniki Wzorce projektowe: dekorator Listing 2. Łączymy dekoratory stwa dziedziczenia, ale w sposób bardziej elastyczny. Nie oznacza to oczywiście, iż namawiamy Was, by od dzisiaj nie używać dziedziczenia i pisać tylko dekoratory. Jak każdy wzorzec projektowy, dekorator nie powinien być stosowany tylko w celu otrzymania bardziej elastycznej architektury, ale w przypadkach, w których będzie naprawdę pomocny. Uzbrojeni w solidne podstawy teoretyczne możemy przyjrzeć się wreszcie przykładom pokazującym, jak w łatwy i efektywny sposób rozbudować nasze aplikacje bez konieczności modyfikacji ich podstawowego kodu. Wróćmy zatem do przykładów. Jedną z dobrych praktyk architektonicznych jest dzielenie kodu aplikacji na warstwy. W typowej aplikacji WWW, najniższą warstwę stanowi baza danych (najczęściej w postaci relacyjnej bazy danych lub zwykłych plików). Powyżej umieszczamy wartwę dostępu do danych w postaci obiektów DAO (ang. Data Access Objects). Już ta jedna wspomniana warstwa jest okazją do zaimplementowaniu wielu funkcjonalności w postaci dekoratorów. Wyobraźmy sobie, że chcemy zapisywać czas wyszukiwania danych w DB. Nic prostszego: zamiast modyfikować istniejący kod, otoczmy go dodatkową klasą (Listing 5). A może mamy DAO służące do zapisu danych użytkowników i w pewnych przypadkach chcemy szyfrować hasła. Proszę bardzo: zamiast utrzymywać dwie zbliżone wersje tego samego DAO, dużo efektywniej rozwiążemy problem stosując prosty dekorator bez modyfikowania i duplikowania istniejącego kodu. Przykłady można mnożyć również w innych warstwach sytemu. Jeśli pomyślimy o dowolnej logice biznesowej zapisującej dane, to dekoratory znajdą zastosowanie przy wersjonowaniu danych, zapisywaniu logów zmian, kontroli dostępu itd. Przesuwając się jeszcze jedną warstwę wyżej, do kontrolerów MVC, szybko odkryjemy kolejne zastosowania: śledzenie zachowań użytkowników (np. ścieżki poruszania się po serwisie WWW) czy sprawdzanie uprawnień. Zastosowania i przykłady można by mnożyć w nieskończoność. Poprzestańmy więc na stwierdzeniu, że wzorzec dekoratora jest niezwykle użyteczny i podpowiada eleganckie rozwiązania dla często spotykanych problemów związanych z dodawaniem specyficznej funkcjonalności w różnych wersjach tej samej, podstawowej aplikacji. Ta mnogość i wygoda zastosowań powoduje, że w złożonej aplikacji możemy mieć wiele dekoratorów dla jednego obiektu. Pisanie takiej ilości dekoratorów i zarządzanie ich konfiguracją stanowi wyzwanie samo w sobie. W dalszej części artykułu zastanowimy się więc, jak szybko pisać i konfigurować dekoratory. Zatrzymajmy się na dłużej nad przywołanym przykładem zastosowania dekoratorów do dodania obsługi uprawnień na poziomie warstwy kontrolerów MVC. Listing 6 pokazuje dwa przykładowe kontrolery oraz opakowanie z dekoratorów sprawdzających uprawnienia. Przedstawiony schemat dodawania obsługi uprawnień do aplikacji jest niezwykle efektywny. Po pierwsze, pozwala uruchamiać tą samą aplikację ze sprawdzaniem uprawnień i bez, w zależności od wymagań klienta. class UserDAOPasswordHashingDecorator implements UserDAO { private $_decorateddao; public function construct(userdao $decorateddao){ $this->_decorateddao = $decorateddao; //zadaniem dekoratora jest zapisywanie loginów //tylko wielkimi literami $user->setpassword(md5($user->getpassword())); //wywołanie oryginalnej funkcjonalności $this->_decorateddao->save($user); public function findbyloginnamepassword($loginname, $password) { //przy wyszukiwaniu również szyfrujemy hasła return $this->_decorateddao->findbyloginnamepassword( $loginname, md5($password)); //konstruowanie wielokrotnie udekorowanej wersji obiektu $dao = new UserDAOUpperCaseLoginDecorator(new UserDAOPasswordHashingDecorator( new UserDAOImpl())); Listing 3. Przykład z Listingu 2 zapisany przy pomocy nowych podklas class UserDAOUpperCaseLogin extends UserDAOImpl { $user->setloginname(strtoupper($user->getloginname())); parent::save($user); class UserDAOPasswordHashing extends UserDAOUpperCaseLogin { $user->setpassword(md5($user->getpassword())); parent::save($user); public function findbyloginnamepassword($loginname, $password) { return parent::findbyloginnamepassword($loginname, md5($password)); //konstruowanie wersji obiektu z dziedziczeniem $dao = new UserDAOPasswordHashing(); Listing 4. Zmieniona kolejność zastosowanych dekoratorów w stosunku do Listingu 2. Tworzymy nową funkcjonalność bez modyfikacji istniejącego kodu. $dao = new UserDAOPasswordHashingDecorator(new UserDAOUpperCaseLoginDecorator( new UserDAOImpl())); 4

4 Wzorce projektowe: dekorator Techniki Rysunek 1. Uproszczony graf obiektów w naszej aplikacji Z drugiej strony, taka architektura umożliwia niezależne pisania kodu biznesowego i odpowiedzialnego za bezpieczeństwo. Wreszcie, możemy sobie wyobrazić zastosowanie różnych silników do sprawdzania uprawnień (np. własny lub GACL). Niestety, nasze wszystkie zachwyty trochę przybledną, jeśli uświadomimy sobie, że dla każdego kontrolera trzeba stworzyć osobny dekorator. Nie jest to może wielkim problemem przy pięciu czy dziesięciu kontrolerach, ale staje się koszmarem przy dużych aplikacjach, gdzie często spotkamy setki klas typu kontroler. Nasze miny staną się jeszcze bardziej nietęgie, jeśli uświadomimy sobie, że każdy z dekoratorów będzie do siebie bardzo podobny. Ponowny rzut oka na Listing 6 faktycznie ujawnia, że w kolejnych dekoratorach różnią się tylko nazwy klas i metod zasadnicza logika pozostaje praktycznie bez zmian. Bezmyślne pisanie niemal identycznych dekoratorów nie jest zajęciem szczególnie ciekawym czy produktywnym, a dodatkowo to oczywista duplikacja kodu. Musimy więc znaleźć jakiś sposób na zautomatyzowanie żmudnego zajęcia. PHP5, jako język niezwykle dynamiczny daje nam szerokie możliwości generowania szablonowego kodu w locie. Spośród wielu opcji dwie wydają się najciekawsze: użycie magicznej metody call lub generowanie całego kodu dekoratora w czasie działania skryptu. Obie metody mają swoje wady i zalety, które za chwilę omówimy, ale najpierw spójrzmy na Listing 7, gdzie znajdują się przykładowe dekoratory (z Listingu 6), zaimplementowane przy użyciu obu wspomnianych metod. Dekorator stworzony przy pomocy call jest dosyć prosty i pozwala prezycyjnie regulować, które metody w dekoratorze są generowane automatyczne, a które ręcznie. Po prostu dla tych, które chcemy napisać sami, tworzymy kon- kretną metodą, a wprzypadku pozostałych metod polegamy na call. Omawiana właśnie metoda ma w zasadzie tylko jedną wadę w ten sposób wygenerowane dekoratory nie mogą być użyte w wywołaniach funkcji i metod, dla których określono typ argumentu (a więc dla konstrukcji $obiekt->nazwametody(typargumentu $agrument);). Jest to dość poważna wada, ponieważ na początku podkreślaliśmy, iż jedną z cech dekoratora jest zachowanie interfejsu oryginalnego obiektu. Zastosowanie call do generowania dekoratorów wyklucza silniejszą kontrolę typów, a tym samym interfejsów implementowanych przez podstawową i udekorowaną klasę. Aby obejść zidentyfikowany problem, posłużymy się prostą koncepcyjnie metodą generowaniem kodu w locie. Spójrzmy na Listing 8, gdzie pokazujemy użycie specjalnie przygotowanej biblioteki (PHPProxy, dostępnej na sourceforge.net) do generowania kodu. Jak widać, samo jej użycie jest niezwykle proste sprowadza się do zaimplementowania tylko tej logiki, która ma się znaleźć w dekoratorze nie musimy powielać ani jednego znaku kodu. Tak prosta implementacja jest możliwa dzięki istnieniu interfejsu ProxyInvocationHandler. W interfejsie tym zdefiniowana jest tylko jedna metoda invoke($method, $args). Nie trzeba być potomkiem Sherlocka Holmesa by wydedukować, że metoda ta jest uruchamiana w momencie wywoływania metod na dekoratorze, a w argumetach otrzymujemy wszystkie niezbędne informacje o wywołaniu tj. nazwę metody i jej argumenty. Korzystając z implementacji interfejsu ProxyInvocationHandler z opisywanej biblioteki (Listing 9), możemy łatwo zdecydować, czy chcemy tylko udekorować oryginalną funkcjonalność (a więc wywołać ją podczas uruchamiania dekoratora), czy też stworzyć zupełnie nowy kod: cały sekret tkwi w meto- Listing 5. Dodajemy nową funkcjonalność do zapisywania czasu wyszukiwania danych w DB class PerformanceLoggingUserDAO implements UserDAO { private $_decorateddao; private $_starttime; public function construct(userdao $decorateddao){ $this->_decorateddao = $decorateddao; $this->startmethodexecution(); $this->_decorateddao->save($user); $this->stopmethodexecution('save'); public function findbyloginnamepassword($loginname, $password) { $this->startmethodexecution(); return $this->_decorateddao->findbyloginnamepassword( $loginname, $password); $this->stopmethodexecution('findbyloginnamepassword'); private function startmethodexecution(){ $this->_starttime = microtime(); private function stopmethodexecution($methodname){ $executiontime = microtime() - $this->_starttime; echo "Wykonanie metody '$methodname' zajęło $executiontime <br>"; //konstruowanie udekorowanej wersji obiektu $dao = new PerformanceLoggingUserDAO(new UserDAOImpl()); 5

5 Techniki Wzorce projektowe: dekorator dzie getdelegate(), dzieki której możemy pobrać dekorowany obiekt i wywołać na nim dowolną metodę. Użycie biblioteki PHPProxy pozwala generować dekoratory przy minimalnym nakładzie pracy ze strony programisty i przy eliminacji powtórzeń w kodzie. Niestety, nie jest to metoda pozbawiona wad. Po pierwsze, generowanie kodu w czasie działania programu może być zbyt czasochłonne w przypadku mocno obciążonych serwisów internetowych, gdzie wydajność jest rzeczą krytyczną. Drugi, trochę mniej uciążliwy problem, związany jest z przypadłością nękająca wszystkie rozwiązania oparte o generowanie kodu. Otóż podczas wykonania programu uruchamiany jest również kod, który... nie jest nigdzie zapisany na stałe. Oznacza to, że w pewnych warunkach śledzenie wykonania programu (np. podczas wyszukiwania błędów) może być nieco utrudnione. Tak czy inaczej, mimo przedstawionych wad, jest to zdecydowanie najłatwiejsza metoda tworzenia wielu dekoratorów. Podsumujmy naszą dotychczasową wiedzę o dekoratorach. Na wstępie stwierdziliśmy, że jest to bardzo pożyteczny wzorzec, który może być stosowany praktycznie w każdej warstwie systemu. Jest to alternatywa do dziedziczenia obiektów, umożliwiająca wzbogacanie lub zmianę istniejącej funkcjonalności, bez konieczności modyfikacji raz napisanego kodu. Dekorator pada jednak trochę ofiarą własnego sukcesu mnogość jego zastosowań powoduje, że w bardziej rozbudowanej aplikacji możemy wykorzystać setki obiektów implementujących wzorzec dekoratora. Aby nie zginąć w tym gąszczu podobnych obiektów, znaleźliśmy dwie metody na dynamiczne generowanie dekoratorów. Niestety, to nie koniec problemów, które musimy rozwiązać, aby efektywnie wykorzystać dekoratory jako integralną część rozwiązania architektonicznego. Załóżmy, że Rysunek 1 przedstawia uproszczony graf obiektów w naszej aplikacji. Obiekty te są oczywiście ułożone w warstwy, natomiast obiekty są połączone między sobą siecią zależności. Już samo poprawne skonstruowanie takiej sieci obiektów może być nie lada wyzwaniem, o czym Czytelnik mógł się przekonać, śledząc mój artykuł Obiektowa linia montażowa, czyli przejrzyste Rysunek 2. Dodając dekoratory, wprowadzamy do omawianego grafu kolejny stopień skomplikowania, opakowując wybrane obiekty aplikacji j Listing 6a. Dwa przykładowe kontrolery oraz opakowanie z dekoratorów sprawdzających uprawnienia class useraction { private $_userservice; public function construct(userservice $userservice) { $this->_userservice = $userservice; public function listall(httprequest $request, ModelAndView $mv){ $users = $this->_userservice->findall(); $mv->addtomodel('users',$users); $mv->setview('userslist'); public function listwithexpensivequery( HttpRequest $request, ModelAndView $mv){ $users = $this->_userservice->finduserbyexpensivequery(); $mv->addtomodel('users',$users); $mv->setview('userslist'); public function addform(httprequest $request, ModelAndView $mv){ $mv->setview('useraddform'); public function add(httprequest $request, ModelAndView $mv){ $user = new User( $request->getparam('login'), $request->getparam('pass'), $request->getparam('firstname'), $request->getparam('lastname')); $mv->addtomodel('user',$user); try { $this->_userservice->adduser($user); $mv->setview('useraddconfirm'); catch (UserExistsException $e) { $mv->addtomodel('adduser_error','user exists!'); $mv->setview('useraddform'); class homepage { public function show(httprequest $request, ModelAndView $mv){ $mv->setview('homepage'); 6

6 Wzorce projektowe: dekorator Techniki Listing 6b. Dwa przykładowe kontrolery oraz opakowanie z dekoratorów sprawdzających // Klasa pomocnicza dla dekoratorów, gdzie odbywa się // właściwe sprawdzanie uprawnień abstract class AbstractActionSecurityDecoratorImpl { private $_decoratedaction; public function construct($decoratedaction) { $this->_decoratedaction = $decoratedaction; public function executetargetactionwithsecuritycheck( $targetaction, HttpRequest $request, ModelAndView $mv){ Rysunek 3. W Pico zawarta jest cała konfiguracja związana z połączeniami pomiędzy obiektami. Aby wprowadzić dodatkowy obiekt pośredniczący, musimy jedynie przekonfigurować połączenia. //tutaj tylko proste sprawdzanie, czy zalogowany, //ale równie łatwo zintegrować np. GACL session_start(); if ($_SESSION['user'] == null) { $mv->setview('loginform'); else { return $this->_decoratedaction->$targetaction($request, $mv); //Mimo, iż obie akcje są zupełnie inne, //to dekoratory są niemal identyczne! //Oczywista duplikacja kodu! class UserActionSecurityDecoratorImpl extends AbstractActionSecurityDecoratorImpl { public function listall(httprequest $request, ModelAndView $mv){ 'listall', $request, $mv); public function listwithexpensivequery( HttpRequest $request, ModelAndView $mv){ 'listwithexpensivequery', $request, $mv); public function addform(httprequest $request, ModelAndView $mv){ 'addform', $request, $mv); public function add(httprequest $request, ModelAndView $mv){ 'add', $request, $mv); class HomepageActionSecurityDecoratorImpl extends AbstractActionSecurityDecoratorImpl { public function show(httprequest $request, ModelAndView $mv){ 'show', $request, $mv); i elastyczne aplikacje w PHP5, z numeru 1/2006. Dodając dekoratory, wprowadzamy do omawianego grafu kolejny stopień skomplikowania, opakowując wybrane obiekty aplikacji (Rysunek 2). Warto przy tym zauważyć, że udekorowaniu będą podlegały głównie obiekty infrastrukturalne (kontrolery, DAO itd.), a nie domenowe. Musimy więc znaleźć jakiś łatwy sposób na dodanie wielu dekoratorów w całej aplikacji, bez konieczności ręcznego przebudowywania połączeń. Przy składaniu skomplikowanych grafów obiektów doskonale sprawdza się wzorzec architektoniczny IoC (ang. Inversion of Control), o którym również pisaliśmy w wyżej wspomnianym artykule. Mamy szczęście, ponieważ ten sam wzorzec również znakomicie ułatwia dodawanie dekoratorów. Dlaczego? Przypomnijmy, że w przypadku stosowania wzorca IoC bardzo pomocne są biblioteki typu kontener IoC. Te lekkie kontenery biorą na siebie cały ciężar tworzenia skomplikowanych grafów obiektów, dbając przy tym o właściwe rozwiązanie zależności pomiędzy obiektami. Kontener IoC jest więc jednym, centralnym miejscem, gdzie powoływane są do życia instancje obiektów infrastrukturalnych. Doskonale, o to nam właśnie chodziło. To scentralizowane miejsce tworzenia obiektów pozwala nam łatwo dodać nasze "opakowania". Spójrzmy na Listing 10, gdzie znajdziemy przykład wykorzystania Pico dla PHP lekkiego kontenera IoC do dodania dekoratorów do obiektów aplikacji. Jak widać, cała operacja jest stosunkowo prosta wystarczą dwie linijki kodu. Przeanalizujmy dokładniej przykład z Listingu 10. Widzimy na nim początkowo dwa współpracujące ze sobą obiekty: serwisowy i DAO. Są to obiekty infrastrukturalne, podczas dzialania aplikacji potrzebny jest zwykle tylko jeden egzemplarz takiego obiektu. W tym przypadku to Pico dba o powołanie do życia instancji obiektów oraz ich połączenie. Aby zastosować dekorator zliczający czas wykonania poszczególnych metod, musimy w jakiś sposób rozerwać ścisłe połączenie pomiędzy obiektem DAO i obiektem z DAO korzystającym. Przy klasycznym podejściu do budowy programów, gdybyśmy użyli operatora new, metod statycznych lub fabryk, mielibyśmy małe szanse na wprowadzenie trzeciego obiektu w łańcuch powią- 7

7 Techniki Wzorce projektowe: dekorator Listing 7. Dekorator (z Listingu 6), zaimplementowany przy użyciu call oraz generowanie całego kodu dekoratora w czasie działania skryptu // implementacja dekoratora z wykorzystaniem metody call class UserActionSecurityDecoratorCallImpl extends AbstractActionSecurityDecoratorImpl { public function call ($methodname, $args ) { $request = $args[0]; $mv = $args[1]; $methodname, $request, $mv); class HomepageActionSecurityDecoratorCallImpl extends AbstractActionSecurityDecoratorImpl { public function call ($methodname, $args ) { $request = $args[0]; $mv = $args[1]; $methodname, $request, $mv); Listing 8. Działanie PHPProxy do dynamicznego generowania kodu // biblioteka do dynamicznego generowania klas require_once(dirname( FILE ).'/phpproxy/src/proxygenerator.inc.php'); // wprowadzamy interfejs na fragment kodu sprawdzający uprawnienia, aby mieć // możliwość stosowania różnych sposobów i bibliotek interface SecurityChecker { function hasrightsfor(user $user, $actiontocheckrightsfor); class SecurityCheckerIsNotNull implements SecurityChecker { function hasrightsfor(user $user, $actiontocheckrightsfor){ if ($user!= null) { //tu tylko proste sprawdzanie, ale chcemy pokazać, //że kod odpowiedzialny za sprawdzanie uprawnień //jest wydzielony i może być użyty w dekoratorach return true; else { return false; // Część wspólna dla wszystkich dekoratorów. Nie ma tu duplikacji kodu jak na // Listingu 7.Cała logika związana ze sprawdzeniem uprawnień i wyowołaniem // (lub nie) dekoratora zamknięta jest w tej jednej klasie class SecurityCheckerMethodInvImpl extends DelegatingInvocationHandler { private $_securitychecker; private $_decoratedaction; public function construct(securitychecker $securitychecker) { $this->_securitychecker = $securitychecker; public function invoke($method, $args) { $request = $args[0]; $mv = $args[1]; $user = getloggedinuser(); if ($this->_securitychecker($user, $method)){ return parent::invoke($method, $args); else { $mv->setview('loginform'); public function getloggedinuser(){ session_start(); return $_SESSION['user']; $proxygenerator = new ProxyClassGenerator(); $securemethodinvocation = new SecurityCheckerMethodInvImpl( new SecurityCheckerIsNotNull()); // dynamiczne wygenerowanie dowolnego dekoratora sprowadza się do jednej linii // kodu! $useractiondecorated = $proxygenerator->getproxy( 'useraction', $securemethodinvocation); $homepagedecorated = $proxygenerator->getproxy( 'homepage', $securemethodinvocation); zań. W przypadku kontenera IoC sprawa jest o wiele prostsza, ponieważ w Pico zawarta jest cała konfiguracja związana z połączeniami pomiędzy obiektami. Jedyne, co musimy zrobić, to przekonfigurować te połączenia w taki sposób, by wprowadzić dodatkowy obiekt pośredniczący (Rysunek 3). W Pico robimy to przy pomocy parametrów komponentu, tak jak pokazaliśmy w drugiej części Listingu 10. Oczywiście pokazany sposób można wykorzystać do użycia więcej niż jednego dekoratora (Listing 11). Kontenery IoC w znaczący sposób ułatwiają stosowanie dekoratorów w złożonych aplikacjach. Dzieki nim możemy w jednym, centralnym miejscu, skonfigurować połączenia między obiektami i tym samym dodać nowy element do takiego połączenia. Sposób jest dość prosty i nie wymaga zmian w kodzie PHP jedynie w konfiguracji kontenera IoC. Listing 9. Korzystając z implementacji interfejsu ProxyInvocationHandler z opisywanej biblioteki możemy łatwo zdecydować, czy chcemy tylko udekorować oryginalną funkcjonalność, czy też stworzyć zupełnie nowy kod interface ProxyInvocationHandler { public function invoke($method, $args); class DelegatingInvocationHandler implements ProxyInvocationHandler { private $_delegate = null; public function construct( $delegate){ $this->_delegate = $delegate; public function invoke( $method, $args){ $reflectionclass = new ReflectionClass( get_class($this-> getdelegate())); $reflectionmethod = $reflectionclass-> getmethod($method); return $reflectionmethod-> invokeargs( $this->getdelegate(),$args); public function getdelegate(){ return $this->_delegate; 8

8 Wzorce projektowe: dekorator Techniki Listing 10. Przykład wykorzystania Pico dla PHP lekkiego kontenera IoC do dodania dekoratorów do obiektów aplikacji $parentpico = new DefaultPicoContainer(); $parentpico->regcomponentimpl('frontcontroller', 'FrontControllerImpl'); $parentpico->regcomponentimpl( 'ActionResolvingStrategy', //componentkey 'PicoActionResolvingStrategy', //componentclass array ('paramname' => 'action') ); $parentpico->regcomponentimplwithincfilename( dirname( FILE ).'/lib/smartyviewresolver.php', 'ViewResolvingStrategy', 'SmartyViewResolvingStrategy', array ( array('compile_dir' => dirname( FILE ).'/work/templates_c'), 'file:'.dirname( FILE ).'/templates/smarty/', '.tpl') ); $pico = new DefaultPicoContainer(null, $parentpico); $pico->regcomponentinstance($pico, 'PicoContainer'); '/../shared/model/model.inc.php','userservice','userserviceimpl'); '/../shared/model/model.inc.php','userdao','userdaopdoimpl'); $pico->regcomponentimpl('pdo','pdopicoadapter',array ( 'pgsql:dbname=ditalkdb;host=localhost', 'postgres', 'postgres')); //actions '/actions/loginaction_action.php','loginaction','loginaction'); '/actions/useraction_action.php','useractiontarget', 'useraction'); $pico->regcomponentimpl('useraction', 'UserActionSecurityDecoratorImpl', array ('decoratedaction' => new BasicComponentParameter('useractionTarget'))); '/actions/homepage_action.php','homepagetarget','homepage'); $pico->regcomponentimpl('homepage', 'HomepageActionSecurityDecoratorImpl', array ('decoratedaction' => new BasicComponentParameter('homepageTarget'))); $fc = $pico->getcomponentinstance('frontcontroller'); $fc->doservice(new HttpRequest()); Rozwiązanie jest prawie idealne. Prawie, bo w dalszym ciągu dla każdego dekoratora trzeba dodać nowy wpis w konfiguracji i zmodyfikować połączenia między obiektami. Dla twórczo lewniwego programisty to zdecydowanie zbyt duży wysiłek. Jeśli pomyślimy całościowo o stylu programowania, w którym napisany został Listing 10, to powinna nasunąć się Listing 11. Przykład rozwiązania, które nie skazuje nas na żmudne deklarowanie pojedynczych dekoratorów //rejestracja poprzednich komponentów //jak na Listingu 10 '/actions/useraction_action.php','useraction', 'useraction'); '/actions/homepage_action.php','homepage','homepage'); '/actions/loginaction_action.php','loginaction','loginaction'); //security decorators $pico->regcomponentimpl('securitymethodinterceptor'); $pico->registeraspect(new Aspect(new RegExpNameMatchingPointcut( '/^[a-km-z]+action$/'),new MatchingAllPointcut(), 'SecurityMethodInterceptor')); nam pewna refleksja. Otóż w opisywanym przypadku stosujemy dekoratory do globalnych zmian w całej aplikacji. Patrzymy na działające skrypty i myślimy: teraz chcielibyśmy dodać logowanie do wszystkich obiektów DAO, żeby zobaczyć, gdzie jest wąskie gardło wydajnościowe, albo: teraz udekorujmy wszystkie kontrolery, żeby sprawdzać uprawnienia. Niestety, wypracowana do tej pory metoda skazuje nas na żmudne deklarowanie pojedynczych dekoratorów. Gdyby tylko istniała konstrukcja programistyczna, pozwalająca łatwo wyrazić żądania typu: obiekty określonego typu udekoruj danym kodem, moglibyśmy dosłownie w kilku linijkach kodu wprowadzić do aplikacji logowanie czy sprawdzanie uprawnień. Zupełnie niezależnie od ilości obiektów do udekorowania. Na pocieszenie chcemy powiedzieć, że takie metody już powstają (przykładowy Listing 11)! Jest to idea bardzo zbliżona do programowania aspektowego (ang. Aspect Oriented Programming), ale to już temat na zupełnie inny artykuł. Podsumowanie W artykule pokazaliśmy, że dekorator jest prostym i niezwykle pożytecznym wzorcem projektowym. Jest tak użyteczny, że w pewnym momencie możemy mieć ochotę zastosować go na bardzo szeroką skalę. Aby jednak zrobić to efektywnie, musimy zadbać o rozwiązanie dwóch problemów: automatycznego generowania dekoratorów oraz ich konfiguracji w całej aplikacji. Z pierwszym problem doskonale poradzimy sobie dynamicznie generując powtarzalny kod dekoratora. Zastosowanie kontenera IoC wpłynie dodatnio na architekturę naszej aplikacji i umożliwi łatwe konfigurowanie dekoratorów. Jeśli zrozumiemy i opanujemy przedstawione powyżej triki, świat programowania aspektowego nie będzie miał przed nami tajemnic. O autorze: Paweł Kozłowski jest pracownikiem SU- PERMEDIA, gdzie od roku 2000 projektuje i tworzy złożone aplikacje WWW w PHP. Obecnie zajmuje się rozwijaniem frameworków i bibliotek ORM opartych na PHP5. Jest autorem portu PicoContainer dla PHP5 i wielu publikacji poświęconych PHP. Kontakt: pkozlowski@phpsolmag.org 9