WYKŁAD 8. Wzorce projektowe strukturalne Facade Proxy Flyweight

Transkrypt

1 WYKŁAD 8 Wzorce projektowe strukturalne Facade Proxy Flyweight

2 Structural Design Pattern: Facade Zapewnia jednolity interfejs dla podsystemu zawierajcego wiele interfejsów. Definiuje interfejs wyszego poziomu, co ułatwia korzystanie z podsystemu. Analogia do fasady budynku zzewntrz ładna i równoczenie daje dostp do wntrza.

3 Uzasadnienie: W dekompozycji systemu na podsystemy dy si m.in. do zminimalizowania komunikacji i zalenoci pomidzy podsystemami. Jedn z metod osiagnicia tego celu jest wprowadzenie obiektu fasada zapewniajcego jeden uogólniony i uproszczony interfejs do całego podsystemu.

4 Przykładowo wyobramy sobie rodowisko programistyczn zwierajce jako podsystem kompilator. Podystem ten zawiera takie klasy jak: AnalizatorLeksykalny, AnalizatorSyntaktyczny, WezelProgramu, StrumienKodowBajtowych, BudowniczyWezlowProgramu. [wzły tworzenie drzewa analizy syntaktycznej]

5 W wikszoci przypadków rodowisko programistyczne nie musi korzysta z bogatego i złoonego interfejsu tych klas. Zadanie kompilatora ogranicza si zwykle do kompilacji. Aby udostpni klientom kompilatora taki włanie interfejs dodajemy klas Kompilator, która z jednej strony wprowadza uproszczony interfejs, a z drugiej nie odcina klienta od moliwoci korzystania z bogatego interfejsu ukrytego za fasad.

6

7 Stosowalno: zamiar zapewnienia prostego interfejsu do złoonego podsystemu rozrost podsystemów jest zjawiskiem naturalnym gdy stosuje si w nich wzorce projektowe [wzrost iloci klas i złoonoci jako koszt zwikszenia ponownego uycia i zwikszenia ponownego uycia kompromisy]

8 istnieje wiele zalenocimidzy klientami abstrakcji a klasami implementujcymi warto wprowadzi fasad w celu oddzielenia podsystemu od klientów i innych podsystemów [wzrost niezalenoci podsystemów i ich przenonoci] zamiar stworzenia architektury wielowarstwowej komunikacja midzy warstwami jedynie poprzez fasady Struktura:

9

10 Uczestnicy: Fasada (Kompilator) wie jakie klasy podsystemu s odpowiedzialne za spełnienie dania przekazuje dania klienta do odpowiednich obiektów podsystemu

11 Klasy podsystemu (Skaner, Analizator, WzełProgramu) implementuj funkcje podsystemu wykonuj prac przydzielon przez obiekt klasy Facade nic nie wiedz o fasadzie, tzn. nie przechowuj adnych odwoła do niej

12 Współpraca: Klienci komunikuj si z podsystemem, wysyłajc dania do Facade, która przekazuje je do odpowiednich obiektów podsystemu. Obiekty podsystemu wykonuj właciw prac. Facade moe uczestniczy w tłumaczeniu jej własnego interfejsu na interfejsy podsystemów Klienci Facade nie musz mie dostpu do obiektów jej podsystemu

13 Konsekwencje: Zalety (istotne zastosowanie w inynierii oprogramowania) oddzielenie klientów od komponentów (?) podsystemu [wieloznaczno pojcia obiekt] moliwo uproszczenia klientów osłabia powizanie midzy podsystemami [spełnienie wanego kryterium jakoci weak-coupling (słabe powizanie?)] oraz pozostawia silne powizania pomidzy elementami podsystemu [spełnienie wanego kryterium jakoci strong-cohesion (mocne powizanie, zwarto?)] ułatwiona zmiana komponentów w sposób niewidoczny dla klienta ułatwiona budowa warstwowa systemu eliminowanie złoonych zalenoci lub circular-dependencies (zalenoci cyklicznych) ułatwienie niezalenego tworzenia podsystemów [obsługa iteracyjnoci procesu wytwórczego] zredukowanie zalenoci kompilacyjnych

14 Implementacja: zredukowanie powiza klient-podsystem moliwo dodatkowego osłabienia przez uczynienie klasy Fasade abstrakcyjn z rónymi podklasami konkretnymi dla rónych implementacji podsystemu, dziki czemu klienci nie wiedz o implementacji podsystemu, z której korzystaj, albo konfigurowanie obiektu klasy Facade za pomoc rónych obiektów podsystemu

15 publiczne a prywatne klasy podsystemu klasa kapsułkuje stan i operacje oraz ma interfejs (publiczny lub prywatny) a podsystem kapsułkuje klasy oraz ma interfejs, wic równie moe mie interfejs publiczny lub prywatny Interfejs publiczny jest dla klientów, a prywatny dla rozbudowujcych podsystem. Klasa Facade jest czci (bo podsystem moe mie wicej fasad) publicznego interfejsu podsystemu

16 Przykłady Znane zastosowania Pokrewne wzorce: Fabryka Abstrakcyjna zapewnia interfejs do tworzenia obiektów podsystemów w sposób niezaleny od podsystemów. Moe by uyty zamiast wzorca Facade wtedy ukryje klasy specyficzne dla poszczególnych platform (?)

17 Mediator podobny do Facade, bo pozwala na wyodrbnienie funkcjonalnoci istniejcych ju klas. Zadaniem wzorca Mediator jest jednak wyabstrahowanie dowolnej komunikacji midzy obiektami (jego współpracownikami), ze skupieniem funkcjonalnoci, która nie jest zwizana z adnym z nich, w jednym miejscu. Współpracownicy Mediatora wiedz o nim i komunikuj si z nim a nie midzy sob. Natomiast zadaniem Facade jest wyabstrahowanie interfejsu obiektów podsystemu dla ułatwienia ich uycia nie definiuje nowej funkcjonalnoci, a klasy podsystemu nic o niej nie wiedz. Singleton zwykle naley zagawrantowa istnienie tylko jednego obiektu Facade

18 Structural Design Pattern: Proxy Zapewnia substytut lub reprezentanta innego obiektu w celu sterowania dostpem do niego.

19 Uzasadnienie: W edytorach graficznych moemy nie chcie umieszczania od razu przy otwieraniu dokumentu całego duego i złoonego obrazka. Wolimy jego osadzenie odłoy do momentu, w którym rysunek ma si sta widoczny w okienku edytora. Jednak w dokumencie trzeba umieci co zamiast rysunku.

20 Rozwizaniem jest uycie zamiast obiektu rysunku innego obiektu pełnomocnika, który wystpuje wdokumencie zamiast docelowego obiektu. Obiekt pełnomocnika powinien zachowywa si tak jak rysunek i powinien te zaj si jego utworzeniem na danie (metoda Rysuj()). Po utworzeniu obiektu rysunku pełnomocnik zajmuje si przekazywaniem do niego da klienta (edytora).

21

22 Stosowalno: Stsouje si go wtedy, gdy do odwołania do obiektu potrzeba czego wicej ni wskanik. Typowe sytuacje: Pełnomocnik zdalny. Lokalny reprezentant obiektu znajdujcego si w innej przestrzeni adresowej. Pełnomocnik wirtualny. Tworzy kosztowne obiekty na danie (przykład podano)

23 Pełnomocnik ochraniajcy. Kontroluje dostp do oryginalnego obiektu (np. gdy obiekty maj róne prawa dostpu) Sprytne odwołanie. Zastpuje zwykły wskanik wykonujc dodatkowe akcje przy dostpie do obiektu [por. C++::STL]. Typowe zastosowania: zliczanie iloci odwoła do rzeczywistego obiektu tak by mona go było usun gdy wiadomo, e nie jest ju potrzebny [por. Java::ReferenceCounting] ładowanie trwałych obiektów do pamici przy pierwszym odwołaniu sprawdzanie czy rzeczywisty obiekt jest zablokowany przed uyciem go (np. wielowtkowo)

24

25 Uczestnicy: Pełnomocnik (PełnomocnikRysunku) przechowuje odwołanie, które umoliwia mu dostp do obiektu klasy PrawdziwyPrzedmiot; moe odwoływa si do klasy Przedmiot jeli ma ona taki sam interfejs zapewnia taki sam interfejs jak interfejs klasy Przedmiot (zastpowalno obiektów) kontroluje dostp do prawdziwego przedmiotu, w tym tworzeni i usuwanie

26 ponadto: pełnomocnicy zdalni odpowiedzialni za kodowanie da i ich argumentów oraz za wysyłanie zakodowanych da do rzeczywistych przedmiotów w innej przestrzeni adresowej pełnomocnicy wirtualni mog przechowywa w pamici podrcznej dodatkowe informacje o rzeczywistym przedmiocie, dziki czemu mog odłoy na póniej uzyskanie dostpu do niego pełnomocnicy ochraniajcy sprawdzaj czy wywołujcy ma wymagane zezwolenie na dostp

27 Przedmiot (ObiektGraficzny) definiuje wspólny interfejs dla klas PrawdziwyPrzedmiot i Pełnomocnik PrawdziwyPrzedmiot (Rysunek) definiuje rzeczywisty obiekt reprezentowany przez obiekt klasy Pełnomocnik

28 Współpraca: Pełnomocnik w zalenoci od potrzeb i rodzaju przekazuje dania do obiektu klasy PrawdziwyPrzedmiot Konsekwencje: Wprowadza poziom poredniczenia, o nastpujcych zastosowaniach: pełnomocnik zdalny moe ukry fakt umieszczenia obiektu w innej przestrzeni adresowej pełnomocnik wirtualny moe wykonywa optymalizacj pełnomocnicy ochraniajcy i sprytne odwołania umoliwiaj wykonywanie dodatkowych czynnoci porzdkowych

29 Wzorzec Pełnomocnik moe ukry przed klientem optymalizacj kopiowanie-przy-zapisywaniu. Implementacja przecianie operatora dostpu od składowych w C++ stosowanie doesnotunderstand w Smalltalk pełnomocnik nie zawsze musi zna typ prawdziwego przedmiotu

30 Przykłady Znane zastosowania Pokrewne wzorce: Adapter. Zapewnia inny interfejs do adaptowanego obiektu. Pełnomocnik natomiast zapewani taki sam interfejs jak interfejs przedmiotu. Pełnomocnik zasosowany do ochrony dostpu moe odmówi wykonania operacji jego interfejs jest podzbiorem interfejsu przedmiotu.

31 Decorator. Moe mie podobn implementacj do wzorca Proxy, ale jego przeznaczenie jest inne. Decorator dodaje co najmniej jedno zobowizanie do obiektu, a Proxy steruje dostpem do obiektu pełnomocnik ochraniajcy moe by zaimplementowany jak Decorator pełnomocnik zdalny nie zawiera bezporedniego odwołania do pzredmiotu (hostid+lokalny adres na nim) pełnomocnik wirtualny rozpoczyna działanie od poredniego odwołania, potem uzyskuje i stosuje bezporednie

32 Structural Design Pattern: Flyweight Wykoryzstuje współdzielenie obiektów w celu efektywnej obsługi wilekiej iloci drobnych obiektów.

33 Uzasadnienie: Czasami mamy sytuacje, w których musimu mie duo małych obiektów. Przykładem moe by edytor tekstu, w którym obiekty takie jak wykresy, rysunki, akapity mog (powinny) by reprezentowane jako obiekty. Jednak jeli chcielibymy reprezentowa w ten sposób znaki w celu zwikszenia elastycznoci aplikacji, to byłoby to bardzo nieefektywne (pami+czas przetwarzania).

34 Wzorzec Flyweight (pyłek) okrela takie współdzielenie obiektów, aby mona było obsługiwa znaki jako obiekty bez ponoszenia ogromnych kosztów.

35 Flyweight to współdzielony obiekt, który moe by uywany jednoczenie w wielu kontekstach. Działa jako obiekt niezaleny w kazdym kontekcie. Jest nie do odrónienia od obiektu niewspółdzielonego. Nic nie wie o kontekcie, w jakim ma by uyty. Rozróniane s stan wewntrzny (w pyłku, niezaleny od kontekstu) i stan zewntrzny (zaleny od kontekstu). Klient przekazuje stan zewntrzny do pyłku jeli potrzebny.

36 Dla przykładu edytor tekstu moe utworzy pyłek dla kadej litery alfabetu (1-1). Kady pyłek przechowuje stan wewntrzny (kod znaku). Połoenie znaku w dokumencie, styl typograficzny s okrelone na zewntrz pyłku okrelajc stan zewntrzny. Przykład moliwej realizacji takiego edytora:

37

38 Glif klasa abstrakcyjna obiektów graficznych. Wiersz wie gdzie Znaki powinny si wyrysowa aby były równo ułoone (połoenie biecego wiersza), moe te zlicza sum szerokoci swoich wczeniejszych znaków oba te parametry mog stanowi Kontekst.

39 Stosowalno: Naley go stosowa gdy spełnione s wszystkie ponisze warunki: aplikacja uywa wielkiej iloci obiektów koszty zapamitania s wysokie ze wzgldu na sam ilo obiektów wikszo stanu obiketów moe by przeniesiona na zewntrz po usuniciu stanu na zewntrz wiele grup obiektó mona zastpi stosunkowo niewielk iloci współdzielonych obiektów tosamo obiektów nie jest dla aplikacji istotna

40 Struktura:

41 Uczestnicy: Pyłek (Glif) deklaruje interfejs przez który pyłki mog otrzymywa stan zewntrzny i działa zgodnie z nim PyłekKonkretny (Znak) implementuje interfejs pyłku i ew. przechowuje stan wewntrzny musi dawa si współdzieli

42 NiewspółdzielonyPyłekKonkretny (Wiersz, Łam) czsto PyłkiKonkretne s dziemi obiektów klasy NiewspółdzielonyPyłekKonkretny FabtykaPyłków tworzy obiekty klasy Pyłek i zarzdza nimi zapewnia właciwe współdzielenie pyłków Klient utrzymuje odwołania do pyłków wylicza lub przechowuje stan zewntrzny pyłków

43 Współpraca: Klienci musz zna stan zewntrzny, aby mogli przekaza go do obiektów klasy PyłekKonkretny Klienci nie powinni zajmowa si tworzeniem obiektów klasy PyłekKonkretny obsług współdzielenia zajmuje si FabrykaPyłków

44 Konsekwencje: Zysk na pamici kosztem spowolnienia aplikacji zaleny od: zmniejszenia łcznej iloci obiektów wynikajcego ze współdzielenia wielkoci stanu wewntrznego obiektu tego czy stan zewntrzny jest wyliczany czy przechowywany

45 Implementacja: usuwanie stanu zewntrznego ma sens gdy mona go przenie (wyliczy) do znacznie mniejszej iloci obiektów zarzdzanie współdzielonymi obiektami FabrykaPyłków czsto uywa pamici asocjacyjnej pyłki warto przechowywa w pamici gdy jest ich stosunkowo niewiele a zlicza odwołania lub odmieca gdy jest ich duo a nie s ju potrzebne

46 Przykłady Znane zastosowania Pokrewne wzorce: Composite czsto łczony z wzorcem Flyweight w celu zaimplementowania logicznie hierarchicznej struktury w kategoriach acyklicznego grafu skierowanego ze współdzielonymi wzłami-limi State, Strategy czsto najlepszym wyjciem jest zaimplementowanie ich jako Flyweights

47 WZORCE PROJEKTOWE CZYNNOCIOWE Omówimy (W9-W11): Observer Visitor Command Strategy Iterator TemplateMethod