View
36
Download
0
Category
Preview:
DESCRIPTION
Szkolenie dla NaviExpert, 21.02.2011. Wybrane wzorce projektowe Gang of Four. Agenda. Motywacja dla stosowania i definiowania wzorców Struktura wzorca projektowego Katalog wzorców projektowych. Różne dziedziny inżynierii stawiają sobie podobne pytania: - PowerPoint PPT Presentation
Citation preview
Szkolenie dla NaviExpert, 21.02.2011
Wybrane wzorce projektoweGang of Four
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (2)
Agenda
1.Motywacja dla stosowania i definiowania wzorców
2.Struktura wzorca projektowego3.Katalog wzorców projektowych
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (3)
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?
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (4)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (5)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (6)
Wzorce w budownictwie lądowym
Czy zbudować most łukowy czy podwieszany?
na podstawie przykładu R. Johnsona
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (7)
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
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (8)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (9)
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 – sytuacje, w których wzorzec jest
stosowany• strukturę – graficzną reprezentację klas składowych
wzorca
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (10)
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ę – opis implementacji wzorca w danym
języku• przykład – kod stosujący wzorzec• pokrewne wzorce – wzorce używane w podobnym
kontekście
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (11)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (12)
Singleton: cel
• Zapewnienie, że klasa posiada jedną instancję wewnątrz całej aplikacji
• Stworzenie punktu dostępowego do tej instancji
Gang of Four
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (13)
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
Singleton
instancesingletonData
getInstance()singletonOperation()getSingletonData()Singleton()
return instance;
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (14)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (15)
Singleton: implementacja 2PL
Istnienie obiektu instance jest sprawdzane dwukrotnie, na zewnątrz i wewnątrz bloku synchronizacji
static public Tax getInstance() { if (instance == null) { synchronize (this) { if (instance == null) { instance == new TaxA(); } } } return instance;}
Shalloway & Trott (2001)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (16)
Singleton: implementacja z class loaderami
Class loader ładuje pojedynczą klasę TaxA.Instance, która przechowuje pojedynczą instancję klasy Tax
public class TaxA extends Tax { private static class Instance { static final Tax instance = new TaxA(); }
private TaxA() {} public static Taxt getInstance() { return Instance.instance; }}
Shalloway & Trott (2001)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (17)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (18)
Pool of Objects: struktura
Client
ReusableObject
Pool
Pool()getInstance()getObject()returnObject()size()
10..n
10..n
0..n
1
0..n
1
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (19)
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 za pośrednictwem
obiektu Pool
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (20)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (21)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (22)
Observer: struktura
Observer
update()
Subject
request()
ConcreteSubject
getState()setState()
ConcreteObserver
update()
for all observers { obs->update();}
observerState = subject->getState();
+obs
+subject
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (23)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (24)
Observer: konsekwencje
• Luźniejsze powiązania pomiędzy obiektami:– obiekt Subject komunikuje się z innymi obiektami
przez interfejs Observer– obiekty Subject i Observers mogą należeć do różnych
warstw abstrakcji• Programowe rozgłaszanie komunikatów• Spójność stanu pomiędzy obiektami Subject i Observers• Skalowalność aktualizacji
– push: Observers otrzymują kompletny stan obiektu Subject
– pull: Observers otrzymują powiadomienie i referencję do obiektu Subject
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (25)
Adapter: cel
• Umożliwienie współpracy obiektów o niezgodnych typach
• Tłumaczenie protokołów obiektowych
Gang of Four
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (26)
Adapter: struktura
Target
request()
Client
Adaptee
specificRequest()
Adapter
request()
adaptee->specificRequest()
+adaptee
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (27)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (28)
Adapter: konsekwencje
• Duża elastyczność– pojedynczy Adapter może współpracować z
wieloma obiektami Adaptee naraz– Adapter może dodawać funkcjonalność do
Adaptee (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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (29)
Composite: cel
• Organizowanie obiektów w struktury drzewiaste reprezentujące relacje typu całość-część
• Jednolita obsługa pojednczych obiektów i złożonych struktur
Gang of Four
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (30)
Composite: struktura
Leaf
operation()
Composite
operation()add()remove()getChild()
Component
operation()
Client +child
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (31)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (32)
Composite: konsekwencje
• Elastyczna definicja struktur drzewiastych• Proste dodawanie nowych komponentów• Proste i spójne zarządzanie strukturą o dowolnej liczbie
elementów
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (33)
Proxy: cel
• Dostarczenie zamiennika dla obiektu w celu jego kontroli i ochrony
• Przezroczyste odsunięcie inicjalizacji obiektu w czasie
Gang of Four
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (34)
Proxy: struktura
Subject
request()
Client
RealSubject
Request()
Proxy
Request()
realSubject->Request()
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (35)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (36)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (37)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (38)
Command: struktura
Command
execute()
Invoker
ConcreteCommand
state
execute()
Receiver
action()
Client
receiver->action()
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (39)
Command: interakcje
receiver : Receiverreceiver : Receiver
client : Clientclient : Client command : Commandcommand : Command
invoker : Invokerinvoker : Invoker
new Command()
storeCommand(command)
execute( )
action( )
configure(receiver)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (40)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (41)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (42)
Command: przykład
Operation
execute()
Income
account : Account
execute()
Transfer
from : Accountto : Account
execute()
InterestChange
account : Accountinterest : Interest
execute()
Bank
income()transfer()interestChange()
InterestA
compute()
InterestB
compute()
InterestC
compute()
Account
balance : Long
doOperation(operation : Operation)
Interest
compute()
<<creates>>
operation->execute()
Operation o = new Income(amount);account.execute(o)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (43)
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); }}
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (44)
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); }}
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (45)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (46)
Factory Method: struktura
Product
ConcreteProductConcreteCreator
factoryMethod()
return new ConcreteProduct()
product = factoryMeythod()
<<create>>
Client
Creator
factoryMethod()
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (47)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (48)
Factory Method: konsekwencje
• Przeniesienie odpowiedzialności za tworzenie obiektów Product z klienta na obiekt Creator
• Możliwość rozszerzania hierarchii klas Product niezależnie od klienta
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (49)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (50)
Abstract Factory: struktura
ProductA1
ConcreteFactory2
createProductA()createProductB()
ProductA2
ConcreteFactory1
createProductA()createProductB()
ProductB2 ProductB1
AbstractFactory
createProductA()createProductB()
Abstract Product A
Abstract Product B
Client
<<create>>
<<create>>
<<create>>
<<create>>
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (51)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (52)
Abstract Factory: konsekwencje
• Łatwa zmiana całych grup produktów poprzez zmianę używanej Concrete Factory
• Wydzielenie interfejsu do tworzenia obiektów• Odseparowanie klienta od szczegółów implementacji
obiektów Product• Utrudnione dodawanie kolejnych obiektów Product we
wszystkich grupach
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (53)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (54)
Chain of Responsibility: struktura
Obiekty Handler tworzą listę jednokierunkową (łańcuch), wzdłuż której są przekazywane żądania.
ConcreteHandler1
handleRequest()
ConcreteHandler2
handleRequest()
Handler
handleRequest()
Client +successor
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (55)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (56)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (57)
Chain of Responsibility: przykład 1
Obiekt Inbox wywołuje pierwszy obiekt Filter w łańcuchu. Kolejne filtry przekazują sobie sterowanie
Filter
doFilter()
filterChain.doFilter()
Inbox
filter(msg : Message)
Filter1
doFilter()
Filter2
doFilter()
Filter3
doFilter()
+next+next+filterChain
if (! isEligible()) next.doFilter()
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (58)
Chain of Responsibility: przykład 2
Obiekt Inbox wywołuje kolejno obiekty Filter. Nie występuje bezpośrenie przekazywanie sterowania z jednego filtra do drugiego.
Filter
doFilter()
Filter1
doFilter()
Filter2
doFilter()
Filter3
doFilter()
for (f : filters) { if (f.doFilter()) { break; }}
Inbox
filters : Set
filter(msg : Message)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (59)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (60)
Facade: struktura
Klient może odwołać się zarówno do obiektu Facade, jak i bezpośrednio do podsystemów
Client
Subsystem1
Subsystem2 Subsystem3
Facade
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (61)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (62)
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 lub
bezpośrednio do podsystemów
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (63)
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() }}
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (64)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (65)
Builder: struktura
Klient zleca prace, Director zna sposób reprezentacji, a obiekty typu Builder tworzą specjalizowane obiekty typu Product.
ConcreteBuilder
buildPart()getResult()
for all objects in structure { builder->buildPart()} Product
Builder
buildPart()
Director
construct()
+builderClient
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (66)
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 i podzleca im
wykonanie obiektów Product• Product
– reprezentuje element składowy struktury– posiada interfejs umożliwiający łączenie z innymi
obiektami Product
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (67)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (68)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (69)
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
Originator
state
SetMemento(Memento)CreateMemento()
return new Memento(state)
state = Memento->GetState()
Memento
state
GetState()SetState()
Caretaker<<create>> +memento
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (70)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (71)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (72)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (73)
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; }
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (74)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (75)
Prototype: cel
Umożliwienie tworzenia obiektów na podstawie przykładowej instancji, a nie poprzez wywołanie konstruktora
E. Gamma et al. (1995)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (76)
Prototype: struktura
Wywołanie metody clone() powoduje utworzenie dokładnej kopii przekazanego obiektu Prototype.
ConcretePrototype1
clone()
ConcretePrototype2
clone()
Prototype
clone()
Client
p = prototype->clone()
return clone of itself
return clone of itself
+prototype
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (77)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (78)
Prototype: konsekwencje
• Możliwość tworzenia obiektów poprzez przykład• Uproszczona konstrukcja podobnych obiektów
– pominięcie wyboru konstruktora– ograniczenie liczby podklas w systemie
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (79)
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);
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (80)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (81)
State/Strategy: struktura
Stan jest obiektem. Zmiana stanu oznacza zmianę obiektu go reprezentującego. Delegowane do niego metody są wywoływane polimorficznie.
ConcreteStateA
handle()
ConcreteStateB
handle()
currentState->handle()
State
handle()
Client
Context
request() 1
+currentState
1
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (82)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (83)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (84)
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!"); } }}
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (85)
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!"); }}
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (86)
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(); }}
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (87)
Strategy: przykład
HeapSort
init()sample()sort()
MergeSort
init()sample()sort()
QuickSort
init()sample()sort()
Sorter
data : java.util.Collection
sort()
SortingStrategy
init()sample()sort()
Sorter zleca operację wybranej strategii sortowania. Każda strategia to jeden algorytm. Zmiana strategii nie wpływa na obiekt Sorter.
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (88)
Decorator: cel
• Umożliwienie dynamicznego dodawania funkcjonalności do obiektu
• Stworzenie elastycznej alternatywy dla tworzenia podklas
E. Gamma et al. (1995)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (89)
Decorator: struktura
Klient wysyła komunikat do obiektu Decorator, który przekazuje go obiektowi ConcreteComponent oraz wykonuje dodatkowe operacje („dekoracje”)
ConcreteComponent
operation()
ConcreteDecoratorA
addedState
operation()
ConcreteDecoratorB
operation()addedBehaviour()
Decorator
operation()
Component
operation()
component->operation()
decorator->operation()addedBehavior()
+component
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (90)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (91)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (92)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (93)
Bridge: struktura
RefinedAbstraction
operation()
impl->operationImpl()
ConcreteImplementorA
operationImpl()
ConcreteImplementorB
operationImpl()
Implementor
operationImpl()
Abstraction
operation()
Client
+impl
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (94)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (95)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (96)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (97)
Flyweight: struktura
Flyweight
operation(extrinsicState)
FlyweightFactory
getFlyweight(key : String)
ConcreteFlyweight
operation(extrinsicState)
UnsharedConcreteFlyweight
operation(extrinsicState)
Client
if (flyweights[key] exists) { return existing flyweight;} else { create new one; add to pool; return the new one;}
+flyweights
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (98)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (99)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (100)
Mediator: cel
• Uproszczenie komunikacji wielu obiektów• Hermetyzacja mechanizmu wymiany komunikatów
E. Gamma et al. (1995)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (101)
Mediator: struktura
Obiekty Colleague i obiekt Mediator tworzą topologię gwiazdy. Komunikaty między obiektami Colleague są przekazywane za pośrednictwem mediatora
Colleague
ConcreteColleague1 ConcreteColleague2
ConcreteMediator
Mediator
1 1..n
+mediator
1 1..n
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (102)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (103)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (104)
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; } }
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (105)
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 + " "); } } }
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (106)
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()); } } }
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (107)
Template Method: cel
• Stworzenie szkieletu algorytmu w postaci klasy• Przesunięcie niektórych operacji do podklas
E. Gamma et al. (1995)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (108)
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.
ConcreteClass
primitiveOperation1()primitiveOperation2()
...primitiveOperation1()...primitiveOperation2()...
Client
AbstractClass
templateMethod()primitiveOperation1()primitiveOperation2()
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (109)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (110)
Template Method: konsekwencje
za Gang of Four
• Odwrócona struktura odwołań– zasada hollywoodzka: proszę nie dzwonić, to my
oddzwonimy– nadklasa odwołuje się do metod w podklasach
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (111)
Iterator: cel
Umożliwienie sekwencyjnego dostępu do elementów kolekcji bez ujawniania jej wewnętrznej implementacji
E. Gamma et al. (1995)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (112)
Iterator: struktura
Każdy Aggregate tworzy specyficzny dla siebie iterator.
Klient odwołuje się do niego poprzez abstrakcyjny interfejs.
Aggregate
createIterator()
Iterator
getFirst()getNext()hasNext()
Client
ConcreteAggregate
createIterator()
ConcreteIterator
return new ConcreteIterator(this)
<<create>>
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (113)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (114)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (115)
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)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (116)
Visitor: struktura
ConcreteVisitor1
visit(ConcreteElementA)visit(ConcreteElementB)
ConcreteVisitor2
visit(ConcreteElementA)visit(ConcreteElementB)
ConcreteElementA
accept(Visitor)operationA()
ConcreteElementB
accept(Visitor)operationB()
Element
accept(Visitor)
Visitor
visit(ConcreteElementA)visit(ConcreteElementB)
ObjectStructure
forEach()
Client
visitor->visit(this) visitor->visit(this)
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (117)
Visitor: interakcje
: ObjectStructure : ObjectStructure : ConcreteElementA : ConcreteElementA : ConcreteElementB : ConcreteElementB : ConcreteVisitor1 : ConcreteVisitor1
accept()
visit()
operationA( )
accept()
visit()
operationB( )
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (118)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (119)
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
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (120)
Visitor: przykład
public class Bank { List<BankingProduct> products = new ArrayList<BankingProduct>();
public List<BankingProduct> doReport(Report report) { List<BankingProduct> result = new ArrayList<BankingProduct>();
for (BankingProduct product : products) { result.add(product.accept(report)); }
return result; }}
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (121)
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); } }
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (122)
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; }}
Szkolenie dla NaviExpert, 21.02.2011
Wzorce projektowe cz. I (123)
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
Recommended