Zaawansowane projektowanie obiektowe
Wzorce projektowe cz. III
Prowadzący:
Bartosz Walter
Wzorce projektowe cz. III
1
Bartosz Walter
Zaawansowane projektowanie obiektowe
Decorator: cel
•
UmoŜliwienie dynamicznego dodawania funkcjonalności
do obiektu
•
Stworzenie elastycznej alternatywy dla tworzenia
podklas
E. Gamma et al. (1995)
Wzorce projektowe cz. III (2)
Dekorator jest wzorcem zbliŜonym pod względem struktury do wzorców
Proxy i Adapter. Celem jego stosowania jest stworzenie moŜliwości
dodawania funkcjonalności do klasy w czasie wykonywania programu.
Alternatywnym sposobem realizacji podobnego celu (modyfikacji
zachowania wewnątrz grupy klas) jest dziedziczenie, jednak ma ono
powaŜne wady. JeŜeli klasa ma trzy róŜne właściwości, które mogą
wpływać na jej zachowanie i mogą przyjmować wartości binarne (np. klasa
Pracownik: wiek – pełnoletni/dziecko, zatrudnienie –
pracujący/bezrobotny, stan cywilny – wolny/Ŝonaty), wówczas do
reprezentacji wszystkich moŜliwych przypadków naleŜałoby utworzyć 2^3
= 8 podklas. Liczba ta rośnie wykładniczo wraz ze wzrostem liczby
właściwości. Takie rozwiązanie na dłuŜszą metę jest nieakceptowalne, i
dlatego konieczne jest wykorzystanie innego mechanizmu, np. wzorca
Decoratora.
Wzorce projektowe cz. III
2
Bartosz Walter
Zaawansowane projektowanie obiektowe
Decorator: struktura
Component
+component
operation()
ConcreteComponent
Decorator
component->operation()
operation()
operation()
ConcreteDecoratorA
addedState
ConcreteDecoratorB
decorator->operation()
addedBehavior()
operation()
addedBehaviour()
operation()
Klient wysyła komunikat do obiektu
Decorator
, który
przekazuje go obiektowi
ConcreteComponent
oraz
wykonuje dodatkowe operacje („dekoracje”)
Wzorce projektowe cz. III (3)
Component jest wspólnym interfejsem dla wszystkich klas, które moŜna
dekorować. Implementują go zarówno klasa ConcreteComponent, która
jest odpowiedzialna za podstawową funkcjonalność oferowaną klientowi,
jak i dekoratory. KaŜdy dekorator posiada referencję (oznaczoną jako
kompozycję, aby zaznaczyć obowiązkowość i siłę tej relacji) do innego
obiektu Component, którym moŜe być ponownie dekorator lub
ConcreteComponent. Otrzymując Ŝądanie wykonania określonej operacji,
dekorator deleguje je do swojego „wewnętrznego” obiektu Component, a
następnie wykonuje specyficzną dla siebie dodatkową funkcjonalność.
Dzięki temu dodanie do obiektu nowej funkcjonalności polega na
utworzeniu dekoratora i przekazaniu mu owego obiektu. W ten sposób
dekorator staje się rzeczywistym odbiorcą komunikatów od klienta, a
ConcreteComponent – jego podwykonawcą.
Kiedy kaŜdy dekorator (klasy ConcreteDecoratorA i ConcreteDecorator B)
dodaje do dekorowanego obiektu tylko jedną funkcję, wówczas dekorując
obiekt wielokrotnie uzyskujemy efekt osiągnięcia Ŝądanej sumarycznej
funkcjonalności. Pod względem typu udekorowany obiekt nie róŜni się od
obiektu nieudekorowanego (klient widzi go przez interfejs Component),
dlatego zastosowanie tego wzorca nie wymaga istotnych zmian w kodzie
klienta.
Wzorce projektowe cz. III
3
Bartosz Walter
Zaawansowane projektowanie obiektowe
Decorator: uczestnicy
•
Component
– definiuje wspólny interfejs obiektów, które moŜna
dekorować
•
Concrete Component
– realizuje podstawową funkcjonalność obiektu
•
Decorator
– posiada referencję typu
Component
i do tego obiektu
deleguje komunikaty
– rozszerza funkcjonalność obiektu
ConcreteComponent
Wzorce projektowe cz. III (4)
Warto zwrócić uwagę, Ŝe obiekt ConcreteComponent, aby mógł
uczestniczyć w tym wzorcu, musi definiować interfejs Component, którego
alternatywną implementacją są dekoratory. WaŜne jest teŜ, aby
dekoratory odpowiednio delegowały swoje metody do wewnętrznych
obiektów typu Component.
Wzorce projektowe cz. III
4
Bartosz Walter
Zaawansowane projektowanie obiektowe
Decorator: konsekwencje
•
Większa elastyczność w przydziale odpowiedzialności
niŜ w przypadku dziedziczenia
•
MoŜliwość
dodawania funkcjonalności w trakcie
wykonywania programu
, gdy jest ona potrzebna
•
ToŜsamość obiektu
z którym komunikuje się klient
moŜe
się zmieniać
wskutek dekoracji
•
Łatwiejsze testowanie
poszczególnych dekoratorów
Wzorce projektowe cz. III (5)
Wykorzystanie dekoratorów w celu rozszerzenia funkcjonalności
oferowanej przez klasę ma wiele zalet nad stosowaniem dziedziczenia.
Przydział odpowiedzialności do obiektu jest dynamiczny i na dowolnym
poziomie ziarnistości, zaleŜnym od implementacji dekoratorów.
NaleŜy zwrócić uwagę, Ŝe zastosowanie dekoratora zmienia referencję do
obiektu, do którego odwołuje się klient. Aby uniknąć błędów, warto
tworzenie i stosowanie dekoratorów powierzyć specjalizowanej metodzie
(typu Factory Method).
PoniewaŜ dekoratory słuŜą do modyfikacji zachowania, a nie
przechowywania danych (w szczególności dekoratory mogą być obiektami
bezstanowymi), nie naleŜy przechowywać w nich informacji. Pozwala to
utrzymać ich relatywnie niewielki rozmiar.
Stosowanie dekoratorów przyczynia się do łatwiejszego testowania
jednostkowego systemu, poniewaŜ kaŜdy dekorator wymaga jedynie
testów specyficznych dla siebie, a nie dla kompletnie udekorowanego
obiektu.
Wzorce projektowe cz. III
5