Wzorce projektowe – czynnościowe Command Strategy

WYKŁAD 10
Wzorce projektowe – czynno ciowe
Command
Strategy
Behavioral Design Pattern: Command [obj]
Kapsułkuje dania w postaci obiektu, co
umo liwia parametryzowanie klientów
ró nymi daniami, kolejkowanie da lub
zapisywanie ich w dziennikach, a tak e
ułatwia implementacj anulowanych
operacji.
Inne nazwy: Akcja, Transakcja
Uzasadnienie:
Czasem istnieje potrzeba wydawania da obiektom bez
jakiejkolwiek wiedzy o danej operacji lub odbiorcy
dania. Przykładem mog by elementy GUI takie jak
przyciski lub menu. Obiekty te s odpowiedzialne za
wykonywanie da w odpowiedzi na akcje u ytkownika.
dania te zale jednak od zastosowania. Obiekty graficzne
nie mog go zna ani nie mog go w sobie implementowa .
Rozwi zaniem jest przekształcenie dania w obiekt. Obiekt
ten mo na przekazywa . Klasa Polecenie deklaruje interfejs
do ró nych działa , np. jednooperacyjny Wykonaj().
Podklasy konkretne okre laj pary odbiorca- akcja pami taj c
odbiorc jako zmienn i implementuj c Wykonaj() w celu
wywołania dania. Odbiorca ma wiedz wymagan do
spełnienia dania.
Dobrym przykładem jest implementacja
Menu. Ka dy element menu jest obiketem
klasy ElementMenu. Klasa Aplikacja
tworzy menu i jego elementy wraz z reszt
interfejsu u ytkownika. Kontroluje ona te
na bie co obiekty Dokument otwarte przez
u ytkownika.
Aplikacja konfiguruje ka dy obiekt klasy
ElementMenu za pomoc obiektu podklasy
konkretnej Polecenia. Gdy u ytkownik wybierze
ElementMenu, ten wywołuje Wykonaj() ze
swojego obiektu Polecenia. Obiekty klasy
ElementMenu nie wiedz której podklasy
Polecenia u ywaj . Podklasy Polecenia
przechowuj odbiorc
dania i wywołuj jedn
lub wi cej jego operacji.
Czasami pojawia si te konieczno
wykonania całego ci gu polece . Aby
realizowa takie ci gi polece mo na
zdefiniowa klas MakroPolecenie, która
mo e wykona nieograniczony ci g polece
przez ni okre lony.
Wzorzec Command rozdziela obiekt wywołuj cy
operacj od obiektu, który wie jak j wykona .
Daje to elastyczno przy projektowaniu interfejsu
u ytkownika. Mo na np. zapewni aby ta sama
operacja była wywoływana zarówno z Menu jak i
przez przycisk dzi ki korzystaniu przez nie z tego
samego obiketu klasy konkretnej Polecenia.
Polecenia mo na wymienia dynamicznie, co
przydaje si przy menu zale nym od kontekstu.
Mo na te tworzy skrypty z polece przez
składanie ich z fragmentów (por. nagrywanie
makr np. w aplikacjach MS Office).
Stosowalno :
• sparametryzowanie obiektów wykonywan akcj (jak
ElementMenu) – w j zykach proceduralnych odpowiada to
funkcjom zwrotnym (callbacks)
• specyfikowanie, kolejkowanie i spełnianie da w
ró nym czasie – mo na przesyła obiekty dania do
innych procesów i tam je realizowa
• uzgl dnienia anulowania wprowadzanych zmian –
operacja Wykonaj() z obiektu Polecenie mo e zapami ta
stan (lista stanów) potrzebny do cofni cia skutków jej
działania przez operacj AnulujWykonanie()
• umo liwienie wpisywania zmian do
dziennika, tak aby w razie niepowodzenia
(nawet awaria systemu) mo na było je
ponownie wykona – konieczno dodania
operacji Zapisz() i Wczytaj() do interfejsu
Polecenia
• stworzenie systemu wokół operacji
wysokiego poziomu zbudownych z operacji
pierwotnych – systemy transakcyjne
Struktura:
Uczestnicy:
• Polecenie
– deklaruje interfejs do wykonywania operacji
• PolecenieKonkretne (PolecenieWklej,
PolecenieOtwórz)
– definiuje powi zanie mi dzy obiektem
Odbiorca i akcj
– implementuje operacj Wykonaj() przez
wywołanie odpowiednich operacji Odbiorcy
• Klient (Aplikacja)
– worzy obiekt klasy PolecenieKonkretne i ustala
jego odbiorc
• Wywołuj cy (ElementMenu)
– prosi polecenie o spełnienie dania
• Odbiorca (Dokument, Aplikacja)
– wie jak wykona operacje zwi zane ze
spełnieniem dania; Odbiorc mo e by
dowolna klasa
Współpraca:
• Klient tworzy obiekt PolecenieKonkretne i podaje
jego odbiorc
• ObiektWywołuj cy przechowuje obiekt
PolecenieKonkretne
• Wywołuj cy zgłasza danie, wywołuj c operacj
Wykonaj() Polecenia; je li jest wycofywalne, to
najpierw zapami tuje stan
• obiekt PolecenieKonkretne wywołuje operacje
swojego odbiorcy w celu spełnienia dania
Konsekwencje:
• Polecenie oddziela obiekt, który wywołał operacj
od tego, który wie jak j wykona
• Polecenia s obiektami – mog by przetwarzane
tak jak inne obiekty
• z poszczególnych polece mo na tworzy
polecenia zło one – przykład MakroPolecenie;
ogólnie polecenia zło one s obiektami z wzorca
Composite
• mo na łatwo dodawa nowe polecenia bez
modyfikowania istniej cych klas
Implementacja:
• na ile inteligentne powinno by polecenie?
• mo liwo anulowania i przywracania
operacji
• unikanie narastania bł dów w procesie
anulowania operacji
• stosowanie szablonów z C++
Przykłady
Zastosowania
Pokrewne wzorce:
• Composite – do implementowania
MakroPolecenia
• Memento – do pami tania stanu potrzebnego do
anulowania operacji
• Prototype – Polecenie, które musi by skopiowane
przed umieszczeniem go na li cie działa jak
Prototype
Behavioral Design Pattern: Strategy [obj]
Definiuje rodzin algorytmów, kapsułkuje
ka dy z nich i umo liwia ich wymian .
Sprawia, e mo liwe staje si zmienianie
algorytmu niezale nie od u ywaj cych go
klientów.
Uzasadnienie:
W edytorach tekstu stosuje si wiele algorytmów
dziel cych tekst na wiersze. Jednak algorytmów
takich nie powinni my umieszcza na sztywno w
klasach, poniewa :
• klienci wymagajacy dzielenia tekstu na wiersze staj
si skomplikowani
• ró ne algorytmy s odpowiednie w ró nych
sytuacjach, ale mo emy niepotrzebowa wszystkich
• trudno jest dodawa lub zmienia algorytmy gdy
podział na wiersze jest cz ci klienta
Aby unikn tych problemów mo emy
zdefiniowa klasy, które kapsułkuj
poszczególne algorytmy podziału na
wiersze. Zakapsułkowany w ten sposób
algorytm nazywamy strategi .
ObiektZło ony jest odpowiedzialny za
utrzymywanie i uaktualnianie przej do
nowych wierszy w tek cie. Strategie
podiału na wiersze nie s jednak
zaimplementowane w niej, lecz oddzielnie
w klasach konkretnych klasy Składacz.
Podklasy konkretne klasy Składacz
implementuj ró ne strategie.
• Składacz prosty – w danej chwili wyznacza
jedno przej cie do nowego wiersza
• SkładaczTeXowy – optymalizuje globalnie
od razu dla całego akapitu zestaw przej do
nowej linii
• SkładaczTablicowy – tak dobiera przej cia
do nowego wiersza aby ka dy wiersz miał
tyle samo elementów
ObiektZło ony ma odwołanie do obiektu
Składacz. Przy ka dym formatowaniu
przekazuje on odpowiedzialno do
wybranego przez siebie obiektu Składacz
konkretny.
Stosowalno :
• wiele powi zanych ze sob klas ró ni si tylko
zachowaniem – strategie umo liwiaj konfigurowanie
klasy za pomoc jednego z wielu zachowa
• potrzebne s ró ne warianty jakiego algorytmu
• w algorytmie s u ywane dane, o których klient nie
powinien wiedzie – ukrycie ich w algorytmach
• kasa definiuje wiele zachowa , które w jej metodach s
obło one wielokrotnymi instrukcjami warunkowymi –
mo na unikn objawu wskazuj cego na nadmiern
strukturalno kodu
Struktura:
Uczestnicy:
• Strategia (Składacz)
– deklaruje interfejs wspólny dla wszystkich
obsługiwanych algorytmów; Kontekst
wykorzystuje ten interfejs do wykonywania
algorytmu zdefiniowanego przez
Strategi Konkretn
• StrategiaKonkretna (SkładaczProsty,
SkładaczTeXowy, SkładaczTablicowy)
– implementuje algorytm wykorzystuj c interfejs
z klasy Strategia
• Kontekst (ObiketZło ony)
– jest konfigurowany za pomoc obiektu
StrategiaKonkretna
– utrzymuje odwołanie do obiektu Strategia
– mo e definiowa interfejs umo liwiaj cy
Strategii uzyskanie dost pu do swoich
danych
Współpraca:
• klasy Strategia i Kontekst współdziałaj w celu
zastosowania wybranego algorytmu – Kontekst
mo e przekaza potrzebne dane albo samego
siebie (wtedy mo liwo odwoła zwrotnych)
• Kontekst przekazuje dania od klientów do
swojej strategii – zwykle klienci tworz obiekt
StrategiaKonkretna i przekazuj go do kontekstu,
a potem komunikuj si wył cznie z kontekstem
Konsekwencje:
• rodziny powi zanych ze sob algorytmów
• alternatywa dla tworzenia podklas
• eliminacja instrukcji warunkowych
• wybór implementacji
• klienci musz by wiadomi istnienia ró nych strategii
• koszty zwi zane z komunikacj mi dzy Strategi a
Kontekstem
• zwi kszona ilo obiektów – rozwi zaniem jest wtedy
wzorzec obiektowy FlyWeight
Implementacja:
• definiowanie interfejsów Strategii i Kontekstu
• strategie jako parametry szablonów – wtedy
eliminacja klasy abstrakcyjnej Strategia
• dooprowadzenie do tego aby obiekty klasy
Strategia były opcjonalne – mo liwo
wprowadzenia domy lnego zachowania Kontekstu
Przykłady
Zastosowania
Pokrewne wzorce:
• Flyweight – obiekty Strategia s cz sto
dobrymi kandydatami na pyłki.