Wzorzec strukturalny Decorator i wzorzec behawioralny Observer

Laboratorium
Projektowanie Obiektowe – Wzorce Projektowe
Temat : Wzorzec strukturalny Decorator
i wzorzec behawioralny Observer
Historia zmian
Data
Wersja
Autor
Opis zmian
21.03.2011
1.0
Tomasz Kowalski
Utworzenie dokumentu i wprowadzenie zadania
laboratoryjnego
09.05.2011
1.1
Tomasz Kowalski
Aktualizacja treści, dodanie ilustracji i zadania z gwiazdką
17.05.2011
1.2
Tomasz Kowalski
Drobne poprawki
02.03.2012
1.3
Tomasz Kowalski
Zmiana wzorca
12.05.2012
1.4
Tomasz Kowalski
Poprawa diagramu UML
15.05.2012
1.5
Tomasz Kowalski
Uzupełnienie ilustracji z diagramem UML i aktualizacja
22.05.2013
2.0
Tomasz Kowalski
Aktualizacja w związku z reorganizacją laboratorium
11.06.2013
2.1
Tomasz Kowalski
Doprecyzowanie zadania z wzorcem observer
26.04.2014
2.2
Tomasz Kowalski
Aktualizacja Observera (obowiązkowy!)
1. Cel laboratorium
Głównym celem laboratoriów jest zapoznanie się ze strukturalnym wzorcami projektowymi
Decorator i Observer. Zajęcia powinny pomoc studentom rozpoznawać omawiane wzorce w
projektach informatycznych, samodzielnie implementować wzorce oraz dokonywać odpowiednich
modyfikacji wzorca w zależności od potrzeb projektu.
2. Laboratorium:
Laboratorium jest kontynuacją poprzednich laboratoriów dotyczących wzorców adapter i
command. Rozwiązanie poniższych zadań należy utworzyć w nowych pakietach, których nazwy
będą odpowiadać stosowanym wzorcom projektowym (np. edu.kis.powp.decorator).
Kolejnym pomysłem szefa jest opracowanie rozwiązania dotyczącego kontroli poziomu tuszu w
ploterze. Prace nad rzeczywistym sterownikiem plotera wykazały, że nie będzie możliwe uzyskanie
dostępu do informacji o tuszu bezpośrednio z plotera. Zgodnie z wskazówkami szefa kontrola tuszu
powinna być możliwa zarówno w trybie rzeczywistego użycia plotera jak i podczas symulacji, a
abstrakcje korzystające ze sterowników (klienci sterownika) nie muszą być świadome o
zaimplementowanym mechanizmie.
Szef (bazując na swoich wieloletnich doświadczeniach w projektowaniu systemów) prosi Cię o
opracowanie nowego rozwiązania w oparciu o uproszczony wzorzec decorator (patrz ilustracja 1)
zgodnie z następującymi wytycznymi:
• ilość tuszu powinna być mierzona w jednostkach długości rysowanych linii,
•
na potrzeby symulacji przy braku tuszu ploter powinien przesuwać swoją pozycję nie
rysując do momentu doładowania,
•
szef dodatkowo wspomniał, że mile widziane byłoby powiadomienie ostrzegające o
kończącym się poziomie tuszu.
Ilustracja 1: Diagram UML uproszczonego wzorca decorator i kontroli tuszu.
1. Przed zastosowaniem wzorca decorator zaimplementuj prosty menadżer do kontroli
poziomu tuszu realizujący interfejs IMenadzerTuszu, który będzie zapewniał możliwość:
ładowania, pobierania oraz sprawdzania poziomu tuszu. Klasa ta ma wyłącznie udostępniać
w/w funkcjonalność (np. ładowanie tuszu przez klienta).
2. Wykorzystując wzorzec decorator zaimplementuj sterownik SterownikDecorator (w
hierarchii sterowników), który korzystając z menadżera tuszu będzie realizował
funkcjonalność kontroli ilości tonera w ploterze (bądź w jego symulatorze). *Jaka nazwa tej
klasy będzie bardziej odpowiednia.
3. Zaimplementuj test pokazujący możliwości mechanizmu kontroli tuszu. Wykorzystaj
rozwiązania z poprzedniego laboratorium (tj. polecenia i ich fabryki).
4. Na potrzeby symulacji pakietem Rysownik zmodyfikuj decorator, aby po zakończeniu
tonera narysowane linii nadal były widoczne, ale np. rysując cienką przerywaną linią.
5. *W kontekście projektu wymień i wyjaśnij zalety refaktoryzacji funkcjonalności kontroli
poziomu tuszu do wzorca decorator.
6. *W trosce o większą generyczność opracowanego rozwiązania dokonaj refaktoryzacji do
bardziej złożonej wersji wzorca decorator. Zaimplementuj osłonę do kontroli tuszu oraz
przykładową osłonę o innej wymyślonej przez Ciebie funkcjonalności.
Bazując na ilustracji 2 zaimplementuj przy użyciu wzorca observer mechanizmy opisane w
kolejnych punktach.
7. Zmiany typu linii w przypadku braku lub doładowaniu tuszu w dekorującym sterowniku
(observerem jest sterownik dekorujący).
8. W programie testującym zaimplementuj ostrzeżenie klienta o braku tuszu poprzez (możesz
skorzystać ze swingowej fasady JOptionPane). Powiadomienie może oferować opcję
doładowania tuszu.
Wskazówka: program testowy (tzn. klient) może tworzyć odpowiedniego observera jako
instancję klasy anonimowej (podobnie jak w typowej obsłudze zdarzeń1).
Ilustracja 2: Diagram UML wzorca observer i kontroli tuszu.
1 http://docs.oracle.com/javase/tutorial/java/javaOO/anonymousclasses.html#examples-of-anonymous-classes