Facade

Z PHPEdia.pl
Skocz do: nawigacji, wyszukiwania

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 najbardziej 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 a 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śleć 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.

Linki

Przewodnik po projektowaniu klas w PHP

Strona ta opisuje jeden z Wzorców projektowych.

Wzorce projektowe: Definicja | Zalety | Podział wzorców | Lista wzorców

Wiki letter w.png To jest tylko zalążek artykułu. Jeśli możesz, rozbuduj go.