Bartosz Walter
Wzorce projektowe
1
In
ż
ynieria oprogramowania
Wzorce projektowe
Prowadz
ą
cy:
Bartosz Walter
Bartosz Walter
Wzorce projektowe
2
In
ż
ynieria oprogramowania
Wzorce projektowe (2)
Agenda
1. Geneza wzorców
2. Banda Czterech i katalog wzorców projektowych
3. Wybrane wzorce projektowe i ich zastosowanie
Wykład b
ę
dzie po
ś
wi
ę
cony przegl
ą
dowi zagadnie
ń
zwi
ą
zanych z
wzorcami projektowymi. Omówiona zostanie geneza wzorców oraz wpływ
tzw. Bandy Czterech na ich powstanie i ewolucj
ę
. Główn
ą
cz
ęść
wykładu
b
ę
dzie prezentacja wybranych wzorców i ich zastosowa
ń
na przykładzie
systemu bibliotecznego.
Bartosz Walter
Wzorce projektowe
3
In
ż
ynieria oprogramowania
Wzorce projektowe (3)
Motywacja
• Czy odpowiedzi na powtarzaj
ą
ce si
ę
pytania mo
ż
na
przedstawi
ć
w sposób ogólny, tak aby były pomocne w
tworzeniu rozwi
ą
za
ń
w ró
ż
nych konkretnych
kontekstach?
• Czy jako
ść
projektu mo
ż
na opisa
ć
w kategoriach
powtarzalnych rozwi
ą
za
ń
, bez konieczno
ś
ci ci
ą
głego
"wynajdywania koła"?
D
ąż
enie do jednolito
ś
ci rozwi
ą
za
ń
, ich klasyfikacji i uproszczenia,
pojawiaj
ą
w wielu dziedzinach in
ż
ynierii. Podstawowe pytanie, jakie
stawiaj
ą
sobie in
ż
ynierowie, dotyczy mo
ż
liwo
ś
ci wielokrotnego
wykorzystania raz sformułowanego rozwi
ą
zania danego problemu. Czy
mo
ż
na zapisa
ć
to rozwi
ą
zanie w sposób ogólny, abstrahuj
ą
c od
szczegółowych rozwi
ą
za
ń
? Pozwoliłoby uj
ąć
tzw. dobre praktyki w postaci
szablonów, które mo
ż
na stosowa
ć
wielokrotnie, unikaj
ą
c typowych
bł
ę
dów.
Bartosz Walter
Wzorce projektowe
4
In
ż
ynieria oprogramowania
Wzorce projektowe (4)
Geneza wzorców
Wzorzec to sprawdzona koncepcja, która opisuje
problem
powtarzaj
ą
cy si
ę
wielokrotnie
w okre
ś
lonym
kontek
ś
cie
, działaj
ą
ce na niego
siły
, oraz podaje
istot
ę
jego rozwi
ą
zania
w sposób abstrakcyjny”
Christopher Alexander
Wzorce projektowe, cho
ć
obecnie znane przede wszystkim w kontek
ś
cie
in
ż
ynierii oprogramowania, wywodz
ą
si
ę
z architektury. Twórc
ą
tego
poj
ę
cia był ameryka
ń
ski architekt, Christopher Alexander, który postawił
tez
ę
,
ż
e pi
ę
kno, funkcjonalno
ść
oraz inne cechy u
ż
ytkowe lub
konstrukcyjne mo
ż
na zapisa
ć
wła
ś
nie w postaci uogólnionych rozwi
ą
za
ń
.
Wzorce opisane przez Alexandra powstały na podstawie analizy decyzji
podejmowanych przez architektów i budowniczych, którzy usiłowali
osi
ą
gn
ąć
okre
ś
lony efekt, z ich do
ś
wiadcze
ń
, bł
ę
dów i odkry
ć
.
Zdaniem Aleksandra, ka
ż
dy wzorzec powinien by
ć
opisany przez
nast
ę
puj
ą
ce atrybuty:
•układ sił działaj
ą
cych na niego – czyli
ś
rodowisko i jego wpływ
•rozwi
ą
zanie – schemat konstrukcji, która uwzgl
ę
dnia działaj
ą
ce siły,
równowa
ż
y je i oferuje najlepsze osi
ą
gni
ę
cie celu przy zało
ż
onych
czynnikach
•kontekst - opis warunków, w których rozwi
ą
zanie mo
ż
na zastosowa
ć
.
Taki wzorzec jest gotowym schematem post
ę
powania, który mo
ż
na
zastosowa
ć
w wielu sytuacjach, ł
ą
cz
ą
c go tak
ż
e z innymi wzorcami.
Wprawdzie idee Alexandra nie odbiły si
ę
szerokim echem w
ś
wiecie
architektury, jednak stanowiły silny impuls dla rozwoju technik
projektowania oprogramowania.
Bartosz Walter
Wzorce projektowe
5
In
ż
ynieria oprogramowania
Wzorce projektowe (5)
Wzorce w architekturze
Czy zbudowa
ć
most,
opieraj
ą
c prz
ę
sło na
kolejnych filarach poł
ą
czonych łukiem, tak
aby łuk usztywniał prz
ę
sło, stanowi
ą
c jego
podparcie na całej długo
ś
ci prz
ę
sła
,
czy te
ż
mocuj
ą
c prz
ę
sło z obu stron za
pomoc
ą
lin stalowych o kolejno coraz
krótszych długo
ś
ciach do pylonów
umieszczonych po
ś
rodku długo
ś
ci mostu
?
Aby przybli
ż
y
ć
poj
ę
cie wzorca, przyjrzyjmy si
ę
dylematowi projektanta
budowlanego, który zastanawia si
ę
nad wyborem konstrukcji mostu lub
wiaduktu. Z ka
ż
dym rozwi
ą
zaniem zwi
ą
zane s
ą
pewne wymagania
wst
ę
pne, dotycz
ą
ce np. no
ś
no
ś
ci gruntu, uwarunkowania konstrukcyjne,
wpływaj
ą
ce na koszt konstrukcji i konsekwencje, m.in. osi
ą
gni
ę
ta
no
ś
no
ść
, konieczno
ść
konserwacji etc. Analiza ka
ż
dej konstrukcji oraz
wyra
ż
enie jej w sposób opisowy jest mo
ż
liwe, ale do
ść
skomplikowane i
nara
ż
one na niedomówienia. Trzeba bowiem za ka
ż
dym razem na nowo
przemy
ś
le
ć
poszczególne elementy projektu, uwzgl
ę
dni
ć
zadania, jakie
stoj
ą
przed projektowan
ą
budowl
ą
, warunki klimatyczne etc.
Bartosz Walter
Wzorce projektowe
6
In
ż
ynieria oprogramowania
Wzorce projektowe (6)
Wzorce w architekturze
Czy zbudowa
ć
most łukowy
czy
podwieszany
?
Dlatego łatwiejsze jest posługiwanie si
ę
wzorcem, który uwzgl
ę
dnia
wszystkie te elementy i natychmiast nasuwa skojarzenie dotycz
ą
ce
wszystkich pozostałych wła
ś
ciwo
ś
ci projektu. Zatem u
ż
ycie nazwy mostu
łukowego czy podwieszanego jest swego rodzaju wzorcem, mówi
ą
cym
kiedy, jak i przy jakich ograniczeniach mo
ż
na wybudowa
ć
dan
ą
konstrukcj
ę
.
Bartosz Walter
Wzorce projektowe
7
In
ż
ynieria oprogramowania
Wzorce projektowe (7)
Banda Czterech (Gang of Four)
E. Gamma, R. Helm, R. Johnson, J. Vlissides (1994)
Wzorzec projektowy
identyfikuje i
opisuje pewn
ą
abstrakcj
ę
, której
poziom znajduje si
ę
powy
ż
ej poziomu
abstrakcji pojedynczej klasy, instancji
lub komponentu
.
Autorami pierwszej szeroko znanej publikacji po
ś
wi
ę
conej wzorcom w
in
ż
ynierii oprogramowania byli E. Gamma, R. Helm, R.Johnson i J.
Vlissides, znani jako Banda Czterech (Gang of Four) – w bli
ż
ej
niesprecyzowanym nawi
ą
zaniu do nazwy grupy dawnych prominentów w
komunistycznych Chinach. W swojej ksi
ąż
ce opisali 24 wzorce projektowe
dotycz
ą
ce konstrukcji, struktury i zachowania obiektów w systemach
informatycznych. Ich zdaniem, poziom abstrakcji wzorca projektowego
powinien znajdowa
ć
si
ę
powy
ż
ej poziomu pojedynczej klasy.
Od tego czasu wzorce projektowe stały si
ę
jednym z podstawowych
narz
ę
dzi projektowania systemów. Powstały nowe, specjalizowane
wzorce po
ś
wi
ę
cone rozwi
ą
zaniom dla konkretnych technologii czy
platform (np. wzorce dla J2EE).
Bartosz Walter
Wzorce projektowe
8
In
ż
ynieria oprogramowania
Wzorce projektowe (8)
Wzorce w in
ż
ynierii oprogramowania
Wzorce w in
ż
ynierii oprogramowania
• wzorce architektoniczne
– poziom integracji
komponentów
• wzorce projektowe
– poziom interakcji mi
ę
dzy klasami
• wzorce analityczne
– poziom opisu rzeczywisto
ś
ci
• wzorce implementacyjne
– poziom j
ę
zyka
programowania
Od tego momentu obserwuje si
ę
w in
ż
ynierii oprogramowania dynamiczny
rozwój wzorców na ró
ż
nych obszarach rozwoju oprogramowania, przede
wszystkim na poziomie architektury, testowania, analizy i implementacji
oprogramowania. Pozwalaj
ą
one unika
ć
powszechnych bł
ę
dów i stosowa
ć
tzw. najlepsze praktyki w zasadzie w ka
ż
dej dziedzinie zwi
ą
zanej z
oprogramowaniem.
Bartosz Walter
Wzorce projektowe
9
In
ż
ynieria oprogramowania
Wzorce projektowe (9)
Podział wzorców projektowych
Kreacyjne
opisują elastyczne sposoby tworzenia obiektów
uniezależniają system od sposobu tworzenia obekt
Behawioralne
opisują algorytmy i przydział odpowiedzialności
charakteryzują sposób interakcji między obiektami
Strukturalne
opisują sposób konstrukcji struktur obiektowych
korzystają z dziedziczenia i delegacji
Banda Czterech zaproponowała podstawow
ą
systematyk
ę
wzorców,
dziel
ą
c je na trzy kategorie:
•wzorców kreacyjnych, które dotycz
ą
sposobów tworzenia obiektów,
skupiaj
ą
c si
ę
na abstrakcji i hermetyzacji tego procesu
•wzorców strukturalny, opisuj
ą
cych sposób konstrukcji struktur
obiektowych, ł
ą
czenia ze sob
ą
obiektów i zarz
ą
dzania nimi, oraz
•wzorców behawioralnych, skupiaj
ą
cych si
ę
na opisie algorytmów,
podziale odpowiedzialno
ś
ci pomi
ę
dzy obiekty oraz charakterystyce
interakcji pomi
ę
dzy nimi.
Bartosz Walter
Wzorce projektowe
10
In
ż
ynieria oprogramowania
Wzorce projektowe (10)
Szablon wzorca projektowego
Atrybuty wzorca
• nazwa
–
lakoniczny opis istoty wzorca
• klasyfikacja
–
kategoria, do której
wzorzec nale
ż
y
• cel
–
przeznaczenie wzorca
• aliasy
–
alternatywne nazwy wzorca
• motywacja
–
scenariusz opisuj
ą
cy
problem i rozwi
ą
zanie
• zastosowania
–
sytuacje, w których
wzorzec jest stosowany
• struktura
–
graficzna reprezentacja klas
składowych wzorca
Gamma et al., 1995
Wzorzec
Wzorzec
• nazwa
• klasyfikacja
• cel
• aliasy
• motywacja
• zastosowania
• struktura
Ka
ż
dy wzorzec nale
żą
cy do katalogu zaproponowanego przez „Band
ę
Czterech” opisany jest przez zestaw atrybutów, dzi
ę
ki którym jego
wła
ś
ciwo
ś
ci s
ą
przedstawione w usystematyzowany, powtarzalny i
obiektywny sposób. W ten sposób powstał szablon wzorca projektowego.
Po kolei omówione zostan
ą
pokrótce najwa
ż
niejsze jego atrybuty.
Nazwa wzorca jest dobrana tak, aby szybko nasuwa
ć
skojarzenia z
przeznaczeniem wzorca. Nazwy oryginalnie zostały sformułowane po
angielsku, i tak te
ż
b
ę
d
ą
podawane w trakcie wykładu. Stosowanie
spójnego, angloj
ę
zycznego nazewnictwa ułatwia komunikacj
ę
, dlatego
pomijanie polskich tłumacze
ń
(cho
ć
w niektórych przypadkach naturalnych
i nie powoduj
ą
cych wieloznaczno
ś
ci) wydaje si
ę
uzasadnione.
Cel wzorca krótko opisuje ostateczny skutek jego zastosowania.
Bardzo wa
ż
nym elementem jest opis struktury wzorca, przede wszystkim
w zakresie powi
ą
za
ń
pomi
ę
dzy uczestnicz
ą
cymi w nim klasami w postaci
diagramu klas UML. Aspekt dynamiczny (zachowanie poszczególnych
uczestników wzorca) opisywany jest w atrybucie dotycz
ą
cym
współdziałania.
Bartosz Walter
Wzorce projektowe
11
In
ż
ynieria oprogramowania
Wzorce projektowe (11)
Szablon wzorca projektowego (cd.)
za Gang of Four
Wzorzec
Wzorzec
• uczestnicy
• kolaboracje
• konsekwencje
• implementacja
• przykład
• wzorce pokrewne
Atrybuty wzorca (cd.)
• uczestnicy
–
nazwy i zakres
odpowiedzialno
ś
ci uczestników wzorca
• współdziałania
–
opis współpracy
mi
ę
dzy uczestnikami
• konsekwencje
–
efekty zastosowania
wzorca
• implementacja
–
opis implementacji
wzorca w danym j
ę
zyku
• przykład
–
kod stosuj
ą
cy wzorzec
• pokrewne wzorce
–
wzorce u
ż
ywane w
podobnym kontek
ś
cie
Lista uczestników wzorca zawiera nie tylko nazwy ról klas wchodz
ą
cych w
jego skład, ale przede wszystkim zakres ich odpowiedzialno
ś
ci oraz
sposób zachowania. Jest to uszczegółowienie informacji, które s
ą
umieszczone na diagramie struktury.
Cz
ę
sto pomijan
ą
, cho
ć
bardzo wa
ż
n
ą
, składow
ą
ka
ż
dego wzorca jest
informacja o konsekwencjach, jakie niesie jego zastosowanie, szczególnie
negatywnych. Wykorzystanie wzorca cz
ę
sto wymusza podejmowanie
okre
ś
lonych decyzji w przyszło
ś
ci i wyklucza niektóre rozwi
ą
zania, dlatego
projektant powinien by
ć
ś
wiadomy ich zwi
ą
zków z tym wzorcem.
Przykład pozwala lepiej zrozumie
ć
charakter, przeznaczenie i struktur
ę
wzorca.
Je
ż
eli wzorzec jest spokrewniony z innymi, przede wszystkim pod
wzgl
ę
dem kontekstu oraz celu stosowania, wówczas s
ą
one wymienione
jako wzorce pokrewne.
Bartosz Walter
Wzorce projektowe
12
In
ż
ynieria oprogramowania
Wzorce projektowe (12)
Biblioteka
Katalogi
Katalogi
Karty czytelników
Karty czytelników
Karty ksi
ąż
ek
Karty ksi
ąż
ek
Kontakt
z czytelnikiem
Kontakt
z czytelnikiem
W celu lepszego przedstawienia idei wzorców, wybrane wzorce zostan
ą
omówione na przykładzie projektu oprogramowania dla biblioteki. System
taki składa si
ę
z rozmaitych modułów i realizuje ró
ż
ne funkcje, które nie s
ą
interesuj
ą
ce z punktu widzenia jako
ś
ci projektu. Dlatego dla potrzeb
przykładu zostanie on ograniczony do czterech odułów, spo
ś
ród których
opisane zostan
ą
wybrane problemy i sposoby ich rozwi
ą
zania w oparciu o
wzorce.
Te cztery moduły w systemie bibliotecznym to:
•katalogi, przechowuj
ą
ce informacje o zbiorach biblioteki, i porz
ą
dkuj
ą
ce
je według wybranego kryterium;
•karty czytelników, słu
żą
ce do przechowywania danych o czytelnikach: ich
danych osobowych, historii rezerwacji, wypo
ż
ycze
ń
etc.;
•karty ksi
ąż
ek, które reprezentuj
ą
poszczególne egzemplarze ksi
ąż
ki i s
ą
przechowywane w katalogach;
•mechanizm kontaktu z czytelnikiem, pozwalaj
ą
cy dowiadywa
ć
si
ę
o
stanie rezerwacji, nowo
ś
ciach w bibliotece etc.
Bartosz Walter
Wzorce projektowe
13
In
ż
ynieria oprogramowania
Wzorce projektowe (13)
Biblioteka
Katalogi
Katalogi
Karty czytelników
Karty czytelników
Karty ksi
ąż
ek
Karty ksi
ąż
ek
Kontakt
z czytelnikiem
Kontakt
z czytelnikiem
Pierwszym modułem jest system katalogów i przechowywania w nich
informacji. Słu
ż
y on przede wszystkim celom informacyjnym, a
najwa
ż
niejsz
ą
oferowan
ą
przez niego funkcj
ą
jest wyszukiwanie ksi
ąż
ek
wg. ró
ż
nych kryteriów.
Bartosz Walter
Wzorce projektowe
14
In
ż
ynieria oprogramowania
Wzorce projektowe (14)
Katalogi
• Informacje o ksi
ąż
kach s
ą
przechowywane w
katalogach:
autorskim
,
alfabetycznym
i
rzeczowym
.
• Katalog rzeczowy
jest nieograniczon
ą
hierarchiczn
ą
struktur
ą
drzewiast
ą
zło
ż
on
ą
z kategorii
W bibliotece istniej
ą
trzy rodzaje katalogu: autorski, alfabetyczny i
rzeczowy. Wszystkie katalogi przechowuj
ą
t
ę
sam
ą
informacj
ę
, jednak
uporz
ą
dkowan
ą
według innego kryterium. Struktura katalogów
autorskiego i alfabetycznego jest intuicyjnie zrozumiała, dlatego przede
wszystkim warto skupi
ć
si
ę
na katalogu rzeczowym. Definiuje on
drzewiast
ą
struktur
ę
hierarchiczn
ą
zbudowan
ą
z kategorii, w których
zgrupowane s
ą
ksi
ąż
ki o podobnej tematyce. Ka
ż
da ksi
ąż
ka jest
przypisana w danym momencie tylko do jednej kategorii, jednak mo
ż
na
(teoretycznie) przypisanie to zmieni
ć
. Katalog rzeczowy, mimo znacznie
bardziej zło
ż
onej struktury, posiada te same cechy funkcjonalne co
pozostałe katalogi: mo
ż
na w nim wyszuka
ć
ksi
ąż
k
ę
oraz j
ą
doda
ć
do
katalogu.
Bartosz Walter
Wzorce projektowe
15
In
ż
ynieria oprogramowania
Wzorce projektowe (15)
Problem 1: Katalog rzeczowy
Katalog rzeczowy: wymagania
• struktura hierarchiczna kategorii oznaczonych cyframi
• nieograniczone mo
ż
liwo
ś
ci rozwoju
• łatwo
ść
wyszukiwania
• mo
ż
liwo
ść
zmiany poło
ż
enia ksi
ąż
ki
1. Nauki
ś
cisłe
1.1 Matematyka
1.2 Fizyka
1.1.1 Geometria
1.1.2 Algebra
Przykład dotyczy wła
ś
nie katalogu rzeczowego. Wobec niego postawione
s
ą
nast
ę
puj
ą
ce wymagania:
•ma reprezentowa
ć
hierarchiczn
ą
struktur
ę
kategorii opisywanych w
notacji cyfrowej (np. kategoria 1. Nauki
ś
cisłe zawiera kategorie 1.1
Matematyka i 1.2 Fizyka, a z kolei ta pierwsza kategoria posiada
podkategorie 1.1.1 Geometria i 1.1.2 Algebra);
•musi posiada
ć
te same własno
ś
ci funkcjonalne co inne katalogi: prosty
system wyszukiwania i innych funkcji zarz
ą
dczych;
•musi posiada
ć
mo
ż
liwo
ść
nieograniczonego rozwoju; rozmiar struktury
nie mo
ż
e rzutowa
ć
na sposób wyszukiwania w niej informacji (cho
ć
mo
ż
e,
oczywi
ś
cie, mie
ć
wpływ na wydajno
ść
tego procesu).
Bartosz Walter
Wzorce projektowe
16
In
ż
ynieria oprogramowania
Wzorce projektowe (16)
Rozwi
ą
zanie: drzewo
Wady i zalety:
• umo
ż
liwia jednolite zarz
ą
dzanie struktur
ą
(np.
przeszukiwanie)
• umo
ż
liwia zmian
ę
poło
ż
enia obiektu
Ksi
ąż
ka
szukaj()
Przeszukiwal
ny
szukaj()
K atalog rzeczowy
znajd
ź
()
Kategoria
szukaj()
+zawiera
Naturalne rozwi
ą
zanie polega na stworzeniu wspólnego interfejsu, np. o
nazwie Przeszukiwalny, który jest implementowany we wszystkich
obiektach, które s
ą
cz
ęś
ci
ą
struktury i w których mo
ż
na szuka
ć
ksi
ąż
ek.
Interfejs ten posiada dwie implementacje: Kategori
ę
(która jest zwi
ą
zana
relacj
ą
agregacji z dowoln
ą
liczb
ą
obiektów zale
ż
nych typu
Przeszukiwalny, a zatem zarówno innych Kategorii, jak i Ksi
ąż
ek) oraz
Ksi
ąż
k
ę
(reprezentuj
ą
c
ą
element struktury, który nie posiada obiektów
zale
ż
nych).
Obiekt klasy Katalog rzeczowy, który wywoła metod
ę
szukaj() w kategorii
znajduj
ą
cej si
ę
w korzeniu drzewa katalogu, nie musi zna
ć
struktury tego
drzewa, jego gł
ę
boko
ś
ci ani innych własno
ś
ci. Ka
ż
da Kategoria, po
wywołaniu jej metody szukaj(), realizuje ten sam algorytm: wykonuje
wyszukiwanie na własnym obiekcie, a nast
ę
pnie wywołuje t
ę
sam
ą
metod
ę
na ka
ż
dym jej obiekcie zale
ż
nym, co powoduje rekurencyjne
przeszukanie drzewa w gł
ą
b.
Takie rozwi
ą
zanie umo
ż
liwia, zgodnie z podanymi wcze
ś
niej
wymaganiami, jednolity sposób wyszukiwania, minimalizuj
ą
cy wiedz
ę
,
jak
ą
o strukturze danych powinien posiada
ć
klient. Mo
ż
liwe jest tak
ż
e
przeniesienie Ksi
ąż
ki z jednej Kategorii do innej w trakcie działania
systemu (co nie byłoby mo
ż
liwe w niektórych rozwi
ą
zaniach, np.
zwi
ą
zanych z dziedziczeniem).
Bartosz Walter
Wzorce projektowe
17
In
ż
ynieria oprogramowania
Wzorce projektowe (17)
Wzorzec Composite
Komponent
Kompozyt
Li
ść
Ksi
ąż
ka
szukaj()
Przeszukiwal
ny
szukaj()
K atalog rzeczowy
znajd
ź
()
Kategoria
szukaj()
+zawiera
Przedstawione rozwi
ą
zanie jest oparte w cało
ś
ci na jednym z wzorców
projektowych o nazwie Composite. Posługuje si
ę
on nazwami
uczestników opisuj
ą
cymi ich role w tym wzorcu, co pozwala łatwo
stosowa
ć
go w innych sytuacjach. Klasa Kategoria jest nazywana w nim
Kompozytem (czyli obiektem zło
ż
onym z innych komponentów), interfejs
Przeszukiwalny – Komponentem (czyli dowolnym elementem struktury,
który mo
ż
na przeszukiwa
ć
), natomiast Ksi
ąż
ka jest Li
ś
ciem drzewa
(obiektem, który nie posiada obiektów zale
ż
nych)
Bartosz Walter
Wzorce projektowe
18
In
ż
ynieria oprogramowania
Wzorce projektowe (18)
Wzorzec Composite: uczestnicy
• Komponent
– deklaruje wspólny interfejs dla obiektów znajduj
ą
cych
si
ę
strukturze
– implementuje wspóln
ą
funkcjonalno
ść
wszystkich
obiektów
• Li
ść
– reprezentuje w
ę
zeł bez potomków
• Kompozyt
– reprezentuje w
ę
zeł z potomkami
– przechowuje referencje do potomków
– deleguje otrzymane polecenia do potomków
We wzorcu uczestnicz
ą
trzy klasy. Komponent, podstawowy element
wzorca, deklaruje wspólny interfejs dla wszystkich elementów struktury.
Jego implementacje, Li
ść
i Kompozyt, reprezentuj
ą
odpowiednio w
ę
zły
bez potomków i w
ę
zły po
ś
rednie.
Bartosz Walter
Wzorce projektowe
19
In
ż
ynieria oprogramowania
Wzorce projektowe (19)
Wzorzec Composite: konsekwencje
• Elastyczna definicja struktur drzewiastych
• Proste dodawanie nowych komponentów
• Proste i spójne zarz
ą
dzanie struktur
ą
o dowolnej liczbie
elementów
Wzorzec okre
ś
la metod
ę
konstrukcji hierarchicznych struktur, którymi
mo
ż
na zarz
ą
dza
ć
poprzez jeden w
ę
zeł – korze
ń
. Dzi
ę
ki temu podstawowe
operacje, takie jak wyszukiwanie elementów, nie wymagaj
ą
ż
adnej wiedzy
o strukturze drzewa.
Popularno
ść
tego wzorca wynika z oferowanej przez niego mo
ż
liwo
ś
ci
elastycznego zarz
ą
dzania zło
ż
onymi strukturami. Ponadto wszystkie
elementy struktury realizuj
ą
ten sam algorytm, co ułatwia ich testowanie.
Mechanizm ten jest jednym z najcz
ęś
ciej wykorzystywanych wzorców
projektowych, np. w systemach okienkowych. Struktur
ę
drzewiast
ą
tworz
ą
wówczas składowe okienek: przyciski, etykiety, listy etc. Przesuni
ę
cie
okienka na ekranie powoduje automatyczne przesuni
ę
cie wszystkich jego
elementów.
Bartosz Walter
Wzorce projektowe
20
In
ż
ynieria oprogramowania
Wzorce projektowe (20)
Biblioteka
Katalogi
Katalogi
Karty czytelników
Karty czytelników
Karty ksi
ąż
ek
Karty ksi
ąż
ek
Kontakt
z czytelnikiem
Kontakt
z czytelnikiem
Kolejnym podsystemem biblioteki jest moduł odpowiedzialny za
zarz
ą
dzanie kartami czytelników. Przechowuj
ą
one podstawowe
informacje o ka
ż
dym z u
ż
ytkowników biblioteki (imi
ę
, nazwisko, telefon),
jak równie
ż
histori
ę
rezerwacji i dokonanych przez niego wypo
ż
ycze
ń
.
Bartosz Walter
Wzorce projektowe
21
In
ż
ynieria oprogramowania
Wzorce projektowe (21)
Karty czytelników
Istniej
ą
trzy typy kart czytelnika:
Junior
,
Standard
i
Senior
.
Typ karty okre
ś
la m.in. wysoko
ść
opłaty za korzystanie z
biblioteki i wysoko
ś
ci kar za nieterminowy zwrot ksi
ąż
ek.
Karty biblioteczne funkcjonuj
ą
ce w bibliotece dziel
ą
si
ę
na trzy kategorie:
karty Junior, karty Standard i karty Senior. Rodzaj karty jest zwi
ą
zany z
wiekiem jej wła
ś
ciciela i warunkuje sposób wykonania niektórych operacji,
np. wysoko
ść
opłat zwi
ą
zanych z korzystaniem z biblioteki czy opłat
karnych. Co wa
ż
ne, karta czytelnika mo
ż
e zmieni
ć
swój typ w trakcie
istnienia obiektu (dziecko z kart
ą
Junior po uko
ń
czeniu pewnego wieku
automatycznie jest traktowane jako dorosły z kart
ą
Standard) i nie
wymaga modyfikacji ani wymiany karty.
Bartosz Walter
Wzorce projektowe
22
In
ż
ynieria oprogramowania
Wzorce projektowe (22)
Problem 2: Typy kart czytelnika
Typy kart czytelnika: wymagania
• istniej
ą
trzy rodzaje kart czytelnika: Standard, Junior i
Senior
• karta mo
ż
e zmienia
ć
swój typ
• typ karty okre
ś
la zachowanie karty czytelnika
KartaJunior
oplataRoczna()
oplataKarna()
KartaStandard
oplataRoczna()
oplataKarna()
KartaSenior
oplataRoczna()
oplataKarna()
W tym punkcie zajmiemy si
ę
wła
ś
nie problemem zaprojektowania
systemu kart czytelnika.
Wymagania wobec nich s
ą
nast
ę
puj
ą
ce:
•istniej
ą
trzy rodzaje kart, lecz liczba ta mo
ż
e ulec zmianie w przyszło
ś
ci;
•typ karty mo
ż
e ulec zmianie bez konieczno
ś
ci zmiany samej karty;
•typ karty ma wpływ na sposób, w jaki s
ą
wykonywane niektóre metody
klasy Karta.
Bartosz Walter
Wzorce projektowe
23
In
ż
ynieria oprogramowania
Wzorce projektowe (23)
Rozwi
ą
zanie 1: podklasy
Wady i zalety:
• pozwalaj
ą
na dziedziczenie metod i ich pokrywanie
• uniemo
ż
liwiaj
ą
zmian
ę
typu karty
Karta czytelnika
oplataRoczna()
oplataKarna()
KartaJunior
oplataRoczna()
oplataKarna()
KartaStandard
oplataRoczna()
oplataKarna()
KartaSenior
oplataRoczna()
oplataKarna()
Pierwsze, niemal intuicyjne rozwi
ą
zanie polega na utworzeniu podklas
reprezentuj
ą
cych rodzaje kart. Podklasy dziedzicz
ą
wspólne atrybuty i
zachowanie po nadklasie stanowi
ą
cej ogóln
ą
Kart
ę
Czytelnika, definiuj
ą
c
jednak własny sposób wykonania niektórych metod (np. opłataRoczna() i
opłataKarna()). Z punktu widzenia zachowania programu jest to zatem
rozwi
ą
zanie poprawne, które jednocze
ś
nie promuje ponowne u
ż
ycie kodu
poprzez wykorzystanie dziedziczenia.
Jednak stworzenie niezale
ż
nych klas uniemo
ż
liwia zmian
ę
typu karty bez
rekompilacji kodu. To oznacza,
ż
e zmiana typu karty Junior na Standard
wi
ą
załaby si
ę
z usuni
ę
ciem jednego obiektu i utworzeniem drugiego
poprzez przepisanie jego atrybutów. Dlatego to rozwi
ą
zanie w cało
ś
ci jest
nie do zaakceptowania.
Bartosz Walter
Wzorce projektowe
24
In
ż
ynieria oprogramowania
Wzorce projektowe (24)
Rozwi
ą
zanie 2: delegacja
Wady i zalety:
• podział odpowiedzialno
ś
ci mi
ę
dzy sam obiekt i jego typ
• powtórne u
ż
ycie kodu dzi
ę
ki wykorzystaniu dziedziczenia
• mo
ż
liwa zmiana typu karty bez zmiany samej karty
KartaJunior
oplataRoczna()
oplataKarna()
KartaStandard
oplataRoczna()
oplataKarna()
KartaSenior
oplataRoczna()
oplataKarna()
KartaCzytelnika
numer : String
imie : String
nazwisko : String
TypKarty
oplataRoczna()
oplataKarna()
Drugie rozwi
ą
zanie polega na rozdzieleniu odpowiedzialno
ś
ci Karty
Czytelnika na cz
ęść
przechowuj
ą
c
ą
dane i cz
ęść
reprezentuj
ą
c
ą
stan.
Cz
ęść
przechowuj
ą
ca dane, nadal nazywana Kart
ą
Czytelnika, posiada
referencj
ę
do obiektu reprezentuj
ą
cego aktualny typ, dziedzicz
ą
cego po
klasie abstrakcyjnej lub implementuj
ą
cej interfejs. Dzi
ę
ki temu zmiana
typu wymaga jedynie utworzenia instancji innej klasy Typ Karty i
przypisanie jej do Karty Czytelnika.
Efektem takiego projektu jest czytelniejszy podział odpowiedzialno
ś
ci,
który jednocze
ś
nie posiada zalety brakuj
ą
ce w poprzednim rozwi
ą
zaniu.
Bartosz Walter
Wzorce projektowe
25
In
ż
ynieria oprogramowania
Wzorce projektowe (25)
Wzorzec State
KartaJunior
oplataRoczna()
oplataKarna()
KartaStandard
oplataRoczna()
oplataKarna()
KartaSenior
oplataRoczna()
oplataKarna()
K artaCzytelnika
numer : String
imie : String
nazwisko : String
TypKarty
oplataRoczna()
oplataKarna()
Kontekst
Stan
abstrakcyjny
Stany konkretne
Rozwi
ą
zanie to jest znane jako wzorzec State. Wzorzec ten, podobnie jak
inne wzorce, do opisania klas uczestnicz
ą
cych w nim posługuje si
ę
nazwami ról, jakie one w nim pełni
ą
. KartaCzytelnika jest nazwana
Kontekstem, abstrakcyjny TypKarty – Stanem Abstrakcyjnym, a jego
podklasy – Stanami Konkretnymi.
Obiekt Kontekst, chc
ą
c wykona
ć
metod
ę
zale
ż
n
ą
od typu karty, deleguje
j
ą
do aktualnie zwi
ą
zanego z nim obiektu reprezentuj
ą
cego Typ Karty,
zwykle przekazuj
ą
c referencj
ę
do siebie jako argument takiej metody. W
ten sposób obiekt Typu Karty mo
ż
e odwoła
ć
si
ę
do kontekstu, na którego
rzecz wykonuje odpowiedni
ą
operacj
ę
(np. pobra
ć
dane z obiektu
KartaCzytelnika, wywoła
ć
jego metody etc.)
Bartosz Walter
Wzorce projektowe
26
In
ż
ynieria oprogramowania
Wzorce projektowe (26)
Wzorzec State: uczestnicy
• Kontekst
– posiada referencj
ę
do obiektu reprezentuj
ą
cego
bie
żą
cy stan
• Stan abstrakcyjny
– definiuje interfejs pozwalaj
ą
cy hermetyzowa
ć
zachowanie zwi
ą
zane z ka
ż
dym stanem
• Stan konkretny
– definiuje własne metody implementuj
ą
ce zachowanie
specyficzne dla tego stanu
Podobnie jak w poprzednim przypadku, we wzorcu uczestnicz
ą
3 klasy.
Obiekt Kontekst posiada referencj
ę
do obiektu typu Stan Abstrakcyjny,
wskazuj
ą
c
ą
na bie
żą
cy stan. W obiekcie Stan zdefiniowane s
ą
wszystkie
metody, których zachowanie zale
ż
y od stanu obiektu Kontekst, natomiast
Stany konkretne definiuj
ą
te metody.
Bartosz Walter
Wzorce projektowe
27
In
ż
ynieria oprogramowania
Wzorce projektowe (27)
Wzorzec State: konsekwencje
• Podział zachowania obiektu wg stanów
– kod zwi
ą
zany ze jednym stanem jest zapisany
w
jednym obiekcie
• zmiana stanu jest realizowana przez
zmian
ę
obiektu
stanu na inny
• ochrona przed stanem niespójnym
• mo
ż
liwo
ść
współdzielenia obiektów State
– obiekty State zwykle definiuj
ą
tylko zachowanie
– obiekty State zwykle s
ą
bezstanowe
Zastosowanie wzorca pozwala modyfikowa
ć
zachowanie obiektów tak
jakby zmieniała si
ę
ich klasa – i to jest najwa
ż
niejszy cel i skutek
zastosowania tego wzorca. Drugim efektem jest hermetyzacja stanu w
postaci niezale
ż
nych klas, która pozwala na atomiczn
ą
(niepodzieln
ą
)
zmian
ę
tego stanu, bez wprowadzania stanów niespójnych czy
nieoznaczonych.
Ciekawa obserwacja dotyczy mo
ż
liwo
ś
ci współdzielenia obiektów typu
State. Je
ż
eli nie one przechowuj
ą
informacji (a w wi
ę
kszo
ś
ci przypadków
mo
ż
e ona by
ć
zapami
ę
tana w obiekcie Kontekst), a jedynie definiuj
ą
zachowanie, wówczas – paradoksalnie – obiekty te, reprezentuj
ą
ce stan,
s
ą
bezstanowe i mog
ą
by
ć
współdzielone mi
ę
dzy wiele obiektów typu
Kontekst.
Bartosz Walter
Wzorce projektowe
28
In
ż
ynieria oprogramowania
Wzorce projektowe (28)
Biblioteka
Katalogi
Katalogi
Karty czytelników
Karty czytelników
Karty ksi
ąż
ek
Karty ksi
ąż
ek
Kontakt
z czytelnikiem
Kontakt
z czytelnikiem
Trzeci moduł biblioteki słu
ż
y do zarz
ą
dzania kartami ksi
ąż
ek. Z uwagi na
liczb
ę
ksi
ąż
ek (a co za tym idzie, tak
ż
e ich kart) jednym z wa
ż
niejszych
wymaga
ń
wobec niego jest wydajno
ść
.
Bartosz Walter
Wzorce projektowe
29
In
ż
ynieria oprogramowania
Wzorce projektowe (29)
Ksi
ąż
ki
• Wolumen ksi
ąż
ek w bibliotece to obecnie ok. 100 000
egzemplarzy
• Docelowa liczba ksi
ąż
ek jest nieograniczona
• Ka
ż
da ksi
ąż
ka posiada swoj
ą
kart
ę
• Ksi
ąż
ka mo
ż
e składa
ć
si
ę
z wielu tomów, które mog
ą
by
ć
wypo
ż
yczane pojedynczo, niezale
ż
nie od innych
tomów
W bibliotece przechowywanych jest ok. 100 000 woluminów, przy czym
docelowa liczba ksi
ąż
ek jest nieograniczona. Ka
ż
da ksi
ąż
ka (i ka
ż
dy tom
ksi
ąż
ki, w przypadku ksi
ąż
ek wielotomowych) posiada swoj
ą
kart
ę
ksi
ąż
ki,
która przechowuje najwa
ż
niejsze informacje o niej, w tym tak
ż
e o
wypo
ż
yczeniach. W efekcie daje to znaczn
ą
liczb
ę
obiektów tego typu, co
mo
ż
e by
ć
ź
ródłem problemów w niektórych zastosowaniach (np. przy
wy
ś
wietlaniu listy ksi
ąż
ek).
Bartosz Walter
Wzorce projektowe
30
In
ż
ynieria oprogramowania
Wzorce projektowe (30)
Problem 3: Du
ż
a liczba kart ksi
ąż
ek
Liczba ksi
ąż
ek: wymagania
• ka
ż
da ksi
ąż
ka i ka
ż
dy tom posiadaj
ą
swoj
ą
kart
ę
• mo
ż
liwe jest wykonywanie zapyta
ń
na li
ś
cie ksi
ąż
ek
• umiarkowana zło
ż
ono
ść
pami
ę
ciowa
Ksi
ąż
ka
autor : String
tytuł : String
szukaj()
Ksi
ąż
ka
autor : String
tytuł : String
szukaj()
Ksi
ąż
ka
autor : String
tytuł : String
szukaj()
Ksi
ąż
ka
autor : String
tytuł : String
szukaj()
Ksi
ąż
ka
autor : String
tytuł : String
szukaj()
Zajmiemy si
ę
problemem wydajnego zarz
ą
dzania du
żą
liczb
ą
Kart
Ksi
ąż
ek. Tworzenie i usuwanie stu tysi
ę
cy obiektów jest kłopotliwe i
wymaga znacznej pami
ę
ci oraz du
ż
ych nakładów obliczeniowych. Celem
jest zatem takie zaprojektowanie tego modułu, aby ograniczy
ć
zło
ż
ono
ść
pami
ę
ciow
ą
procedur zwi
ą
zanych z Kartami Ksi
ąż
ek..
Bartosz Walter
Wzorce projektowe
31
In
ż
ynieria oprogramowania
Wzorce projektowe (31)
Rozwi
ą
zanie 1: jedna ksi
ąż
ka = jeden obiekt
Wady i zalety:
• intuicyjne i łatwe przetwarzanie
• gigantyczne zapotrzebowanie na pami
ęć
• ograniczenia wydajno
ś
ciowe
• nieracjonalne wykorzystanie zasobów
Biblioteka
Ksi
ąż
ka
autor : String
tytuł : String
szukaj()
n
n
Pierwsze rozwi
ą
zanie jest intuicyjne i naturalne: ka
ż
dej fizycznej karcie
ksi
ąż
ki odpowiada jeden obiekt, tworzony w momencie, gdy jest
potrzebny. Ten model charakteryzuje si
ę
prostym sposobem
przetwarzania: w odpowiedzi na zapytanie (np. wyszukiwanie) obiekt
zarz
ą
dzaj
ą
cy (biblioteka) tworzy niezb
ę
dn
ą
liczb
ę
obiektów
reprezentuj
ą
cych karty ksi
ąż
ki.
Jednak takie rozwi
ą
zanie posiada wszystkie wady zwi
ą
zane z
wydajno
ś
ci
ą
: du
ż
e wymagania pami
ę
ciowe, ograniczenia wydajno
ś
ciowe i
nieracjonalne gospodarowanie zasobami. Nale
ż
y zatem je odrzuci
ć
i
szuka
ć
bardziej zaawansowanego mechanizmu.
Bartosz Walter
Wzorce projektowe
32
In
ż
ynieria oprogramowania
Wzorce projektowe (32)
Rozwi
ą
zanie 2: pula obiektów
Wady i zalety:
• ograniczone u
ż
ycie pami
ę
ci z racjonalnym
zarz
ą
dzaniem
• ograniczona liczba jednocze
ś
nie wykorzystywanych
obiektów
• stosowane do obiektów nierozró
ż
nialnych
Ksi
ąż
ka
autor : String
tytuł : String
szukaj()
Czytelnik
(from Use Case View)
Zarz
ą
dca ksi
ąż
ek
utwórzObiekt()
pobierzObiekt()
n
n
Rozwi
ą
zaniem, które usuwa wady poprzedniego, jest pula obiektów.
Obiekt zarz
ą
dzaj
ą
cy tworzeniem obiektów-ksi
ąż
ek nie tworzy ich za
ka
ż
dym razem, gdy za
żą
da tego klient. Przechowuje on grup
ę
aktywnych
obiektów (wła
ś
nie pul
ę
), które s
ą
przydzielane klientom w miar
ę
ich
potrzeb, a po wykorzystaniu zwracane do puli.
W ten sposób rozwi
ą
zany jest problem racjonalnego wykorzystania
zasobów, poniewa
ż
obiekty mog
ą
by
ć
wykorzystywane wielokrotnie.
Wydajno
ść
takiego rozwi
ą
zania zale
ż
y od liczby aktywnych obiektów i
charakterystyki czasowej nadchodz
ą
cych
żą
da
ń
.
Jednak nie rozwi
ą
zuje to wszystkich problemów: pula zasobów słu
ż
y do
zarz
ą
dzania grup
ą
obiektów nierozró
ż
nialnych (np. reprezentuj
ą
cych
niektóre zasoby), natomiast karty ksi
ąż
ek posiadaj
ą
indywidualne dane,
które odró
ż
niaj
ą
je od siebie. Bezpo
ś
rednie zastosowanie tego wzorca nie
jest zatem mo
ż
liwe i nale
ż
y szuka
ć
lepszego rozwi
ą
zania.
Bartosz Walter
Wzorce projektowe
33
In
ż
ynieria oprogramowania
Wzorce projektowe (33)
Wzorzec Pool of Objects
Pula
obiektów
Obiekt
Ksi
ąż
ka
autor : String
tytuł : String
szukaj()
Czytelnik
(from Use Case View)
Zarz
ą
dca ksi
ąż
ek
utwórzObiekt()
pobierzObiekt()
n
n
Zanim jednak przejdziemy do kolejnego mechanizmu, jaki mo
ż
e znale
źć
zastosowanie w tej sytuacji, warto w cało
ś
ci omówi
ć
wzorzec Pool of
Objects. Uczestnicz
ą
w nim dwie klasy: Zarz
ą
dca, który dysponuje pul
ą
,
oraz Obiektu zarz
ą
dzanego przez niego. Klient (w tym przypadku
Czytelnik) otrzymuje obiekty klasy Ksi
ąż
ka wył
ą
cznie za po
ś
rednictwem
Zarz
ą
dcy.
Bartosz Walter
Wzorce projektowe
34
In
ż
ynieria oprogramowania
Wzorce projektowe (34)
Wzorzec Pool of Objects: uczestnicy
• Pula obiektów
– definiuje punkt dost
ę
pu do obiektów
– zarz
ą
dza cyklem
ż
ycia obiektów
• Obiekt
– definiuje swój cykl
ż
ycia
– mo
ż
e by
ć
powtórnie wykorzystany
Najwa
ż
niejsze dwie funkcje Puli obiektów to zdefiniowanie punktu dost
ę
pu
do obiektów (zarówno do ich tworzenia, jak i zwrotu) oraz zarz
ą
dzanie
cyklem ich
ż
ycia: tworzeniem, inicjalizacj
ą
i usuwaniem.
Klient mo
ż
e otrzyma
ć
instancj
ę
klasy Obiekt wył
ą
cznie za pomoc
ą
Puli
obiektów i w ten sam sposób zwalnia przydzielony obiekt.
Bartosz Walter
Wzorce projektowe
35
In
ż
ynieria oprogramowania
Wzorce projektowe (35)
Wzorzec Pool of Objects: konsekwencje
• Zwi
ę
kszona wydajno
ść
– obiekty s
ą
tworzone w ograniczonej liczbie instancji i
wykorzystywane wielokrotnie
– zrównowa
ż
one obci
ąż
enie zasobów
• Lepsza hermetyzacja
– klient nie zajmuje si
ę
tworzeniem i obsług
ą
obiektów
Dzi
ę
ki wykorzystaniu wzorca Pool of Objects, Obiekty s
ą
tworzone w
ograniczonej liczbie instancji i wielokrotnie wykorzystywane ponownie.
Pozwala to usun
ąć
bardzo istotny koszt zwi
ą
zany z ich tworzeniem. Jest
on szczególnie dokuczliwy, gdy liczba
żą
da
ń
jest du
ż
a, a czas
wykorzystania obiektu bardzo krótki, np. w przypadku przetwarzania
zapyta
ń
zwracaj
ą
cych list
ę
obiektów. Pula obiektów mo
ż
e tak
ż
e
wykorzystywa
ć
skomplikowane algorytmy heurystyczne w celu
przewidywania zapotrzebowania na obiekty i dostosowywania do potrzeb
liczby Obiektów przechowywanych w puli, co dodatkowo przyczynia si
ę
do
optymalizacji wykorzystania zasobów.
Ponadto, wzorzec ten poprawia tak
ż
e hermetyzacj
ę
Obiektu: jego
tworzeniem i konfiguracj
ą
zajmuje si
ę
Pula obiektów, natomiast Klient
jedynie korzysta z usług oferowanych Obiekt.
Bartosz Walter
Wzorce projektowe
36
In
ż
ynieria oprogramowania
Wzorce projektowe (36)
Rozwi
ą
zanie nr 3: "anonimowe ksi
ąż
ki"
Wady i zalety:
• takie jak w przypadku wzorca Pool of Objects
• niejawne konfigurowanie obiektów danymi instancji
Ksi
ąż
ka
autor : String
tytuł : String
załadujDane()
Czytelnik
(from Use Case View)
Zarz
ą
dca ksi
ąż
ek
pobierzObiekt()
n
n
baza danych
Powiedzieli
ś
my wcze
ś
niej,
ż
e wzorzec Pool of Objects nie spełnia
wszystkich wymaga
ń
zdefiniowanych w specyfikacji tego modułu.
Na tym slajdzie przedstawiono inny mechanizm – "anonimowych
ksi
ąż
ek", stanowi
ą
cy rozwini
ę
cie wzorca Puli obiektów. Pula
przechowywała nierozró
ż
nialne obiekty gotowe do u
ż
ycia, zatem
niemo
ż
liwe było przechowywanie w nich informacji specyficznej.
Natomiast w przypadku obiektów anonimowych pula zawiera obiekty
"nieaktywne", pozbawione specyficznych danych, wymagaj
ą
ce inicjacji
przed przekazaniem Klientowi. Polega ona wła
ś
nie na załadowaniu do
obiektu informacji specyficznych, np. odczytanych z bazy danych. W ten
sposób klient otrzymuje dokładnie taki obiekt, jakiego oczekuje, nie
powoduj
ą
c zwi
ę
kszenia zu
ż
ycia zasobów.
Zalety tego rozwi
ą
zania s
ą
wi
ę
c identyczne jak w przypadku puli
obiektów, a jednocze
ś
nie mo
ż
liwe jest tak
ż
e konfigurowanie obiektów
danymi specyficznymi.
Bartosz Walter
Wzorce projektowe
37
In
ż
ynieria oprogramowania
Wzorce projektowe (37)
Wzorzec Flyweight
Fabryka
Obiekt
Ksi
ąż
ka
autor : String
tytuł : String
załadujDane()
Czytelnik
(from Use Case View)
Zarz
ą
dca ksi
ąż
ek
pobierzObiekt()
n
n
baza danych
Idea tej koncepcji jest zawarta we wzorcu Flyweight, którego celem jest
wła
ś
nie ograniczenie liczby instancji wymaganych do obsługi
nadchodz
ą
cych
żą
da
ń
, przy zapewnieniu ich indywidualnych cech. We
wzorcu rola pełniona przez Zarz
ą
dce jest nazywana Fabryk
ą
, natomiast
Ksi
ąż
ka jest Obiektem.
Istot
ą
wzorca jest podział danych przechowywanych w Obiektach na dane
wewn
ę
trzne (współdzielone) i zewn
ę
trzne (unikatowe dla ka
ż
dego
obiektu). Dane wewn
ę
trzne nie s
ą
modyfikowane przy inicjacji obiektu,
natomiast dane zewn
ę
trzne s
ą
dostarczane dla ka
ż
dego obiektu z
zewn
ą
trz przed przekazaniem obiektu Klientowi.
Bartosz Walter
Wzorce projektowe
38
In
ż
ynieria oprogramowania
Wzorce projektowe (38)
Wzorzec Flyweight: uczestnicy
• Obiekt
– podlega współdzieleniu mi
ę
dzy klientów
– definiuje interfejs do przyjmowania i odtwarzania
stanu zewn
ę
trznego obiektu
– przechowuje stan wewn
ę
trzny (współdzielony)
– jest niezale
ż
ny od kontekstu (z wyj
ą
tkiem stanu
zewn
ę
trznego)
• Fabryka obiektów
– tworzy i przechowuje obiekty
Wzorzec składa si
ę
z dwóch obiektów:
Obiektu, który umo
ż
liwia skonfigurowanie go danymi specyficznymi, oraz
Fabryki obiektów, która stanowi (z punktu widzenia klienta) logiczny
konstruktor obiektów. Fabryka ta posiada pami
ęć
(pul
ę
obiektów), w której
przechowuje utworzone wcze
ś
niej, anonimowe instancje. Zajmuje si
ę
tak
ż
e zapisem i odtwarzaniem (serializacj
ą
i deserializacj
ą
) stanu
zewn
ę
trznego obiektu.
Bartosz Walter
Wzorce projektowe
39
In
ż
ynieria oprogramowania
Wzorce projektowe (39)
Wzorzec Flyweight: konsekwencje
• Zmniejszenie wymaga
ń
pami
ę
ciowych programu
– zmniejszenie ogólnej liczby obiektów
– zmniejszenie rozmiaru stanu obiektów
– stan zewn
ę
trzny mo
ż
e by
ć
przechowywany lub
wyliczany
• Wzrost zło
ż
ono
ś
ci obliczeniowej
– dodatkowy nakład na zarz
ą
dzanie stanem
zewn
ę
trznym
Zastosowanie tego wzorca pozwala na znaczne oszcz
ę
dno
ś
ci pami
ę
ci,
szczególnie w aplikacjach korzystaj
ą
cych z du
ż
ej liczby instancji tego
samego typu. Z jednej strony ulega zmniejszeniu ogólna liczba
utworzonych obiektów, a z drugiej – rozmiar ich stanów wewn
ę
trznych.
Oczywi
ś
cie, nie uwzgl
ę
dnia to kosztu przechowywania stanu
zewn
ę
trznego, jednak w pewnych sytuacjach mo
ż
e on by
ć
obliczony, a
ponadto nie wymaga on tworzenia i usuwania obiektów, co stanowi
główny problem w tego typu aplikacjach.
Bartosz Walter
Wzorce projektowe
40
In
ż
ynieria oprogramowania
Wzorce projektowe (40)
Biblioteka
Katalogi
Katalogi
Karty czytelników
Karty czytelników
Karty ksi
ąż
ek
Karty ksi
ąż
ek
Kontakt
z czytelnikiem
Kontakt
z czytelnikiem
Ostatnim modułem biblioteki jest podsystem odpowiedzialny za kontakt z
czytelnikami, np. poprzez poczt
ę
elektroniczn
ą
. Pozwala on na
przesyłanie Czytelnikom informacji dotycz
ą
cych ich rezerwacji, jak
równie
ż
np. o nowych nabytkach biblioteki
Bartosz Walter
Wzorce projektowe
41
In
ż
ynieria oprogramowania
Wzorce projektowe (41)
Kontakt z czytelnikiem
• Czytelnik mo
ż
e zarezerwowa
ć
ksi
ąż
k
ę
, która aktualnie
jest niedost
ę
pna
• Informacja o dost
ę
pno
ś
ci ksi
ąż
ki zostanie wysłana do
czytelnika natychmiast po jej zwrocie przez
poprzedniego czytelnika
Biblioteka
Czytelnik
Problemem jest stworzenie efektywnego mechanizmu, który pozwoli
przesyła
ć
Czytelnikom powiadomienia o ró
ż
norodnych zmianach
zachodz
ą
cych wewn
ą
trz biblioteki.
Bartosz Walter
Wzorce projektowe
42
In
ż
ynieria oprogramowania
Wzorce projektowe (42)
Problem 4: Newsletter
Newsletter: wymagania
• powiadomienie o stanie rezerwacji
• powiadomienie o nowych ksi
ąż
kach
Problem dotyczy powiadamiania Czytelnika w dwóch sytuacjach: gdy
zmieni si
ę
stan jego rezerwacji (np. Ksi
ąż
ka zostanie zwrócona przez
poprzedniego Czytelnika do Biblioteki) oraz w innych przypadkach, gdy
Biblioteka uzna to za uzasadnione (np. w celu przekazania informacji o
nowo
ś
ciach w Bibliotece).
Bartosz Walter
Wzorce projektowe
43
In
ż
ynieria oprogramowania
Wzorce projektowe (43)
Rozwi
ą
zanie 1: okresowe odpytywanie
Wady i zalety:
• intuicyjna metoda uzyskiwania informacji
• wymaga ci
ą
głej aktywno
ś
ci czytelnika
Czytelnik
Biblioteka
(from Logical View)
Rezerwacja
(from Logical View)
n
n
odpytuje
Pierwszym rozwi
ą
zaniem jest okresowe odpytywanie biblioteki przez
Czytelnika. Rozwi
ą
zanie to, cho
ć
w praktyce cz
ę
sto stosowane, jest
bardzo niewygodne, poniewa
ż
wymaga ci
ą
głej aktywno
ś
ci Czytelnika,
jednocze
ś
nie absorbuj
ą
c zasoby po stronie Biblioteki.
Bartosz Walter
Wzorce projektowe
44
In
ż
ynieria oprogramowania
Wzorce projektowe (44)
Rozwi
ą
zanie 2: powiadamianie
Wady i zalety:
• Biblioteka powiadamia tylko gdy nast
ą
piła zmiana stanu
rezerwacji
• brak obci
ąż
enia czytelnika
Czytelnik
aktualizuj()
Biblioteka
powiadom()
(from Logical View)
Rezerwacja
(from Logical View)
n
n
powiadamia
Dlatego lepszym rozwi
ą
zaniem jest odwrócenie zale
ż
no
ś
ci pomi
ę
dzy
Bibliotek
ą
i Czytelnikiem poprzez przerzucenie na Bibliotek
ę
obowi
ą
zku
asynchronicznego powiadomienia Czytelnika o zmianach. W ten sposób
zasoby po stronie Biblioteki s
ą
anga
ż
owane jedynie w momencie
rzeczywistej zmiany stanu, a Czytelnik nie jest przez t
ę
operacj
ę
absorbowany w
ż
aden sposób.
Bartosz Walter
Wzorce projektowe
45
In
ż
ynieria oprogramowania
Wzorce projektowe (45)
Wzorzec Observer
Czytelnik
aktualizuj()
Biblioteka
powiadom()
(from Logical View)
Rezerwacja
(from Logical View)
n
n
powiadamia
Podmiot
Obserwator
Rozwi
ą
zanie to znane jest jako wzorzec o nazwach Observer lub Listener.
Biblioteka pełni rol
ę
Podmiotu – obiektu, którego stan jest obserwowany,
natomiast Czytelnik jest jego Obserwatorem. Czytelnik wyra
ż
a
zainteresowanie powiadomieniami, rejestruj
ą
c si
ę
Bibliotece jako
Obserwator. W efekcie Biblioteka wywołuje wspóln
ą
metod
ę
wszystkich
Obserwatorów (aktualizuj()) na rzecz ka
ż
dego zarejestrowanego
Obserwatora.
Bartosz Walter
Wzorce projektowe
46
In
ż
ynieria oprogramowania
Wzorce projektowe (46)
Wzorzec Observer: uczestnicy
• Podmiot
– utrzymuje rejestr Obserwatorów
– umo
ż
liwia doł
ą
czanie i odł
ą
czanie Obserwatorów
– powiadamia Obserwatory o zmianie swojego stanu
• Obserwator
– posiada interfejs słu
żą
cy do powiadamiania o
zmianach
– aktualizuje swój stan na podstawie powiadomienia
We wzorcu udział bior
ą
udział dwa obiekty: Podmiot i Obserwator.
Odpowiedzialno
ść
Podmiotu polega na przechowywaniu referencji do
Obserwatorów, ich dodawaniu i usuwaniu, a tak
ż
e ich powiadamianiu o
zmianach. Obserwator posiada interfejs słu
żą
cy do powiadamiania przez
Podmiot, oraz aktualizuje swój stan lub wykonuje inne czynno
ś
ci na
podstawie powiadomienia.
W j
ę
zyku Java rola obiektu obserwowanego jest reprezentowana przez
klas
ę
java.util.Observable, natomiast obserwatory implementuj
ą
interfejs
java.util.Observer. Znacznie upraszcza to zadanie implementacji wzorca
w tym j
ę
zyku.
Bartosz Walter
Wzorce projektowe
47
In
ż
ynieria oprogramowania
Wzorce projektowe (47)
Wzorzec Observer: konsekwencje
• Lu
ź
niejsze powi
ą
zania
pomi
ę
dzy obiektami:
– Podmiot komunikuje si
ę
z innymi obiektami przez
interfejs Obserwatora
– Podmiot i Obserwatory mog
ą
nale
ż
e
ć
do ró
ż
nych
warstw abstrakcji
• Programowe
rozgłaszanie komunikatów
• Spójno
ść
stanu
Podmiotu i Obserwatorów
Jednym z najwa
ż
niejszych konsekwencji zastosowania wzorca Observer
jest ograniczenie powi
ą
za
ń
i zale
ż
no
ś
ci pomi
ę
dzy obserwatorami i
obiektem obserwowanym. Wprawdzie obiekt obserwowany posiada
referencje do obserwatorów, jednak jego wiedza jest ograniczona tylko do
znajomo
ś
ci interfejsu Obserwator, który deklaruje jedn
ą
metod
ę
. Tak
ż
e
Obserwatory nie musz
ą
zna
ć
Podmiotu w momencie wywołania ich
metody aktualizuj(), poniewa
ż
otrzymuj
ą
powiadomienia asynchroniczne.
Dzi
ę
ki ogólno
ś
ci interfejsu Obserwator obiekty uczestnicz
ą
ce we wzorcu
mog
ą
nale
ż
e
ć
do ró
ż
nych warstw abstrakcji. Wzorzec pozwala zachowa
ć
spójno
ść
pomi
ę
dzy warstwami aplikacji, poniewa
ż
informacje o zmianach
w jednej warstwie s
ą
przekazywane natychmiast do pozostałych obiektów.
Bartosz Walter
Wzorce projektowe
48
In
ż
ynieria oprogramowania
Wzorce projektowe (48)
Podsumowanie
• Wzorce projektowe s
ą
abstrakcyjnymi
rozwi
ą
zaniami powtarzaj
ą
cych si
ę
problemów
• Wzorzec posiada okre
ś
lony zbiór atrybutów
• Wzorce pozwalaj
ą
efektywnie rozwi
ą
zywa
ć
problemy projektowe
Podczas wykładu przedstawiono krótki zarys genezy wzorców
projektowych i motywacji, jaka wspiera ich rozwój. Ponadto
zaprezentowano wybrane wzorce na przykładzie fragmentów systemu
bibliotecznego.
Wyszukiwarka
Podobne podstrony:
IO 05 2 Wzorce projektowe
Inzynieria oprogramowania w ujeciu obiektowym UML wzorce projektowe i Java iowuje
Wzorce projektowe ściaga
Projektowanie zorientowane obiektowo Wzorce projektowe Wydanie II
J2EE Wzorce projektowe Wydanie 2
BYT Wzorce projektowe wyklady z 10 i 24 11 2006
Ajax Wzorce projektowe
PIO W7 2 Wzorce projektowe
J2EE Wzorce projektowe
Ajax Wzorce projektowe
io w12 projektowanie architekury opr
IOpr, wykład 5, wzorce projekt(1)
więcej podobnych podstron