Transcript dsaasdasdas
Szkolenie dla NaviExpert, 21.02.2011
Wybrane wzorce projektowe Gang of Four
Szkolenie dla NaviExpert, 21.02.2011
Agenda
1.
Motywacja dla stosowania i definiowania wzorców 2. Struktura wzorca projektowego 3.
Katalog wzorców projektowych Wzorce projektowe cz. I (2)
Szkolenie dla NaviExpert, 21.02.2011
Motywacja
Różne dziedziny inżynierii stawiają sobie podobne pytania: • Czy typowe problemy można rozwiązywać w powtarzalny sposób?
• Czy te problemy można przedstawić w sposób abstrakcyjny, tak aby były pomocne w tworzeniu rozwiązań w różnych konkretnych kontekstach?
Wzorce projektowe cz. I (3)
Szkolenie dla NaviExpert, 21.02.2011
Geneza wzorców
„Wzorzec opisuje problem , który powtarza się wielokrotnie w danym środowisku , oraz podaje istotę jego rozwiązania w taki sposób, aby można było je zastosować miliony razy bez potrzeby powtarzania tej samej pracy”
Christopher Alexander „A pattern language”, 1977
Wzorce projektowe cz. I (4)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce w budownictwie lądowym
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 ?
na podstawie przykładu R. Johnsona
Wzorce projektowe cz. I (5)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce w budownictwie lądowym
Czy zbudować most łukowy czy podwieszany ?
na podstawie przykładu R. Johnsona
Wzorce projektowe cz. I (6)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce w inżynierii oprogramowania
Wzorce w inżynierii oprogramowania • • wzorce architektoniczne komponentów
wzorce projektowe
– poziom integracji – poziom interakcji między klasami • wzorce analityczne – poziom opisu rzeczywistości • wzorce implementacyjne programowania – poziom języka Wzorzec projektowy identyfikuje i opisuje pewną abstrakcję, której poziom znajduje się powyżej poziomu abstrakcji pojedynczej klasy, instancji lub komponentu.
E. Gamma, R. Johnson, R. Helm, J. Vlissides, 1994
Wzorce projektowe cz. I (7)
Szkolenie dla NaviExpert, 21.02.2011
Systematyka wzorców projektowych
• • •
Wzorce kreacyjne
– abstrakcyjne metody tworzenia obiektów – uniezależnienie systemu od sposobu tworzenia obiektów
Wzorce strukturalne
– sposób wiązania obiektów w struktury – właściwe wykorzystanie dziedziczenia i kompozycji
Wzorce behawioralne
– algorytmy i przydział odpowiedzialności – opis przepływu kontroli i interakcji Wzorce projektowe cz. I (8)
Szkolenie dla NaviExpert, 21.02.2011
Szablon wzorca projektowego
• • Wzorzec projektowy jest opisany przez:
nazwę
– lakoniczny opis istoty wzorca • • klasyfikację – kategorię, do której wzorzec należy
cel
– do czego wzorzec służy • aliasy – inne nazwy, pod którymi jest znany • motywację – scenariusz opisujący problem i rozwiązanie • zastosowania stosowany – sytuacje, w których wzorzec jest
strukturę
wzorca – graficzną reprezentację klas składowych Wzorce projektowe cz. I (9)
Szkolenie dla NaviExpert, 21.02.2011
Szablon wzorca projektowego cd.
•
uczestników
– nazwy i odpowiedzialności klas składowych wzorca • współdziałania – opis współpracy między uczestnikami • •
konsekwencje
– efekty zastosowania wzorca • implementację języku – opis implementacji wzorca w danym
przykład
– kod stosujący wzorzec • pokrewne wzorce kontekście – wzorce używane w podobnym Wzorce projektowe cz. I (10)
Szkolenie dla NaviExpert, 21.02.2011
Katalog wzorców projektowych
• Katalog wzorców projektowych
Gang of Four
(Gamma, Johnson, Helm, Vlissides) obejmuje 23 wzorce: – kreacyjne :
Abstract Factory, Builder, Factory Method, Prototype, Singleton
– strukturalne :
Adapter, Bridge, Composite, Decorator, Composite, Facade, Proxy, Flyweight
– behawioralne :
Chain of Responsibility, Command, Interpreter, Mediator, Iterator, Memento, Observer, State, Strategy, Template Method, Visitor
• Lista wzorców jest sukcesywne uzupełniana przez innych autorów Wzorce projektowe cz. I (11)
Szkolenie dla NaviExpert, 21.02.2011
Singleton: cel
• Zapewnienie, że klasa posiada jedną instancję wewnątrz całej aplikacji • Stworzenie punktu dostępowego do tej instancji
Gang of Four
Wzorce projektowe cz. I (12)
Szkolenie dla NaviExpert, 21.02.2011
Singleton: struktura i uczestnicy
Singleton
– definiuje statyczną metodę
getInstance()
udostępniającą instancję klasy – ogranicza dostęp do konstruktora do własnej klasy i podklas – jest odpowiedzialny za tworzenie instancji własnej klasy Wzorce projektowe cz. I (13)
Szkolenie dla NaviExpert, 21.02.2011
Singleton: konsekwencje
• Singleton przejmuje odpowiedzialność za tworzenie instancji własnej klasy • Klient nie zarządza instancją klasy ; otrzymuje ją na żądanie • Singleton może zarządzać także swoimi podklasami • Singleton można łatwo rozszerzyć do puli obiektów • Singleton jest zwykle obiektem bezstanowym • Singleton zachowuje się podobnie do zmiennej globalnej • Singleton może powodować zwiększenie liczby powiązań w systemie Wzorce projektowe cz. I (14)
Szkolenie dla NaviExpert, 21.02.2011
Singleton: implementacja 2PL
static public Tax getInstance() { if (instance == null) { synchronize (this) { if (instance == null) { instance == new TaxA(); } } } return instance; }
Istnienie obiektu
instance
jest sprawdzane dwukrotnie, na zewnątrz i wewnątrz bloku synchronizacji
Shalloway & Trott (2001)
Wzorce projektowe cz. I (15)
Szkolenie dla NaviExpert, 21.02.2011
Singleton: implementacja z
class loaderami
public class TaxA extends Tax { private static class Instance { static final Tax instance = new TaxA(); } } private TaxA() {} public static Taxt getInstance() { return Instance.instance; }
Class loader
ładuje pojedynczą klasę
TaxA.Instance
, która przechowuje pojedynczą instancję klasy
Tax Shalloway & Trott (2001)
Wzorce projektowe cz. I (16)
Szkolenie dla NaviExpert, 21.02.2011
Pool of Objects: cel
• Zarządzanie grupą obiektów reprezentujących zasoby wielokrotnego użycia • Ograniczenie kosztów tworzenia i usuwania obiektów
Shalloway & Trott (2001)
Wzorce projektowe cz. I (17)
Szkolenie dla NaviExpert, 21.02.2011
Pool of Objects: struktura
Wzorce projektowe cz. I (18)
Szkolenie dla NaviExpert, 21.02.2011
Pool of Objects: uczestnicy
• • •
Pool
– definiuje punkt dostępu do obiektów
Reusable Object
– zarządza cyklem życia obiektów
Reusable Object
Reusable Object
– definiuje swój cykl życia – może być powtórnie wykorzystany
Client
– otrzymuje obiekty
Reusable Object
obiektu
Pool
za pośrednictwem Wzorce projektowe cz. I (19)
Szkolenie dla NaviExpert, 21.02.2011
Pool of Objects: konsekwencje
• Zwiększona wydajność – obiekty
ReusableObject
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
ReusableObject
Wzorce projektowe cz. I (20)
Szkolenie dla NaviExpert, 21.02.2011
Observer: cel
• Utworzenie zależności typu jeden-wiele pomiędzy obiektami • Informacja o zmianie stanu wyróżnionego obiektu jest przekazywana wszystkim pozostałym obiektom
Gang of Four
Wzorce projektowe cz. I (21)
Szkolenie dla NaviExpert, 21.02.2011
Observer: struktura
Wzorce projektowe cz. I (22)
Szkolenie dla NaviExpert, 21.02.2011
Observer: uczestnicy
• • • •
Subject
– utrzymuje rejestr obiektów
Observer
– umożliwia dołączanie i odłączanie obiektów
Observer
Observer
– udostępnia interfejs do powiadamiania o zmianach
Concrete Subject
– przechowuje stan istotny dla obiektów
Concrete Observer
– powiadamia obiekty
Concrete Observer
Concrete Observer
– aktualizuje swój stan na podstawie powiadomienia Wzorce projektowe cz. I (23)
Szkolenie dla NaviExpert, 21.02.2011
Observer: konsekwencje
• Luźniejsze powiązania pomiędzy obiektami: – obiekt
Subject
komunikuje się z innymi obiektami przez interfejs
Observer
– obiekty
Subject
i warstw abstrakcji
Observers
mogą należeć do • Programowe rozgłaszanie komunikatów różnych • Spójność stanu pomiędzy obiektami
Subject
• Skalowalność aktualizacji i
Observers
– push :
Observers
Subject otrzymują kompletny stan obiektu – pull :
Observers
otrzymują powiadomienie i referencję do obiektu
Subject
Wzorce projektowe cz. I (24)
Szkolenie dla NaviExpert, 21.02.2011
Adapter: cel
• Umożliwienie współpracy obiektów o niezgodnych typach • Tłumaczenie protokołów obiektowych
Gang of Four
Wzorce projektowe cz. I (25)
Szkolenie dla NaviExpert, 21.02.2011
Adapter: struktura
Wzorce projektowe cz. I (26)
Szkolenie dla NaviExpert, 21.02.2011
Adapter: uczestnicy
• • • •
Target
– definiuje interfejs specyficzny dla klienta
Client
– współpracuje z obiektami typu
Target
Adaptee
– posiada interfejs wymagający adaptacji
Adapter
– adaptuje interfejs
Adaptee
do interfejsu
Target
Wzorce projektowe cz. I (27)
Szkolenie dla NaviExpert, 21.02.2011
Adapter: konsekwencje • Duża elastyczność – pojedynczy
Adapter
może współpracować z wieloma obiektami
Adaptee
naraz –
Adapter Adaptee
może dodawać funkcjonalność do (zob. wzorzec
Decorator
) • Utrudnione pokrywanie metod
Adaptera
– konieczne utworzenie podklas obiektu
Adaptee
i bezpośrednie odwołania do nich • Kompozycja i dziedziczenie jako mechanizmy adaptacji
Wzorce projektowe cz. I (28)
Szkolenie dla NaviExpert, 21.02.2011
Composite: cel • Organizowanie obiektów w struktury drzewiaste reprezentujące relacje typu całość-część • Jednolita obsługa złożonych struktur pojednczych obiektów i
Gang of Four
Wzorce projektowe cz. I (29)
Szkolenie dla NaviExpert, 21.02.2011
Composite: struktura
Wzorce projektowe cz. I (30)
Szkolenie dla NaviExpert, 21.02.2011
Composite: uczestnicy
• • •
Component
– deklaruje wspólny interfejs dla obiektów znajdujących się strukturze – implementuje wspólną funkcjonalność wszystkich obiektów
Leaf
– reprezentuje węzeł bez potomków
Composite
– reprezentuje węzeł z potomkami – przechowuje referencje do potomków – deleguje otrzymane polecenia do potomków Wzorce projektowe cz. I (31)
Szkolenie dla NaviExpert, 21.02.2011
Composite: konsekwencje
• Elastyczna definicja struktur drzewiastych • Proste dodawanie nowych komponentów • Proste i spójne zarządzanie strukturą o dowolnej liczbie elementów Wzorce projektowe cz. I (32)
Szkolenie dla NaviExpert, 21.02.2011
Proxy: cel
• Dostarczenie zamiennika dla obiektu w celu jego kontroli i ochrony • Przezroczyste odsunięcie inicjalizacji obiektu w czasie
Gang of Four
Wzorce projektowe cz. I (33)
Szkolenie dla NaviExpert, 21.02.2011
Proxy: struktura
Wzorce projektowe cz. I (34)
Szkolenie dla NaviExpert, 21.02.2011
Proxy: uczestnicy
• • •
Proxy
– posiada referencję do obiektu
Real Subject
i deleguje do niego żądania – kontroluje dostęp do obiektu
Real Subject
– jest zamiennikiem
Real Subject
dla klienta
Subject
– definiuje wspólny interfejs dla
Proxy
i
Real Subject
Real Subject
– rzeczywisty obiekt wymagający kontroli i ochrony Wzorce projektowe cz. I (35)
Szkolenie dla NaviExpert, 21.02.2011
Proxy: konsekwencje
• Zdalny obiekt
Proxy
jest lokalnym reprezentantem obiektu znajdującego się w innej przestrzeni adresowej • Wirtualny obiekt
Proxy
pełni rolę zamiennika dla obiektu o dużch wymaganiach zasobowych (np. pamięciowych) • Ochronny obiekt
Proxy
odostępnia obiekt
Real Subject
tylko uprawnionym obiektom Wzorce projektowe cz. I (36)
Szkolenie dla NaviExpert, 21.02.2011
Command: cel
• Hermetyzacja poleceń do wykonania w postaci obiektów • Umożliwienie parametryzacji klientów obiektami poleceń • Wsparcie dla poleceń odwracalnych
E. Gamma et al. (1995)
Wzorce projektowe cz. I (37)
Szkolenie dla NaviExpert, 21.02.2011
Command: struktura
Wzorce projektowe cz. I (38)
Szkolenie dla NaviExpert, 21.02.2011
Command: interakcje
command : Command new Command() storeCommand(command) configure(receiver) execute( ) action( ) receiver : Receiver Wzorce projektowe cz. I (39)
Szkolenie dla NaviExpert, 21.02.2011
Command: uczestnicy
• • • • •
Command
– definiuje interfejs obiektu reprezentującego polecenie
Concrete Command
– jest powiązany z właściwym obiektem
Receiver
– implementuje akcję w postaci metody
execute()
Client
– tworzy
Concrete Command
Invoker
– ustala odbiorcę akcji każdego obiektu
Command
– wywołuje metodę
execute()
obiektu
Command
Receiver
– jest przedmiotem akcji wykonanej przez
Command
Wzorce projektowe cz. I (40)
Szkolenie dla NaviExpert, 21.02.2011
Command: konsekwencje
• Usunięcie powiązania między nadawcą i przedmiotem polecenia • Łatwe dodawanie kolejnych obiektów
Command
• Możliwość manipulacji obiektami
Command
– polecenia złożone : wzorzec
Composite
• Polecenia mogą być odwracalne – zapamiętanie stanu przez
Concrete Command
– wykorzystanie wzorca
Memento
Wzorce projektowe cz. I (41)
Szkolenie dla NaviExpert, 21.02.2011
Command: przykład
Wzorce projektowe cz. I (42)
Szkolenie dla NaviExpert, 21.02.2011
Command: przykład cd.
public class Bank { // Invoker, Client public void income(Account acc, long amount) { Operation oper = new Income(amount); acc.doOperation(oper); } } public void transfer(Account from, Account to, long amount){ Operation oper = new Transfer(to, amount); from.doOperation(oper); } public class Account { // Reciever long balance = 0; Interest interest = new InterestA(); History history = new History(); public void doOperation(Operation oper) { oper.execute(this); history.log(oper); } }
Wzorce projektowe cz. I (43)
Szkolenie dla NaviExpert, 21.02.2011
Command: przykład cd.
abstract public class Operation { // Command public void execute(); } public class Income { // ConcreteCommand1 public Income(long amount) { // store parameters...
} public void execute(Account acc) { acc.add(amount); } } public class Transfer { // ConcreteCommand2 public Income(Account to, long amount) { // store parameters...
} public void execute(Account from) { from.subtract(amount); to.add(amount); } }
Wzorce projektowe cz. I (44)
Szkolenie dla NaviExpert, 21.02.2011
Factory Method: cel
• Zdefiniowanie interfejsu do tworzenia obiektów • Umożliwienie przekazania odpowiedzialności za tworzenie obiektów do podklas • Umożliwienie wyboru klasy i konstruktora użytego do utworzenia obiektu
E. Gamma et al. (1995)
Wzorce projektowe cz. I (45)
Szkolenie dla NaviExpert, 21.02.2011
Factory Method: struktura
Wzorce projektowe cz. I (46)
Szkolenie dla NaviExpert, 21.02.2011
Factory Method: uczestnicy
• • • •
Product
– definiuje interfejs obiektów tworzonych przez
Factory Method
Concrete Product
– specyficzny produkt tworzony przez
Factory Method
Creator
– definiuje interfejs do tworzenia obiektów typu
Product
Concrete Creator
– tworzy obiekt typu
Concrete Product
Wzorce projektowe cz. I (47)
Szkolenie dla NaviExpert, 21.02.2011
Factory Method: konsekwencje
• Przeniesienie odpowiedzialności
Product
z klienta na obiekt za tworzenie obiektów
Creator
• Możliwość rozszerzania hierarchii klas
Product
niezależnie od klienta Wzorce projektowe cz. I (48)
Szkolenie dla NaviExpert, 21.02.2011
Abstract Factory: cel
• Stworzenie interfejsu do tworzenia grup powiązanych ze sobą produktów • Rozszerzenie
Factory Method
na grupy produktów
E. Gamma et al. (1995)
Wzorce projektowe cz. I (49)
Szkolenie dla NaviExpert, 21.02.2011
Abstract Factory: struktura
Wzorce projektowe cz. I (50)
Szkolenie dla NaviExpert, 21.02.2011
Abstract Factory: uczestnicy
• • • •
Abstract Factory
– definiuje interfejs do tworzenia obiektów
Abstract Product
Concrete Factory
– tworzy obiekty
Concrete Product
należące do jednej grupy
Abstract Product
– deklaruje interfejs obiektów
Product
Concrete Product
– definiuje obiekt
Product
Wzorce projektowe cz. I (51)
Szkolenie dla NaviExpert, 21.02.2011
Abstract Factory: konsekwencje
• Łatwa zmiana całych grup produktów używanej
Concrete Factory
poprzez zmianę • Wydzielenie interfejsu do tworzenia obiektów • Odseparowanie klienta od szczegółów implementacji obiektów
Product
• Utrudnione dodawanie kolejnych obiektów
Product
we wszystkich grupach Wzorce projektowe cz. I (52)
Szkolenie dla NaviExpert, 21.02.2011
Chain of Responsibility: cel
• Usunięcie powiązania pomiędzy nadawcą i odbiorcą żądania • Umożliwienie wielu obiektom obsługi żądania
E. Gamma et al. (1995)
Wzorce projektowe cz. I (53)
Szkolenie dla NaviExpert, 21.02.2011
Chain of Responsibility: struktura
Obiekty
Handler
tworzą listę jednokierunkową (łańcuch), wzdłuż której są przekazywane żądania.
Wzorce projektowe cz. I (54)
Szkolenie dla NaviExpert, 21.02.2011
Chain of Responsibility: uczestnicy
• • •
Handler
– definiuje interfejs do obsługi żądań
Concrete Handler
– obsługuje jeden rodzaj żądania, pozostałe przekazuje do następnika w łańcuchu – posiada referencję typu
Handler
do następnika
Client
– inicjuje przetwarzanie, przekazując żądanie do pierwszego obiektu
Handler
w łańcuchu Wzorce projektowe cz. I (55)
Szkolenie dla NaviExpert, 21.02.2011
Chain of Responsibility: konsekwencje
• Ograniczone powiązania – Klient i każdy obiekt
Handler
nie wiedzą, który z pozostałych obiektów
Handler
obsługuje dany typ żądania – nadawca i odbiorca żądania nie mają o sobie żadnej wiedzy • Możliwość elastycznego przydziału odpowiedzialności do obiektów
Handler
• Ułatwione testowanie • Brak gwarancji obsłużenia żądania Wzorce projektowe cz. I (56)
Szkolenie dla NaviExpert, 21.02.2011
Chain of Responsibility: przykład 1
Obiekt
Inbox
wywołuje pierwszy obiekt
Filter
Kolejne filtry przekazują sobie sterowanie w łańcuchu. Wzorce projektowe cz. I (57)
Szkolenie dla NaviExpert, 21.02.2011
Chain of Responsibility: przykład 2
Obiekt
Inbox
drugiego.
wywołuje kolejno obiekty
Filter
. Nie występuje bezpośrenie przekazywanie sterowania z jednego filtra do Wzorce projektowe cz. I (58)
Szkolenie dla NaviExpert, 21.02.2011
Facade: cel
• Dostarczenie jednorodnego interfejsu wyższego poziomu do zbioru różnych interfejsów w systemie • Ukrycie złożoności podsystemów przed klientem
E. Gamma et al. (1995)
Wzorce projektowe cz. I (59)
Szkolenie dla NaviExpert, 21.02.2011
Client
Facade: struktura
Facade Subsystem2 Subsystem3 Subsystem1 Klient może odwołać się zarówno do obiektu
Facade
, jak i bezpośrednio do podsystemów Wzorce projektowe cz. I (60)
Szkolenie dla NaviExpert, 21.02.2011
Facade: uczestnicy
• •
Facade
– zna zakres odpowiedzialności poszczególnych podsystemów – deleguje żądania klienta do podsystemów
subsystems
– nie wiedzą o obiekcie
Facade
– wykonują żądania od klienta i obiektu
Facade
Wzorce projektowe cz. I (61)
Szkolenie dla NaviExpert, 21.02.2011
Facade: konsekwencje
• Odseparowanie klienta od podsystemów – łatwiejsze korzystanie z podsystemów – niższe koszty pielęgnacji podsystemów – możliwość wymiany/rozbudowy podsystemów • Elastyczny dostęp do podsystemów – klient może odwołać się do obiektu
Facade
bezpośrednio do podsystemów lub Wzorce projektowe cz. I (62)
Szkolenie dla NaviExpert, 21.02.2011
Facade: przykład
public class Email { // facade MimeMessage msg = null; // podsystem 1 Session session = Session.getInstance(null, props); // podsystem 2 public Email(String subject, String text) { msg = new MimeMessage(session); msg.setFrom(DEFAULT_FROM); msg.setSubject(subject); msg.setText(text, "UTF-8"); } public void sendTo(String[] to) { msg.setRecipients(Message.RecipientType.TO, convert(to)); Transport transport = session.getTransport("smtp"); transport.sendMessage(msg, msg.getAllRecipients() } public void sendTo(String[] to, String[] cc) { msg.setRecipients(Message.RecipientType.TO, convert(to)); msg.setRecipients(Message.RecipientType.CC, convert(Cc)); Transport transport = session.getTransport("smtp"); transport.sendMessage(msg, msg.getAllRecipients() } }
Wzorce projektowe cz. I (63)
Szkolenie dla NaviExpert, 21.02.2011
Builder: cel
• Odseparowanie sposobu reprezentacji i metody konstrukcji złożonych struktur obiektowych • Wykorzystanie jednego mechanizmu konstrukcyjnego do tworzenia struktur o różnej reprezentacji
E. Gamma et al. (1995)
Wzorce projektowe cz. I (64)
Szkolenie dla NaviExpert, 21.02.2011
Builder: struktura
Klient
zleca prace,
Director
zna sposób reprezentacji, a obiekty typu
Builder
tworzą specjalizowane obiekty typu
Product
.
Wzorce projektowe cz. I (65)
Szkolenie dla NaviExpert, 21.02.2011
Builder: uczestnicy
• • • •
Builder
– definiuje interfejs do tworzenia obiektów typu
Product
Concrete Builder
– tworzy specjalizowany obiekt typu
Product
Director
– zna sposób realizacji struktury i jej algorytm – zarządza grupą obiektów
Builder
wykonanie obiektów
Product
i podzleca im
Product
– reprezentuje element składowy struktury – posiada interfejs umożliwiający łączenie z innymi obiektami
Product
Wzorce projektowe cz. I (66)
Szkolenie dla NaviExpert, 21.02.2011
Builder: konsekwencje
• Zmiana implementacji obiektów
Product
nie wpływa na proces konstrukcji struktury • Odseparowanie reprezentacji i konstrukcji struktur obiektowych • Precyzyjna kontrola nad procesem konstrukcji struktury • Ułatwione testowanie elementów struktury Wzorce projektowe cz. I (67)
Szkolenie dla NaviExpert, 21.02.2011
Memento: cel
• Umożliwienie zachowania stanu obiektu na zewnątrz w celu jego późniejszego odtworzenia • Zachowanie hermetyzacji tego obiektu
E. Gamma et al. (1995)
Wzorce projektowe cz. I (68)
Szkolenie dla NaviExpert, 21.02.2011
Memento: struktura
Originator
zapisuje i odtwarza swój stan w postaci obiektu
Memento
. Obiekt
Caretaker
przechowuje obiekty
Memento
, ale nie ma dostępu do ich danych Wzorce projektowe cz. I (69)
Szkolenie dla NaviExpert, 21.02.2011
Memento: uczestnicy
• • •
Memento
– przechowuje zapisany stan obiektu
Originator
– uniemożliwia dostęp do tego stanu obiektowi
Caretaker
Originator
– tworzy obiekt
Memento
ze swoim aktualnym stanem – odtwarza stan na podstawie obiektu
Memento
Caretaker
– przechowuje obiekty
Memento
– nie ma dostępu do ich zawartości Wzorce projektowe cz. I (70)
Szkolenie dla NaviExpert, 21.02.2011
Memento: konsekwencje
• Zachowanie hermetyzacji obiektu
Memento
• Uproszczenie obiektu
Originator
– odpowiedzialność za zapis stanu przeniesiona na
Memento
• Podwójny interfejs obiektu Memento – wąski : dla obiektu
Caretaker
– szeroki : dla obiektu
Originator
• Potencjalny wzrost złożoności pamięciowej – stan może być obszerny –
Caretaker
nie zna tego rozmiaru i nie może optymalizować sposobu zarządzania nim Wzorce projektowe cz. I (71)
Szkolenie dla NaviExpert, 21.02.2011
Memento: implementacja
Realizacja podwójnego interfejsu wymaga wsparcia ze strony języka programowania –
Java
: klasy wewnętrzne – Klasa wewnętrzna jest znana tylko swojej klasie zewnętrznej
C++:
klasy zaprzyjaźnione Klasy zaprzyjaźnione są uprzywilejowane w dostępie do swoich składowych niepublicznych Wzorce projektowe cz. I (72)
Szkolenie dla NaviExpert, 21.02.2011
Memento: przykład
public class Account { private int balance = 0; public void credit(int amount) { balance += amount; } public void debit(int amount) { balance -= amount; } public void setMemento(Memento memento) { memento.restoreState(); } public Memento createMemento() { Memento mementoToReturn = new Memento(); mementoToReturn.setState(); return mementoToReturn; }
Wzorce projektowe cz. I (73)
Szkolenie dla NaviExpert, 21.02.2011
Memento: przykład cd.
public class Account { // continued...
class Memento { int mementoBalance = 0; private void setState() { mementoBalance = balance; } private void restoreState() { balance = mementoBalance; } } }
Prywatna klasa wewnętrzna pozwala osiągnąć efekt podwójnego interfejsu: tylko klasa zewnętrzna może odwoływać się do jej stanu Wzorce projektowe cz. I (74)
Szkolenie dla NaviExpert, 21.02.2011
Prototype: cel
Umożliwienie tworzenia obiektów na podstawie przykładowej instancji, a nie poprzez wywołanie konstruktora
E. Gamma et al. (1995)
Wzorce projektowe cz. I (75)
Szkolenie dla NaviExpert, 21.02.2011
Prototype: struktura
Wywołanie metody
clone()
powoduje utworzenie dokładnej kopii przekazanego obiektu
Prototype
.
Wzorce projektowe cz. I (76)
Szkolenie dla NaviExpert, 21.02.2011
Prototype: uczestnicy
• •
Prototype
– deklaruje metodę
clone()
– znacznik obiektów, które mogą się sklonować
Concrete Prototype
– implementuje metodę
clone()
tworzącą klon własnego obiektu Wzorce projektowe cz. I (77)
Szkolenie dla NaviExpert, 21.02.2011
Prototype: konsekwencje
• Możliwość tworzenia obiektów poprzez przykład • Uproszczona konstrukcja podobnych obiektów – pominięcie wyboru konstruktora – ograniczenie liczby podklas w systemie Wzorce projektowe cz. I (78)
Szkolenie dla NaviExpert, 21.02.2011
Prototype: przykład
public class Employee implements Cloneable private String name = null; { public Employee(String name) { this.name = name; } public Object clone() throws CloneNotSupportedException { // tutaj: specyficzne operacje związane z klonowaniem return super.clone(); } } Employee emp = new Employee("John Smith"); Employee emp2 = (Employee) emp.clone(); assertEquals(emp, emp2);
Wzorce projektowe cz. I (79)
Szkolenie dla NaviExpert, 21.02.2011
State/Strategy: cel
• •
State
– umożliwienie zmiany zachowania obiektu w momencie zmiany jego stanu – pozorna zmiana klasy obiektu
Strategy
– umożliwienie zmiany algorytmu realizacji pewnej funkcji – algorytmy są wymienne
E. Gamma et al. (1995)
Wzorce projektowe cz. I (80)
Szkolenie dla NaviExpert, 21.02.2011
State/Strategy: struktura
Stan jest obiektem. Zmiana stanu oznacza zmianę obiektu go reprezentującego. Delegowane do niego metody są wywoływane polimorficznie.
Wzorce projektowe cz. I (81)
Szkolenie dla NaviExpert, 21.02.2011
State/Strategy: uczestnicy
• • •
Context
– posiada referencję do obiektu reprezentującego bieżący stan
State
– definiuje interfejs pozwalający hermetyzować zachowanie związane z każdym stanem
Concrete State
– definiuje własne metody implementujące zachowanie specyficzne dla tego stanu Wzorce projektowe cz. I (82)
Szkolenie dla NaviExpert, 21.02.2011
State/Strategy: 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 Wzorce projektowe cz. I (83)
Szkolenie dla NaviExpert, 21.02.2011
State: przykład
public class Account { private int balance = 0; private String owner = null; private boolean isOpen = false; } public Account(String owner, int balance) { this.owner = owner; this.balance = balance; this.isOpen = true; } public void credit(int amount) { if (isOpen) { balance += amount; } else { alert("Konto nieaktywne!"); } }
Wzorce projektowe cz. I (84)
Szkolenie dla NaviExpert, 21.02.2011
State: przykład cd.
public interface AccountState { public void credit(Account acc, int amount); } public class AccountOpen implements AccountState public void credit(Account acc, int amount) { acc.balance += amount; { } } public class AccountClosed implements AccountState public void credit(Account acc, int amount) { alert("The account is closed!"); } } {
Wzorce projektowe cz. I (85)
Szkolenie dla NaviExpert, 21.02.2011
State: przykład cd.
public class Account { private int balance = 0; private String owner = null; private AccountState state = null; } public Account(String owner, int balance) { this.owner = owner; this.balance = balance; this.state = new AccountOpen(); } public void credit(int amount) { this.state.credit(this, amount); // delegacja } public void close() { this.state = new AccountClosed(); }
Wzorce projektowe cz. I (86)
Szkolenie dla NaviExpert, 21.02.2011
Strategy: przykład
Sorter
strategia to jeden algorytm. Zmiana strategii nie wpływa na obiekt zleca operację wybranej strategii sortowania. Każda
Sorter
.
Wzorce projektowe cz. I (87)
Szkolenie dla NaviExpert, 21.02.2011
Decorator: cel
• Umożliwienie dynamicznego dodawania funkcjonalności do obiektu • Stworzenie elastycznej alternatywy dla tworzenia podklas
E. Gamma et al. (1995)
Wzorce projektowe cz. I (88)
Szkolenie dla NaviExpert, 21.02.2011
Decorator: struktura
Klient wysyła komunikat do obiektu
Decorator
, który przekazuje go obiektowi
ConcreteComponent
oraz wykonuje dodatkowe operacje („dekoracje”) Wzorce projektowe cz. I (89)
Szkolenie dla NaviExpert, 21.02.2011
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. I (90)
Szkolenie dla NaviExpert, 21.02.2011
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 się zmieniać z którym komunikuje się klient wskutek dekoracji może • Łatwiejsze testowanie poszczególnych dekoratorów Wzorce projektowe cz. I (91)
Szkolenie dla NaviExpert, 21.02.2011
Bridge: cel
• Oddzielenie interfejsu i implementacji obiektu, tak aby mogły zmieniać się niezależnie od siebie • Realizacja funkcji interfejsu niezależnie od możliwości języka programowania
Gang of Four
Wzorce projektowe cz. I (92)
Szkolenie dla NaviExpert, 21.02.2011
Bridge: struktura
Wzorce projektowe cz. I (93)
Szkolenie dla NaviExpert, 21.02.2011
Bridge: uczestnicy
• • • •
Abstraction
– definiuje interfejs zewnętrzny (abstrakcję) – posiada referencję do obiektu typu
Implementor
– deleguje żądania do obiektu typu
Implementor
Refined Abstraction
– rozszerza interfejs
Abstraction
Implementor
– definiuje interfejs wewnętrzny (implementację) – niespokrewniony z typem
Abstraction
Concrete Implementor
– implementuje typ
Implementor
Wzorce projektowe cz. I (94)
Szkolenie dla NaviExpert, 21.02.2011
Bridge: konsekwencje
• Usunięcie zależności klienta od implementacji • Wprowadzenie podziału na niezależne interfejs (
Abstraction
) i implementację (
Implementor
) • Możliwość niezależnego rozszerzania typów
Abstraction
i
Implementor
Wzorce projektowe cz. I (95)
Szkolenie dla NaviExpert, 21.02.2011
Flyweight: cel
• Współdzielenie obiektów w celu zwiększenia wydajności • Wydzielenie z obiektu stanu wewnętrznego (współdzielonego) i zewnętrznego (specyficznego)
E. Gamma et al. (1995)
Wzorce projektowe cz. I (96)
Szkolenie dla NaviExpert, 21.02.2011
Flyweight: struktura
Wzorce projektowe cz. I (97)
Szkolenie dla NaviExpert, 21.02.2011
Flyweight: uczestnicy
• • • •
Flyweight
– podlega współdzieleniu między klientów – definiuje interfejs do przyjmowania i odtwarzania stanu zewnętrznego obiektu
Concrete Flyweight
– przechowuje stan wewnętrzny (współdzielony) – jest niezależny od kontekstu (z wyjątkiem stanu zewnętrznego)
Flyweight Factory
– tworzy i przechowuje obiekty
Flyweight
Client
– otrzymuje obiekty
Flyweight
za pośrednictwem
Flyweight Factory
Wzorce projektowe cz. I (98)
Szkolenie dla NaviExpert, 21.02.2011
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 Wzorce projektowe cz. I (99)
Szkolenie dla NaviExpert, 21.02.2011
Mediator: cel
• Uproszczenie komunikacji wielu obiektów • Hermetyzacja mechanizmu wymiany komunikatów
E. Gamma et al. (1995)
Wzorce projektowe cz. I (100)
Szkolenie dla NaviExpert, 21.02.2011
Mediator
+mediator
Mediator: struktura
Colleague
ConcreteColleague1 ConcreteColleague2 ConcreteMediator Obiekty
Colleague
i obiekt
Mediator
tworzą topologię gwiazdy. Komunikaty między obiektami
Colleague
są przekazywane za pośrednictwem mediatora Wzorce projektowe cz. I (101)
Szkolenie dla NaviExpert, 21.02.2011
Mediator: uczestnicy
• • •
Mediator
– definiuje interfejs dołączania i odłączania kolegów
Concrete Mediator
– implementuje mechanizm komunikacji pomiędzy obiektami
Colleague
– posiada referencje do zarejestrowanych obiektów
Colleague
Colleague
– definiuje wspólny interfejs dla komunikujących się obiektów – posiada referencję do obiektu
Mediator
– komunikuje się z innymi obiektami za pośrednictwem obiektu
Mediator
Wzorce projektowe cz. I (102)
Szkolenie dla NaviExpert, 21.02.2011
Mediator: konsekwencje
• Centralizacja mechanizmu komunikacji – wyłączna odpowiedzialność obiektu
Mediator
– zmiana mechanizmu wymaga tylko zmiany
Mediatora
– prostota komunikacji vs. złożoność
Mediatora
• Niezależność obiektów
Colleague
od siebie • Uproszczenie protokołów obiektowych – Zamiana relacji wiele-wiele na relacje jeden-wiele Wzorce projektowe cz. I (103)
Szkolenie dla NaviExpert, 21.02.2011
Mediator: przykład
public class Mediator { private boolean slotFull = false; private int number; } public synchronized void storeMessage(int num) { while (slotFull) { try { wait(); } catch (InterruptedException ex ) { } } number = num; slotFull = true; notifyAll(); } public synchronized int retrieveMessage() { while (slotFull) { try { wait(); } catch (InterruptedException ex ) { } } notifyAll(); slotFull = false; return number; } Wzorce projektowe cz. I (104)
Szkolenie dla NaviExpert, 21.02.2011
Mediator: przykład cd.
public class Producer extends Thread { private Mediator m; private int no; private static int count = 1; public Producer(Mediator m) { mediator = m; no = count++; } } public void run() { int num; while (true) { m.storeMessage(num = (int)(Math.random()*100)); System.out.print("p" + no + "-" + num + " "); } } Wzorce projektowe cz. I (105)
Szkolenie dla NaviExpert, 21.02.2011
Mediator: przykład cd.
public class Consumer extends Thread { private Mediator m; private int no; private static int count = 1; public Consumer(Mediator m) { count = m; id = count++; } } public void run() { while (true) { System.out.print("c" + no + "-" + m.retrieveMessage()); } } Wzorce projektowe cz. I (106)
Szkolenie dla NaviExpert, 21.02.2011
Template Method: cel
• Stworzenie szkieletu algorytmu w postaci klasy • Przesunięcie niektórych operacji do podklas
E. Gamma et al. (1995)
Wzorce projektowe cz. I (107)
Szkolenie dla NaviExpert, 21.02.2011
Template Method: struktura
Metody klasy
AbstractClass
są dziedziczone lub implementowane przez jej podklasy.
Metody odwołujące się do metod abstrakcyjnych są ukonkretniane w podklasach.
Wzorce projektowe cz. I (108)
Szkolenie dla NaviExpert, 21.02.2011
Template Method: uczestnicy
• •
Abstract Class
– definiuje szkielet algorytmu w postaci metody – szkielet odwołuje się do prostych metod abstrakcyjnych
Concrete Class
– implementuje proste metody abstrakcyjne – pokrywa inne, wybrane metody odziedziczone z
AbstractClass
Wzorce projektowe cz. I (109)
Szkolenie dla NaviExpert, 21.02.2011
Template Method: konsekwencje
• Odwrócona struktura odwołań – zasada hollywoodzka:
proszę nie dzwonić, to my oddzwonimy
– nadklasa odwołuje się do metod w podklasach
za Gang of Four
Wzorce projektowe cz. I (110)
Szkolenie dla NaviExpert, 21.02.2011
Iterator: cel
Umożliwienie sekwencyjnego dostępu do elementów kolekcji bez ujawniania jej wewnętrznej implementacji
E. Gamma et al. (1995)
Wzorce projektowe cz. I (111)
Szkolenie dla NaviExpert, 21.02.2011
Iterator: struktura
Każdy
Aggregate
tworzy specyficzny dla siebie iterator.
Klient odwołuje się do niego poprzez abstrakcyjny interfejs.
Wzorce projektowe cz. I (112)
Szkolenie dla NaviExpert, 21.02.2011
Iterator: uczestnicy
• • • •
Aggregate
– ogólny interfejs każdej kolekcji – deklaruje interfejs do tworzenia iteratora
Concrete Aggregate
– tworzy iterator specyficzny dla własnej struktury
Iterator
– definiuje interfejs sekwencyjnego dostępu do obiektu
Aggregate
(
getFirst()
,
getNext()
,
hasNext()
)
Concrete Iterator
– implemenetacja interfejsu
Iterator
specyficzna dla konkretnej kolekcji Wzorce projektowe cz. I (113)
Szkolenie dla NaviExpert, 21.02.2011
Iterator: konsekwencje
• Abstrakcyjny dostęp do elementów kolekcji • Niezależność od implementacji kolekcji • Możliwość współistnienia różnych iteratorów w jednej kolekcji • Możliwość istnienia wielu iteratorów naraz – każdy iterator przechowuje informacje o aktualnym przebiegu – iteratory są obiektami stanowymi Wzorce projektowe cz. I (114)
Szkolenie dla NaviExpert, 21.02.2011
Visitor: cel
• Reprezentacja operacji do wykonania na elementach heterogenicznej struktury • Realizacja operacji w sposób specyficzny dla typu odwiedzanego elementu • Umożliwienie tworzenia nowych operacji bez konieczności modyfikacji klas wewnątrz struktury
E. Gamma et al. (1995)
Wzorce projektowe cz. I (115)
Szkolenie dla NaviExpert, 21.02.2011
Visitor: struktura
Wzorce projektowe cz. I (116)
Szkolenie dla NaviExpert, 21.02.2011
Visitor: interakcje
accept() accept() visit() operationA( ) visit() operationB( ) Wzorce projektowe cz. I (117)
Szkolenie dla NaviExpert, 21.02.2011
Visitor: uczestnicy
• • •
Visitor
– definiuje przeciążone metody dla każdego obiektu
ConcreteElement
do odwiedzenia
Element
– definiuje metodę
accept()
przyjmującą obiekt
Visitor
jako parametr
Object Structure
– posiada iterator pozwalający na dostęp do każdego elementu struktury Wzorce projektowe cz. I (118)
Szkolenie dla NaviExpert, 21.02.2011
Visitor: konsekwencje
• Możliwość odwiedzenia obiektów niespokrewnionych ze sobą • Łatwe dodawanie nowych obiektów
Visitor
• Utrudnione dodawanie nowych typów
Element
– konieczność modyfikacji klasy
Visitor
i jej podklas • Możliwość zbierania informacji z elementów struktury w sposób dla nich specyficzny • Naruszenie hermetyzacji obiektów
Visitor
i
Element
– obiekty muszą odwoływać się do swoich publicznych metod Wzorce projektowe cz. I (119)
Szkolenie dla NaviExpert, 21.02.2011
Visitor: przykład
public class Bank { List
Szkolenie dla NaviExpert, 21.02.2011
Visitor: przykład cd.
public abstract class BankingProduct { } public interface Element { public BankingProduct accept(Report report); } public class Account extends BankingProduct implements Element { public BankingProduct accept(Report report) { if (isPriviliged(report)) { return report.visit(this); } return null; } } public class Credit extends BankingProduct implements Element { public BankingProduct accept(Report report) { return report.visit(this); } } Wzorce projektowe cz. I (121)
Szkolenie dla NaviExpert, 21.02.2011
Visitor: przykład cd.
public class Over1000Report implements Visitor { public BankingProduct visit(Account acc) { if (acc.balance > 1000) return acc; return null; } public BankingProduct visit(Credit credit) { if (credit.draft > 1000 && credit.isActive()) return credit; return null; } } public class PassAllReport implements Visitor { public BankingProduct visit(Account acc) { return this; } public BankingProduct visit(Credit credit) { return this; } } Wzorce projektowe cz. I (122)
Szkolenie dla NaviExpert, 21.02.2011
Podsumowanie
• Wzorce projektowe są gotowymi szablonami rozwiązań typowych problemów projektowych • Wzorzec posiada określony zestaw atrybutów • Katalog wzorców obiektowych stanowi elementarz projektanta oprogramowania Wzorce projektowe cz. I (123)