Rozwiązywanie problemów przekrojowych z użyciem IoC

Transkrypt

1 Dla zaawansowanych Rozwiązywanie problemów przekrojowych z użyciem IoC Piotr Szarwas Stopień trudności: W każdej aplikacji podzielonej na warstwy występują elementy, których nie można przypisać do żadnej z warstw i które stanowią twardy orzech do zgryzienia nawet dla dużego zespołu programistów. Istnieje jednak w miarę prosty sposób poradzenia sobie z nimi: użycie kontenera IoC... W SIECI XXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXXX Każdą aplikację można podzielić na logiczne warstwy. Najczęściej występują trzy warstwy: warstwa danych, logiki biznesowej i prezentacji. Wszystkie spośród nich powinny być nałożone na siebie tak, aby wyższa wiedziała tylko o istnieniu jednej warstwy niższej; wszystko, co znajduje się poniżej, powinno być dla niej niedostępne. Z drugiej strony, warstwa niższa nie wymaga dla swojego działania istnienia żadnej z warstw wyższych. Podział ten ilustrujemy na Rysunku 1. Można jeszcze bardziej dopracować ten schemat mówiąc, że aplikacja powinna posiadać aż pięć warstw: warstwę danych, dostępu do danych, logiki biznesowej/usług, kontrolerów i prezentacji. Ten drugi podział wynika bezpośrednio ze stosowania wzorców programistycznych i architektonicznych. Przykładowo, kontrolery i prezentacja stanowią element wzorca architektonicznego MVC. Pojawienie się warstwy dostępu do danych wynika z zastosowania wzorca DAO, który uniezależnia logikę biznesową od warstwy danych. Dzięki temu można łatwo wymieniać źródło danych. Schemat tego podziału pokazujemy na Rysunku 2. Rozbicie systemu na warstwy zapewnia szereg korzyści: Każdej z warstw można wymienić implementację, nie zmieniając jednocześnie implementacji pozostałych warstw. Jak już wspomnieliśmy, można na przykład wymienić warstwę DAO (dostępu do Co należy wiedzieć... Należy znać zasady programowania obiektowego w PHP5 z wykorzystaniem wzorców projektowych. Co obiecujemy... Pokażemy, jak rozwiązać niektóre spośród problemów przekrojowych (ang. crosscutting concerns). 2

2 Crosscutting concerns Dla zaawansowanych Niestety, praktyka bywa czasem bardziej skomplikowana i nie wszystkie zagadnienia programistyczne możemy umieścić na jednej wybranej warstwie. Te, których nie da się w ten sposób potraktować, nazywamy problemami przekrojowymi (ang. Crosscutting concerns). Najpopularniejsze z nich to: logowanie błędów i debugowanie, bezpieczeństwo i uwierzytelnianie, Rysunek 1. Podział aplikacji na trzy logiczne warstwy. Warstwa wyższa wie tylko o istnieniu warstwy znajdującej się bezpośrednio pod nią. Żadna z warstw niższych nie wie nic o wyższych danych) tak, aby obsługiwała inne źródło danych, nie zmieniając jednocześnie logiki biznesowej. Każda warstwa może być traktowana jako spójna całość. Pozwala to m.in. na tworzenie każdej warstwy przez osobny zespół programistów, który nie musi znać implementacji pozostałych warstw. Jeśli zostanie dobrze zaprojektowana, każda warwstwa(warstwa) może być wykorzystywana wielokrotnie, w różnych projektach lub miejscach tego samego projektu. transakcje. Problem logowania błędów Rozważmy problem logowania błędów. Praktycznie każda aplikacja zawiera elementy kodu odpowiadające za logowanie i debugowanie. Czy jednak możemy je przydzielić do którejś warstwy? Niestety nie. Ich kod jest rozproszony po całej aplikacji i występuje w każdej warstwie. Pamiętajmy, że z punktu widzenia logicznego podziału na warstwy, logowanie błędów nie jest ani częścią logiki biznesowej, ani innej warstwy. Bezpośrednie zakodowanie logiki logowania w każdej z warstw powoduje, że niezależność, przenaszalność i elastyczność tej warstwy drastycznie maleje. W przypadku logowania problem nie jest tak wielki, ale już w sytuacji, Listing 1. Implementacja klasy MailSender służącej do wysyłania maili. Kod klasy pozbawiony jest reguł problemów przekrojowych: logowania i bezpieczeństwa. Reguły te będą implementowane przez odpowiednie dekoratory interface MailSender { public function send($to, $from, $subject, $message); class MailSenderImpl implements MailSender { public function send($to, $from, $subject, $message) { return mail($to,$subject,$message,'from: '.$from); Listing 2. Przykładowa klasa dekorująca dowolną klasę implementującą interface MailSender class MailSenderDecorator implements MailSender { private $mailsender; public function construct(mailsender $mailsender ){ $this->mailsender = $mailsender; public function send($to, $from, $subject, $message) { $result = $this->send($to,$subject,$message,'from: '.$from); Rysunek 2. Podział aplikacji na pięć logicznych warstw. Warstwa wyższa wie tylko o istnieniu warstwy znajdującej się bezpośrednio pod nią. Żadna z warstw niższych nie wie nic o wyższych gdy w aplikacji zaszyjemy reguły bezpieczeństwa, czy też zdefiniujemy miejsca, w których rozpoczynają się i kończą transakcje, cały kod przestaje w zasadzie być przenaszalny i staje się mocno związany z regułami biznesowymi danej aplikacji. Rysunek 3 pokazuje schematycznie nasz problem. Skoro problemy przekrojowe mogę sprawić takie trudności, czy da się je wydzielić do osobnych modułów, które nie będą w ogóle powiązane z żadną z warstw? Okazuje się, że tak. Rozwiązania są dwa. Pierwsze, którym się zajmiemy w tym artykule, będzie polegało na wykorzystaniu wzorca Dekorator i kontenera IoC, który zbudowaliśmy wspólnie w poprzednim artykule. Drugi sposób opiera się na zastosowaniu programowania aspektowego (ang. aspect-oriented programming - AOP). Ten drugi sposób byłby dużo lepszym podejściem; niestety, obecnie dla PHP nie istnieje żaden framework AOP, który w wystarczającym stopniu implementowałby wszystkie założenia programowania aspektowego. Tak jak poprzednio, cały kod zaprezentowany w artykule zostanie umieszczony na stronie Wzorzec Dekorator Zgodnie z definicją GoF (ang. Gang of Four termin, który określa czwórkę pro- 3

3 Dla zaawansowanych Crosscutting concerns gramistów odpowiedzialnych za zapoczątkowanie idei wzorców projektowych zadaniem wzorca Dekorator jest wzbogacanie funkcjonalności obiektów wybranych klas w sposób dynamiczny, bez konieczności modyfikowania oryginalnego kodu. Ponieważ ta definicja może być mało przejrzysta, posłużymy się przykładem. Zbudujemy prostą klasę MailSenderImpl, której zadaniem będzie wysyłanie maili (Listing 1). Wiemy, że klasa ta będzie na tyle uniwersalna, że będziemy chcieli wykorzystać ją w kilku innych, już istniejących projektach. Niestety, każdy z tych projektów ma inne wymagania biznesowe związane z regułami logowania i bezpieczeństwa. Dlatego nie wyposażymy klasy MailSenderImpl w logikę związaną z tymi aspektami, lecz zaimplementujemy tę ostatnią w dekoratorach (Listing 2). Za każdym razem, gdy w którymś z projektów zaistnieje potrzeba wysłania maila, wykorzystamy do tego odpowiedni dekorator, przykładowo: new MailSenderDecorator( new MailSenderImpl()) Listing 3. Implementacja nowej wersji kontenera IoC obsługującej dekorowanie obiektów class IoCContainerWithDecoratorSupport extends DefaultIoCContainter { private $decoratorssupport = array(); public function create($classname) { $classobj = parent::create($classname); if (!$classobj instanceof IoCDecoratorSupport&&!$classObj instanceof IoCDecorator){ foreach( $this->getdecoratorssupport() as $decoratorsupport ) { if ( $decoratorsupport->match($classname,$classobj) ) { $decoratorobj = parent::create( $decoratorsupport-> getdecoratorname() ); $decoratorobj->setobject($classobj); $classobj = $decoratorobj; return $classobj; public function setdecoratorssupport( array $decoratorssupport ) { foreach($decoratorssupport as $decorator) { if (!$decorator instanceof IoCDecoratorSupport ) { throw new Exception('Class '.get_class($decorator). ' does not implement IoCDecoratorSupport interface'); $this->decoratorssupport[] = $decorator; private function getdecoratorssupport(){ return $this->decoratorssupport; Rysunek 3. Problemy przekrojowe znajdują się zawsze z boku każdego podziału na warstwy, a ich kod jest rozproszony pomiędzy tymi ostatnimi Stosując wzorzec Dekorator udało się nam osiągnąć dwie rzeczy. Po pierwsze, uniwersalna klasa MailSender pozostała niezmieniona cała logika związana z wysyłaniem maili jest w jednym miejscu. Po drugie, kod charakterystyczny dla każdej z aplikacji znajduje się w osobnych klasach. Wykorzystując wzorzec Dekorator warto również pamiętać, że jest on bardzo użyteczny, gdy kod źródłowy klas nie jest dostępny: jego użycie stanowi wtedy jedyną możliwość zmiany zachowania obiektu. Wzorzec Dekorator w połączeniu z kontenerem IoC Wróćmy teraz do przedstawionego w poprzednim artykule kontenera IoC. Jak zapewne pamiętamy, kontener IoC to zwyczajnie konfigurowalna fabryka obiektów potrafiąca powołać do życia całe drzewa tych ostatnich. Pokażemy teraz, jak można wykorzystać kontener IoC tak, aby poza tworzeniem obiektów potrafił je także dekorować. Wyobraźmy sobie następujący problem: klient, który zlecił nam projekt, zażyczył sobie, aby każda operacja modyfikacji danych (kto, kiedy i co zmieniał) była logowana. Typowy programista zapewne rozwiązałby ten problem dokonując modyfikacji każdej metody zmieniającej dane. To podejście wydaje się najbardziej oczywiste, ale niestety jest najgorszym z możliwych. Zmodyfikowane zostałyby bowiem wszystkie kluczowe metody aplikacji, co oznacza potrzebę przetestowania całego projektu od nowa. Dodatkowym problemem byłaby konieczność przekazania do każdej z warstw aplikacji informacji o tym, kto aktualnie wykonuje daną metodę. Ponadto, jeżeli modyfikowany kod był wykorzystywany w innych projektach, programista musiałby przestać go współdzielić. Jak 4

4 Crosscutting concerns Dla zaawansowanych Listing 4. Implementacja klasy dopasowującej dekoratory do klas na podstawie nazw klas więc widać, podejście, które wydawało się najbardziej oczywiste, spowodowałoby całą lawinę problemów. My na szczęście będziemy mądrzejsi i do rozwiązania problemu wykorzystamy kontener IoC. Nasze założenie jest następujące: nie możemy dokonać żadnej modyfikacji kodu zapisującego i modyfikującego dane. Dlatego skonstruujemy kon- class ClassNameIoCDecoratorSupport implements IoCDecoratorSupport { private $decoratorname; private $classnametodecorator = array(); public function construct($decoratorname,array $classnametodecorator){ $this->decoratorname = $decoratorname; $this->classnametodecorator = $classnametodecorator; public function match($classname,$classobject) { return (in_array($classname,$this->classnametodecorator))?true:false; public function getdecoratorname() { return obiekt $this->decoratorname; z dekoratorem. W tym celu rozszerzymy klasę DefaultIoCContainer i zmodyfikujemy jej metodę create(). W nowej Listing 5. Implementacja klasy dopasowującej wersji dekoratory tej klasy, do jej klas metoda na podstawie create() najpierw wywołuje create() klasy nadrzęd- dowolnego wyrażenia regularnego class RegExpIoCDecoratorSupport implements nej. IoCDecoratorSupport Następnie sprawdza, { czy powołany private $decoratorname; private $pattern; public function construct($decoratorname,$pattern){ $this->decoratorname = $decoratorname; $this->pattern = $pattern; public function match($classname,$classobject) { return (preg_match($this->pattern,get_class($classobject)))?true:false; public function getdecoratorname() { return $this->decoratorname; Listing 6. Implementacja klasy dopasowującej dekoratory do klas na podstawie interfejsu class InterfaceIoCDecoratorSupport implements IoCDecoratorSupport { private $decoratorname; private $interfacename; public function construct( $decoratorname,$interfacename){ $this->decoratorname= $decoratorname; $this->interfacename= $interfacename; public function match($classname, $classobject) { return ($classobject instanceof $this->interfacename)? true:false; public function getdecoratorname(){ return $this->decoratorname; tener, który na podstawie odpowiedniego wzorca składającego się z nazwy klasy oraz implementowanego przez nią interfejsu będzie umiał udekorować tworzony obiekt. Zabierzmy się więc do pracy. Pierwszym krokiem będzie modyfikacja kontenera IoC tak, aby na podstawie zadanego wzorca mógł połączyć dekorowany obiekt nie implementuje jednego z interfejsów klas pomocniczych dekoratorów, aby uniknąć dekoracji tych ostatnich. Następnie kontener sprawdza przy pomocy klas pomocniczych, czy nazwa świeżo powołanej klasy pasuje do wzorca któregoś z dekoratorów. Jeżeli tak, to klasa pomocnicza zwraca nazwę dekoratora. Każda klasa pomocnicza musi implementować interfejs IoCDecoratorSupport, który z kolei składa się z dwóch metod: match() zwraca true, jeżeli wzorzec dekoratora pasuje do wzorca klasy, getdecoratorname() zwraca nazwę dekoratora z pliku konfiguracyjnego IoC. Klasy pomocnicze dostarczane są do kontenera poprzez metodę setdecorators(). Następnie kontener IoC powołuje do życia tenże dekorator i umieszcza w nim dekorowany obiekt. Dekorator musi implementować interfejs IoCDecorator, który posiada jedną metodę setobject(). Zauważmy, że w ten sposób możemy każdą z klas udekorować wieloma dekoratorami. Warto jeszcze zapamiętać, że zgodnie z implementacją naszego kontenera, dekorator nie może być singletonem. To znaczy: dla każdej dekorowanej klasy musi być powoływany do życia nowy dekorator. Na Listingu 3 przedstawiamy kod nowej wersji kontenera, a na Listingach 4, 5 i 6 kilka przykładowych klas pomocniczych implementujących interfejs IoCDecoratorSupport. Pierwsza klasa odnajduje klasy według pełnej nazwy, druga wg wyrażenia regularnego, a trzecia wg konkretnego interfejsu, który implementuje dekorowana klasa. Wróćmy teraz do naszego przykładu. Załóżmy dla uproszczenia, że aplikacja, w której trzeba dokonać zmian, ma trzy klasy modyfikujące dane: UserDAO, Order- DAO oraz ItemDAO. Wszystkie one implementują jeden wspólny interfejs DAO zawierający metody setconnection( find- ById( save( update( delete(). Metoda setconnection() ustawia połączenie do źródła danych, findbyid() zwraca obiekt na podstawie jego id, save() zapisuje obiekt, update() go zmienia, a delete() kasuje. Dane są modyfikowane jedynie przez metody save( update() i delete(). Szczegóły implementacji klas *DAO nie mają znaczenia w naszym przykładzie. Na Listingu 7 prezentujemy przykła- 5

5 Dla zaawansowanych Crosscutting concerns dową konfigurację kontenera bez dekoratorów. Jak widzimy, składa się ona z czterech wpisów, z których jeden dotyczy połączenia z bazą danych, a pozostałe trzy zawierają ustawienia klas DAO. Zmodyfikujemy teraz przykład tak, aby spełniał on wymagania biznesowe naszego klienta. Nic prostszego: zadanie rozpoczynamy od utworzenia klasy DAOLoggerDecorator. Klasa ta implementuje dwa interfejsy: IoCDecorator i DAO (Listing 8). Oczywiście, jej docelowa implementacja powinna zawierać bardziej wyrafinowany kod logujący. Teraz wykorzystując klasę z Listingu 6 modyfikujemy konfigurację kontenera. Nową konfigurację pokazujemy na Listingu 9. Zauważmy, że dodaliśmy tylko dwa wpisy i zgodnie z założeniami, kod klas UserDAO, Order- DAO oraz ItemDAO nie został zmieniony. W przykładzie pominęliśmy problem przekazywania informacji o tym, kto modyfikuje dane. Gdyby kod (zupełnie inny niż w naszym przykładzie) nie miał tak jasno zdefiniowanego interfejsu, jak nasze klasy DAO, do tworzenia dekoratorów moglibyśmy wykorzystać metodę call( której działanie zostało opisane w dokumentacji PHP. W podobny sposób, jak reguły związane z logowaniem, moglibyśmy dodać do aplikacji kod odnoszący się do reguł bezpieczeństwa i praw dostępu użytkow- Listing 7. Plik konfiguracji kontenera IoC dla opisanego w tekście przykładu bez wsparcia dekoratorów $currentdir = dirname( FILE ); $frameworkpath = realpath( $currentdir.'/../../flexi' ); ini_set( 'include_path', ini_get('include_path'). PATH_SEPARATOR.$frameworkPath.'/' ); require_once 'ioc/ioccontainerwithdecoratorsupport. class.php'; require_once 'ioc/mappingbuilderfromarray. class.php'; $iocmap = array( "connection" => array( "classname" => "Connection", "file" => $currentdir."/connection.class.php", "properties" => array( "userdao" => array( "classname" => "UserDAO", "file" => $currentdir."/userdao.class.php", "properties"=>array( "connection"=>"&connection" "orderdao" => array( "classname" => "OrderDAO", "file" => $currentdir."/orderdao.class.php", "properties" => array( "connection"=>"&connection" "itemdao" => array( "classname" => "ItemDAO", "file" => $currentdir."/itemdao.class.php", "properties" => array( "connection"=>"&connection" ); $mappingbuilder = new MappingBuilderFromArray($iocMap); $ioccontainer=new IoCContainerWithDecoratorSupport( $mappingbuilder->getapplicationmap()); $userdao = $ioccontainer->create("userdao"); $orderdao = $ioccontainer->create("orderdao"); $itemdao = $ioccontainer->create("itemdao"); var_dump($userdao); var_dump($orderdao); var_dump($itemdao); Listing 8. Klasa DAOLoggerDecorator jest dekoratorem klas UserDAO, OrderDAO i ItemDAO class DAOLoggerDecorator implements IoCDecorator, DAO { private $dao; public function findbyid($id){ $result = $this->dao->findbyid($id);... public function save($object){ $result = $this->dao->save($object); public function update($object){ $result = $this->dao->update($object);... public function delete($object){ $result = $this->dao->delete($object);... public function setconnection($connection){ $result = $this->dao-> setconnection($connection); public function setobject($object){ if (!$object instanceof DAO ){ throw new Exception('Class '.get_class($object). ' must implement DAO interface'); $this->dao = $object; 6

6 Crosscutting concerns Dla zaawansowanych Listing 9. Nowa wersja pliku konfiguracyjnego kontenera $currentdir = dirname( FILE ); $frameworkpath = realpath( $currentdir.'/../../flexi' ); ini_set( 'include_path', ini_get('include_path').path_separator. $frameworkpath.'/' ); require_once 'ioc/ioccontainerwithdecoratorsupport.class.php'; require_once 'ioc/mappingbuilderfromarray.class.php'; $iocmap = array( "connection" => array( "classname" => "Connection", "file" => $currentdir."/connection.class.php", "properties" => array( "userdao" => array( "classname" => "UserDAO", "file" => $currentdir."/userdao.class.php", "properties" => array("connection"=>"&connection" "orderdao" => array( "classname" => "OrderDAO", "file" => $currentdir."/orderdao.class.php", "properties" => array("connection"=>"&connection" "itemdao" => array( "classname" => "ItemDAO", "file" => $currentdir."/itemdao.class.php", "properties" => array("connection"=>"&connection" "interfaceiocdecoratorsupport" => array( "classname" => "InterfaceIoCDecoratorSupport", "file" => $frameworkpath."/ioc/decorators/interfaceiocdecoratorsupport. class.php", "properties" => array( "constructorparams" => array("daodecorator","dao") "daodecorator" => array( "classname" => "DAOLoggerDecorator", "file" => $currentdir."/daologgerdecorator.class.php", "singleton" => false, "properties" => array( ); $mappingbuilder = new MappingBuilderFromArray( $iocmap ); $ioccontainer = new IoCContainerWithDecoratorSupport( $mappingbuilder->getapplicationmap() ); $ioccontainer->setdecoratorssupport( array( $ioccontainer->create("interfaceiocdecoratorsupport"))); $userdao = $ioccontainer->create("userdao"); $orderdao = $ioccontainer->create("orderdao"); $itemdao = $ioccontainer->create("itemdao"); var_dump($userdao); var_dump($orderdao); var_dump($itemdao); ników. Wyobraźmy sobie, że klient definiuje nowy wymóg: chce, aby modyfikacji danych mogli dokonywać tylko administratorzy aplikacji. Możemy tu zastosować podobne podejście, jak przy logowaniu. Utworzymy więc klasę DAOSecutiryDecorator, która przy wywoływaniu każdej metody save( update() czy delete() będzie sprawdzała, czy wykonujący ją użytkownik ma prawa do jej użycia: jeżeli nie, aplikacja zgłosi wyjątek. Podsumowanie Stosowanie kontenera IoC i wzorca Dekorator nie jest remedium na wszelkie problemy przekrojowe. Aby wprowadzenie do kodu rzeczywistej aplikacji aspektów logowania i bezpieczeństwa było możliwe od samego początku, aplikacja ta musi mieć jasny podział na warstwy. Należy również ją tworzyć zgodnie z dobrymi praktykami programowania obiektowego, w szczególności kładąc nacisk na interfejsy i kompozycję obiektów. Warto też pamiętać, że reguły bezpieczeństwa i logowania nie są jedynymi problemami przekrojowymi: zaliczają się do nich również transakcje, profilowanie, keszowanie (caching) czy walidacja. Na szczęście i te problemy można rozwiązać przy pomocy kontenera IoC i odpowiednich dekoratorów. O autorze Piotr Szarwas ma wieloletnie doświadczenie w programowaniu i tworzeniu aplikacji WWW (PHP, Java). Jest konsultantem w jednej z największych polskich firm IT, a także doktorantem na Wydziale Fizyki Politechniki Warszawskiej. Od dawna pisze artykuły dla PHP Solutions. Kontakt z autorem: piotr.szarwas@gmail.com 7