WZORCE PROJEKTOWE STRUKTURALNE

WZORCE PROJEKTOWE
STRUKTURALNE
Omówimy (W6-W8):
• Decorator
• Composite
• Adapter
• Bridge
• Facade
• Proxy
WYKŁAD 6
Wzorce projektowe – strukturalne
Decorator
Composite
Structural Design Pattern: Decorator
Dynamicznie doł cza do obiektów dodatkowe
zobowi zania. Zapewnia elastyczn
alternatyw dla tworzenia podklas w celu
rozszerzania funkcjonalno ci.
Inne nazwy:
Opakowanie (Wrapper)
Uzasadnienie stosowania:
Czasami chcemy doł czy pewne
zobowi zania do niektórych obiektów a nie
całych klas. Np. dodanie ramek i pasków
przewijania do składników GUI.
Dziedziczenie jest kłopotliwe – statyczny
wybór ramki, na dodatek dla ka dego
elementu.
Lepszym rozwi zaniem jest umieszczenie
obiektu dekorowanego (element GUI)
wewn trz obiektu dekorujacego (ramka,
scrollbars).
Dekorator dostosowuje si do interfejsu
dekorowanego obiektu staj c si
prze roczystym dla klienta obiektu
dekorowanego.
Dekorator przekazuje dania do obiektu
dekorowanego i mo e wykonywa
dodatkowe operacje przed lub po
otrzymaniu dania. Prze roczysto ta
umo liwia rekurencyjne zagnie d anie
dekoratorów.
Mamy obiekt klasy WidokTekstowy wy wietlaj cy
tekst w okienku. Standardowo nie ma on
suwaków. Mo emy je doda za pomoc
DekoratorZSuwakami. Ramk mo emy doda za
pomoc DekoratoraZRamkami. Klasy
DekoratorZSuwakami i DekoratoraZRamkami s
podklasami abstrakcyjnej klasy Dekorator
reprezentuj cej komponenty wizulane, które
ozdabiaj inne komponenty wizualne.
KomponentWizualny
+komponent
Rysuj()
WidokTekstowy
Dek orator
Rysuj()
Rysuj()
komponent->Ry suj();
DekoratorZSuwakami
DekoratorZRamkami
pozycjaSuwaka
szerokoscRamki
Rysuj()
PrzewinDo()
Rysuj()
RysujRamke()
Dekorator::Rysuj();
RysujRamke();
Klasa Dekorator przesyła dania do swojego
komponentu a podklasy mog rozszerza to
działanie. Je li klient wie jaki dekorator
został wykorzystany, to mo e skorzysta z
tych rozszerze .
Stosowalno :
• dynamiczne i prze roczyste dodawanie
zobowi zania do pojedynczych obiektów
• dodanie zobowi za , które mog zosta cofni te
• niepraktyczne rozszerzanie przez podklasy –
mnóstwo niezale nych rozszerze mo e
spowodowa eksplozj hierarchii.
Struktura:
Komponent
+komponent
Operacja()
KomponentK onkretny
Dek orator
Operacja()
Operacja()
DekoratorKonkretnyA
dodanyStan
Operacja()
k omponent->Operacja();
DekoratorKonkretnyB
Operacja()
DodaneZachowanie()
Dekorator::Operacja();
DodaneZachowanie();
Uczestnicy:
• Komponent (KomponentWizualny)
– definiuje interfejs obiektów, do których
mo na dynamicznie doł cza
zobowi zania
• KomponentKonkretny (WidokTekstowy)
– definiuje obiekt, do którego mo na
doł cza dodatkowe zobowi zania
• Dekorator
– zarz dza odwołaniem do obiektu Komponent i
definiuje interfejs dopasowany do interfejsu
Komponentu
• DekoratorKonkretny (.,.)
– dodaje zobowi zania do Komponentu
Współpraca:
• Dekorator przesyła dania do swojego obiektu
Komponent. Mo e opcjonalnie wykonywa inne
operacje przed lub po przesłaniu dania
Konsekwencje:
• wi ksza elastyczno ni przy stosowaniu
statycznego dziedziczenia – runtime,
mieszanie zobowi za , wielokrotne
doł czanie wła ciwo ci (podwójna ramka)
• unikanie przeładowanych wła ciwo ciami
klas na szczycie hierarchii – koncepcja
prostej klasy na szczycie wzbogacanej w
miar potrzeb przez dekoratory
• Dekorator i jego komponent nie s
identyczne
• wiele małych obiektów – takie systemy
składaj si z wielu małych poł czonych ze
sob w skomplikowany sposób obiektów –
ich autorzy mog je bardzo łatwo zmienia ,
ale trudno je zrozumie i trudno usuwa z
nich bł dy
Implementacja:
• zgodno interfejsów obiektu dekorujacego i
dekorowanego
• pomijanie klasy abstrakcyjnej Dekorator – gdy
dodajemy tylko jedno zobowi zanie (po co
ujednolica interfejsy)
• utrzymanie lekko ci klasy Komponent – nie
powinna definiowa danych
• zmiana skóry obiektu (Decorator) a zmiana
wn trza obiektu (Strategy)
Przykłady:
Znane zastosowania:
• GUI
• strumienie IO [rys.]
Pokrewne wzorce:
Adapter – zmienia interfejs a nie tylko
zobowi zania.
Pokrewne wzorce:
• Adapter – zmienia interfejs a nie tylko
zobowi zania.
• Kompozyt. Decorator to zdegenerowany
Kompozyt z jednym komponentem.
• Strategia – zmienia wn trze obiektu, a Dekorator
zewn trze – konkurencyjny sposób zmieniania
obiektu (Strategia - gdy klasa Komponent jest
ci ka)
Structural Design Pattern: Composite
Składa obiekty w struktury drzewiaste
reprezentuj ce hierarchie typu cz -cało .
Umo liwia klientom jednakowe traktowanie
pojedynczych obiektów i zło e obiektów.
Uzasadnienie stosowania:
Aplikacje graficzne umo liwij budowanie
zło onych diagramów z mniejszych
elementów. U ytkownik mo e grupowa
mniejsze elementy w wi ksze, a te w
jeszcze wi ksze.
Problemem jest fakt, e kod w odró nieniu od
u ytkownika musi inaczej traktowa
elementy pierwotne i kontenery.
Wzorzec pokazuje jak zastosowa składanie
rekurencyjne tak aby klienci nie musieli
rozró nia elementów pierwotnych od
kontenerów.
Obiek tGraficzny
Klient
Linia
Rysuj()
Rysuj()
Dodaj( : Obiek tGraficzny)
Usun( : Obiek tGraficzny)
PodajDzieck o( : int)
Prost okat
Tekst
Rysuj()
Ry suj()
+obiekty graficzne
Rysunek
Operacja()
Dodaj( : ObiektGraficzny)
Usun( : ObiektGraficzny)
PodajDziecko( : int)
Kluczowa jest tu klasa abstrakcyjna, która
reprezentuje zarówno zarówno elementy
pierwotne jak i ich konetenery. W
przykładzie jest to klasa ObiektGraficzny.
Deklaruje ona operacje Rysuj() specyficzne
dla obiektów graficznych. Deklaruje te
operacje wspólne dla kontenerów
pozwalaj ce na manipulowanie dzie mi.
Stosowalno :
• potrzebna reprezentacja hierarchii cz cało
• wymaganie aby klienci mogli ignorowa
ró nic mi dzy zło eniami obiektów a
pojedynczymi obiektami
Komponent
Klient
Operacja()
Dodaj( : Komponent)
Usun( : Komponent)
PodajDzieck o( : int)
+dzieci
Kompozyt
Lisc
Operacja()
Operacja()
Dodaj()
Usun()
PodajDziecko()
dla ka dego og z dzieci
og.Operacja();
Uczestnicy:
• Komponent (ObiektGraficzny)
– deklaruje interfejs składanych obiektów
– implementuje, tam gdzie to mo liwe, domy lne
zachowanie w wypadku interfejsu wspólnego dla
wszystkich klas
– definiuje interfejs umo liwiaj cy dost p i zarz dzanie
komponentami- dzie mi
– czasami definiuje interfejs umo liwiaj cy dost p do
rodzica komponentu w strukturze rekurencyjnej i
implementuje go, je li jest taka potrzeba
• Lisc (Prostok t, Linia, Tekst)
– reprezentuje obiekty b d ce li mi w składanej
strukturze
– definiuje zachowanie obiektów pierwotnych w
strukturze
• Kompozyt (Rysunek)
– definiuje zachowanie komponentów maj cych dzieci
– przechowuje komponenty b d ce dzie mi
– implementuje operacje z interfejsu Komponentu
zwi zane z dzie mi
• Klient
– manipuluje obiektami wyst puj cymi w
strukturze, wykorzystuj c do tego interfejs
Komponentu
Współpraca:
• Klienci u ywaj interfejsu z klasy Komponent w
celu komunikowania si z obiektami składanej
struktury. Je li odbiorca jest li ciem, to realizuje
operacj , je li kompozytem, to przesyła dalej.
Konsekwencje:
• definiuje hierarchie klas grupuj ce obiekty
pierwotne i zło one
• upraszcza budow klienta
• ułatwia dodawanie nowych rodzajów
komponentów
• mo e sprawi , e projekt b dzie zbyt ogólny –
trudno ci z ograniczeniem rodzajów obiketów
pierwotnych (dynamiczna kontrola typów zamiast
statycznej)
Implementacja:
• jawne odwołania do rodziców – ułatwiaj
poruszanie si po strukturze i usuwanie
komponentu; pomagaj w realizacji
ChainOfResponsibility
• współdzielenie komponentów
• maksymalne powi kszenie interfejsu Komponentu
• deklarowanie operacji zarz dzania dzie mi
• uporz dkowanie dzieci – je li kolejno ma
znaczenie, to Iterator
• przechowywanie w pami ci podr cznej w
celu zwi kszenia efektywno ci
• kto powinien usuwa komponenty?
• jaka struktura danych jest najlepsza do
przechowywania komponentów
Przykłady:
Znane zastosowania:
Pokrewne wzorce:
• zwi zku komponent-rodzic u ywa si te przy
stosowaniu ChainOfResponsibility
• cz sto u ywany z Decorator
• Flywieght umo liwia współdzielenie
komponentów (ale bez referencji do rodziców)
• Iterator mo e by u ywany do
przechodzenia kompozytów
• Visitor – grupuje w jednym miejscu
operacje i zachowanie, które w przeciwnym
razie byłyby rozproszone w klasach
Kompozyt i Lisc