Szkolenie dla NaviExpert, 21.02.2011

Szkolenie dla NaviExpert, 21.02.2011

Wybrane wzorce projektoweGang of Four


Wzorce projektowe cz. I (2)

Agenda

1.Motywacja dla stosowania i definiowania wzorców

2.Struktura wzorca projektowego3.Katalog wzorców projektowych



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?



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 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 w budownictwie lądowym

Czy zbudować most łukowy czy podwieszany?

na podstawie przykładu R. Johnsona



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



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



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



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



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



Singleton: cel

• Zapewnienie, że klasa posiada jedną instancję wewnątrz całej aplikacji

• Stworzenie punktu dostępowego do tej instancji

Gang of Four



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;



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



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)



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; }}




Pool of Objects: cel

• Zarządzanie grupą obiektów reprezentujących zasoby wielokrotnego użycia

• Ograniczenie kosztów tworzenia i usuwania obiektów




Pool of Objects: struktura

Client

ReusableObject

Pool

Pool()getInstance()getObject()returnObject()size()

10..n

10..n

0..n

1

0..n

1



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



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



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



Observer: struktura

Observer

update()

Subject

request()

ConcreteSubject

getState()setState()

ConcreteObserver

update()

for all observers { obs->update();}

observerState = subject->getState();

+obs

+subject



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



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



Adapter: cel

• Umożliwienie współpracy obiektów o niezgodnych typach

• Tłumaczenie protokołów obiektowych

Gang of Four



Adapter: struktura

Target

request()

Client

Adaptee

specificRequest()

Adapter

request()

adaptee->specificRequest()

+adaptee



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



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



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



Composite: struktura

Leaf

operation()

Composite

operation()add()remove()getChild()

Component

operation()

Client +child



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



Composite: konsekwencje

• Elastyczna definicja struktur drzewiastych• Proste dodawanie nowych komponentów• Proste i spójne zarządzanie strukturą o dowolnej liczbie

elementów



Proxy: cel

• Dostarczenie zamiennika dla obiektu w celu jego kontroli i ochrony

• Przezroczyste odsunięcie inicjalizacji obiektu w czasie

Gang of Four



Proxy: struktura

Subject

request()

Client

RealSubject

Request()

Proxy

Request()

realSubject->Request()



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



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



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)



Command: struktura

Command

execute()

Invoker

ConcreteCommand

state

execute()

Receiver

action()

Client

receiver->action()



Command: interakcje

receiver : Receiverreceiver : Receiver

client : Clientclient : Client command : Commandcommand : Command

invoker : Invokerinvoker : Invoker

new Command()

storeCommand(command)

execute( )

action( )

configure(receiver)



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



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



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)



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); }}



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); }}



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




Factory Method: struktura

Product

ConcreteProductConcreteCreator

factoryMethod()

return new ConcreteProduct()

product = factoryMeythod()

<<create>>

Client

Creator

factoryMethod()



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



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



Abstract Factory: cel

• Stworzenie interfejsu do tworzenia grup powiązanych ze sobą produktów

• Rozszerzenie Factory Method na grupy produktów




Abstract Factory: struktura

ProductA1

ConcreteFactory2

createProductA()createProductB()

ProductA2

ConcreteFactory1


ProductB2 ProductB1

AbstractFactory


Abstract Product A

Abstract Product B

Client

<<create>>

<<create>>

<<create>>

<<create>>



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



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



Chain of Responsibility: cel

• Usunięcie powiązania pomiędzy nadawcą i odbiorcą żądania

• Umożliwienie wielu obiektom obsługi żądania




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



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



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



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()



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)



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




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



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



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



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() }}



Builder: cel

• Odseparowanie sposobu reprezentacji i metody konstrukcji złożonych struktur obiektowych

• Wykorzystanie jednego mechanizmu konstrukcyjnego do tworzenia struktur o różnej reprezentacji




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



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



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



Memento: cel

• Umożliwienie zachowania stanu obiektu na zewnątrz w celu jego późniejszego odtworzenia

• Zachowanie hermetyzacji tego obiektu




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



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



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



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



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; }



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



Prototype: cel

Umożliwienie tworzenia obiektów na podstawie przykładowej instancji, a nie poprzez wywołanie konstruktora




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



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



Prototype: konsekwencje

• Możliwość tworzenia obiektów poprzez przykład• Uproszczona konstrukcja podobnych obiektów

– pominięcie wyboru konstruktora– ograniczenie liczby podklas w systemie



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);



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




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



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



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



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!"); } }}



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!"); }}



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(); }}



Strategy: przykład

HeapSort

init()sample()sort()

MergeSort


QuickSort


Sorter

data : java.util.Collection

sort()

SortingStrategy


Sorter zleca operację wybranej strategii sortowania. Każda strategia to jeden algorytm. Zmiana strategii nie wpływa na obiekt Sorter.



Decorator: cel

• Umożliwienie dynamicznego dodawania funkcjonalności do obiektu

• Stworzenie elastycznej alternatywy dla tworzenia podklas




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



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



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



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



Bridge: struktura

RefinedAbstraction

operation()

impl->operationImpl()

ConcreteImplementorA

operationImpl()

ConcreteImplementorB

operationImpl()

Implementor

operationImpl()

Abstraction

operation()

Client

+impl



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



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



Flyweight: cel

• Współdzielenie obiektów w celu zwiększenia wydajności• Wydzielenie z obiektu stanu wewnętrznego

(współdzielonego) i zewnętrznego (specyficznego)




Flyweight: struktura

Flyweight

operation(extrinsicState)

FlyweightFactory

getFlyweight(key : String)

ConcreteFlyweight


UnsharedConcreteFlyweight


Client

if (flyweights[key] exists) { return existing flyweight;} else { create new one; add to pool; return the new one;}

+flyweights



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



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



Mediator: cel

• Uproszczenie komunikacji wielu obiektów• Hermetyzacja mechanizmu wymiany komunikatów




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



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



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



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; } }



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 + " "); } } }



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()); } } }



Template Method: cel

• Stworzenie szkieletu algorytmu w postaci klasy• Przesunięcie niektórych operacji do podklas




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()



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



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



Iterator: cel

Umożliwienie sekwencyjnego dostępu do elementów kolekcji bez ujawniania jej wewnętrznej implementacji




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>>



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



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



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




Visitor: struktura

ConcreteVisitor1

visit(ConcreteElementA)visit(ConcreteElementB)

ConcreteVisitor2


ConcreteElementA

accept(Visitor)operationA()

ConcreteElementB

accept(Visitor)operationB()

Element

accept(Visitor)

Visitor


ObjectStructure

forEach()

Client

visitor->visit(this) visitor->visit(this)



Visitor: interakcje

: ObjectStructure : ObjectStructure : ConcreteElementA : ConcreteElementA : ConcreteElementB : ConcreteElementB : ConcreteVisitor1 : ConcreteVisitor1

accept()

visit()

operationA( )

accept()

visit()

operationB( )



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



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



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; }}



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); } }



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; }}



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

Szkolenie dla NaviExpert, 21.02.2011

Documents

Transcript of Szkolenie dla NaviExpert, 21.02.2011