Facade

Z PHPEdia.pl

Spis treści

1 Fasada

Fasada

Problem

Każdy podczas tworzenia projektów, na pewnym etapie, śmiało może stwierdzić, że wszystkie klocki powoli układają się w jedną całość. Niestety owe klocki przeważnie wiążć się bardzo mocno z danym projektem. Uniemożliwia nam to wykorzystanie owych klocków na innym placu budowy, ponieważ nasze wspaniale wymodelowane pociechy, w jakiś magiczny sposób nie pasują w innej implementacji. Na ratunek przychodzi wzorzec Facade, który bardziej od innych wzorców stawia na idee niż na technikć. Fasada zakłada Udostępnianie prostych i zwartych interfejsów dla złożonych systemów. dzięki tak ćÂľuporzćdkowanemućÂť sposobie pisania, nasze klocki mogą być w łatwy sposób oderwane z jednego placu budowy i zastosowane jako solidne i sprawdzone rozwiązanie w innym projekcie.

ćÂľNie czyń drugiemu, co Tobie niemiłe ćÂ? pisząc system przeznaczony do użytku powszechnego, należy wydzielić w nim pewne warstwy. Tak jak warstwy logiki i abstrakcji aplikacji, komunikacyjne, odpowiadające za prezentację. pamiętaj! Warstwy te powinny być jak najsśabiej ze sobć powiązane. Zyskujemy tym samym na elastyczności projektu. Gdy relacja pomiędzy danymi warstwami aplikacji jest zbyt ścisła, warstwy przestają być warstwamić?ą, co prowadzi do tego, że moglibyśmy ich w ogóle nie stosować.

Fasadę jest bardzo trudno przedstawią za pomocą przykładowego kodu. Koncepcję tego wzorca jest jasna: ćÂľTwżrz pojedyncze punkty dostępu do danej warstwy aplikacjićÂť, tak, aby odwośania do docelowej jej części było skupione w jednym miejscu.

Korzyści

Przy honorowaniu Fasady w swoich projektach, zyskujemy przede wszystkim interfejs, który nie wymaga od nas wiedzy o ćÂľwnątrznościachćÂť. Używamy go zgodnie z wytycznymi, a sposób, w jaki pracuje nas nie obchodzi. dzięki temu, wdrażanie takowych składowych systemu przez osoby trzecie, jest szybkie i bezproblemowe ćÂ? warstwa działał niezależnie.

przykład (teoretyczny)

Mamy plik.txt, który zawiera jakieś dane zapisane według szablonu, oddzielone odpowiednimi znakami separującymi. Pewne funkcje odpowiadają za obróbkę dostarczanych ćÂľrekordówćÂť ćÂ? dzięki wyrażeniom regularnym (typ A), inne za samo otwarcie pliku i przesłanie surowych danych do innych funkcji (typ B). często zdarza się, że granica pomiędzy typem A i B jest niewidoczna i oba typy funkcji są od siebie uzależnione.

Według koncepcji Fasady, mechanizm B powinien być wydzielony jako warstwa, ćÂ? ponieważ można go odseparować od danej implementacji i skutecznie implikować w innych (otwieranie pliku i pobranie surowych danych wygląda zawsze tak samo ćÂ? narzędzia dostarczane przez język posiadają pewne utarte schematy ćÂ? koła drugi raz nie wymyślimy). Typ A jest w gorszej (wzglądnie) sytuacji, ćÂ? ponieważ jest cechą szczególną dla systemu (użycie jednych wyrażeś regularnych, skonstruowanych z myślć o konkretnych zadaniach, nie będzie łatwo zaimplementować w innym systemie). Przeniesienie mechanizmu obrżbki pliku do osobnej warstwy, skrytej za interfejsem - w zamian za jego honorowanie - daje nam określone korzyści, a sama implementacja typu B przestaje nas interesować ćÂ? możemy poświęcić większą uwagę typowi A ćÂ? który wykorzystuje Udostępniany interfejs.