Inżynieria Oprogramowania, wykład 5

1

Inżynieria oprogramowania (5)

Inżynieria oprogramowania (5)

→ Wzorce projektowe

Wykorzystano: materiały na stronach Data & Object Factory (www.dofactory.com)

oraz szeroko dostępną literaturę…

Przygotował: dr inż. Dariusz

Pierzchała

[e-mail]

Inżynieria Oprogramowania, wykład 5

2

O czym teraz…



Wzorce architektoniczne



konstrukcyjne



strukturalne,



operacyjne;



Projektowanie obiektowe z wykorzystaniem

wzorców



Przykłady diagramów UML i programów;



Cel:



Zapoznać z przeznaczeniem i własnościami wzorców

projektowych;

Inżynieria Oprogramowania, wykład 5

3

Proces tworzenia oprogramowania



Zbiór czynności i związanych z nimi wyników, które

prowadzą do powstania produktu programowego;



Zasadnicze czynności wspólne dla wszystkich procesów:



Specyfikowanie oprogramowania

•Funkcjonalność oprogramowania i ograniczenia jego działania muszą

być zdefiniowane;



Projektowanie i implementowanie

oprogramowania

•Oprogramowanie, które spełnia specyfikację, musi

być stworzone;



Zatwierdzenie oprogramowania

•Wytworzone oprogramowanie musi spełniać oczekiwania klienta;



Ewolucja oprogramowania

•Oprogramowanie musi ewoluować, aby spełniać zmieniające się

potrzeby użytkowników;

Inżynieria Oprogramowania, wykład 5

4

Historia



Lata 60-70-te - architekt Christopher Alexander krytykuje

nowoczesne, świadome projektowanie;



Zauważalna skuteczność wielu metod tradycyjnych,

wypracowanych ewolucyjnie poprzez praktykę;



Podstawowe zarzuty wobec abstrakcyjnych modeli

dotyczące problemów podczas konkretnej realizacji;



Poszukiwanie alternatywy wśród metod stosowanych w

architekturze budowlanej;



W swoich pracach opisał ponad 250 wzorców;



Każdy wzorzec był małym podręcznikiem opisującym

konkretne zagadnienia architektury, np. „Główne wejście”;



Wynik prac: odwzorowanie metod i stylów

architektonicznych (budowanych) w architekturze

systemów informatycznych;

Inżynieria Oprogramowania, wykład 5

5

Historia



1987 - Ward Cunningham i Kent Beck: koncepcja wzorców

projektowych do nauczania programistów Smalltalk’a;



Nie sprawdziły się w podejściu proceduralnym lat 70-80-

tych;



1991 – Bruce Andersen odkrywa ponownie ich

zastosowanie w OOD/OOP;



1993 – Gang Of Four: E. Gamma, R. Helm, R. Johnson, J.

Vlissides;



1994 – GoF: “Design Patterns: Elements of Reusable

Object-Oriented Software”:



opisują wzorce projektowe;



aktualnie znane i powszechnie stosowane;



Bruce Eckel: „Thinking in Patterns”,

aktualnie dostępne na

www.bruceeckel.com

Inżynieria Oprogramowania, wykład 5

6

Historia



Aktualna literatura

Inżynieria Oprogramowania, wykład 5

7

Pojęcie wzorca



Wzorce projektowe stanowią powtarzalne rozwiązanie

zagadnień projektowych, z którymi się wciąż spotykamy;



Smalltalk Companion



Wzorce projektowe stanowią zbiór reguł określających jak

osiągnąć pewne cele w dziedzinie programowania;



Pree, 1994



Wzorzec adresowany jest do powtarzających się

problemów, które pojawiają się w specyficznych

momentach projektowania i stanowi dla nich rozwiązanie;



Bushmann, 1996



Wzorzec identyfikuje i specyfikuje pewna abstrakcję, której

poziom znajduje się powyżej poziomu abstrakcji

pojedynczej klasy, instancji lub komponentu;



Gamma, 1993

Inżynieria Oprogramowania, wykład 5

8

Pojęcie wzorca



Sprawdzone szkieletowe rozwiązania:



Wzorce dostarczają sprawdzonych rozwiązań dla

powtarzających się problemów;



Możliwe do zastosowania w wielu rzeczywistych kontekstach;



Wpływają na sposób modelowania;



Zapobiegają „wymyślaniu koła od nowa”;



Usprawniają komunikację:



Ułatwiają dyskusję nad problemem i znalezienie właściwego

rozwiązania;



Ułatwiają tworzenie dokumentacji:



Pozwalają na dużo szybsze zdefiniowanie i opisanie systemu;



Dokumentacja może zawierać odwołania do katalogów wzorców

i książkach o wzorcach w celu uzupełnienia opisu systemu;

Wzorce projektowe zwiększają:

elastyczność,

wielokrotne wykorzystanie

oraz czytelność projektu;

Inżynieria Oprogramowania, wykład 5

9

Pojęcie wzorca



Szablon definicji wzorca:



Nazwa wzorca

•znacząca dla problemu i rozwiązania



Kontekst

•opis problemu



Argumenty

•czynniki wpływające na proponowane rozwiązanie
•powody dla których warto stosować dany wzorzec



Rozwiązanie

•struktura: najczęściej diagram klas + diagram sekwencji
•strategie: sposoby implementacji wzorca



Konsekwencje

•wady i zalety danego wzorca



Przykłady zastosowania (opcjonalnie)



Powiązane wzorce i porównanie z innymi

Inżynieria Oprogramowania, wykład 5

10

Pojęcie wzorca



Procedura wyboru wzorca:



Wyróżnienie i zdefiniowanie problemów w projekcie;



Przegląd wzorców i wybór pasujących – kryterium:

•cele,
•kiedy można stosować,
•sposób rozwiązania problemu;



Określenie zakresu zmian w projekcie;



Ocena kosztów zmian w projekcie;



Zastosowanie wzorca:



Zdefiniowanie klas – uczestników wzorca;



Zdefiniowanie operacji wzorca;



Zintegrowanie wzorca z projektem (oprogramowaniem);

Inżynieria Oprogramowania, wykład 5

11

Podział wzorców



Podział wzorców - 1:



Analityczne – ułatwiają modelowanie dziedziny



Projektowe – opisują pewne techniki projektowe



Architektury – standardowe rozwiązania architektury



Organizacyjne – opisują organizację pracy zespołu



Podział wzorców - 2:



Konstrukcyjne



Strukturalne



Operacyjne (czynnościowe)



Podział wzorców - 3:



Warstwy prezentacji



Warstwy logiki



Warstwy integracji

Inżynieria Oprogramowania, wykład 5

12

Podział wzorców



Architektura globalna: koordynacja i komunikacja pomiędzy

organizacjami;



Architektura korporacyjna (enterprise): koordynacja i

komunikacja w obrębie organizacji;



Architektura systemu: koordynacja i komunikacja pomiędzy

aplikacjami;



Architektura aplikacji (Subsystem): dostarczanie

funkcjonalności;



Makro-architektura (Frameworks): powtarzające się

aplikacje;



Mikro-architektura: wzorce projektowe;



Obiekty: specyficzne konstrukcje w językach

programowania;

Inżynieria Oprogramowania, wykład 5

13

Podział wzorców



Podział wzorców:



konstrukcyjne

•wykorzystywane do pozyskiwania obiektów

zamiast ich bezpośredniego tworzenia;



strukturalne

•stosowane do łączenia obiektów w większe

struktury;



operacyjne (czynnościowe)

•definiowanie komunikacji pomiędzy obiektami;
•kontrolowanie przepływów danych w złożonych

algorytmach (programach);

•przydział zobowiązań obiektom;

Inżynieria Oprogramowania, wykład 5

14

Wzorce konstrukcyjne

Inżynieria Oprogramowania, wykład 5

15

Wzorce konstrukcyjne



Służą do pozyskiwania obiektów;



Opisują szczegółowo, jak obiekt może zostać stworzony,



Czynią kod niezależnym od typów tworzonych obiektów;



Wybór konkretnej klasy uzależniany jest np. od

parametrów konfiguracyjnych;



Przykłady:



Singleton,



Fabryka,



Metoda Fabrykująca,



Fabryka Abstrakcyjna,



Budowniczy,



Prototyp;

Inżynieria Oprogramowania, wykład 5

16

Singleton



Zapewnia powołanie tylko jednej instancji obiektu w

całej aplikacji i kontrolowany dostęp;



Obiekt powołany wg tego wzorca jest globalnym

punktem dostępu do instancji danej klasy ;



Wzorzec może być zmodyfikowany do tworzenia

określonej liczby instancji danej klasy (>1);



Funkcje wzorca:



utworzenie obiektu,



inicjalizacja obiektu,



punkt dostępu,



modyfikacja obiektu;



Prostszym rozwiązaniem jest: globalnie dostępna

zmienna statyczną przechowująca referencję do

obiektu;

Inżynieria Oprogramowania, wykład 5

17

Singleton

Inżynieria Oprogramowania, wykład 5

18

class Singleton {
private Singleton instance;
private int i; // dodatkowe pole
private Singleton() {
// }
public static Singleton getInstance() {
if (instance == null)
instance = new Singleton();
return instance;
}
// dodatkowe metody dla pola ‘i’
public int getValue() {
return i; }
public void setValue(int x){
i = x; }
}

Singleton

Singleton

instance : Singleton

Singleton()

<<static>> getInstance() : Singleton

doSth() : void

Przykład

implementacyjny:

Java

Inżynieria Oprogramowania, wykład 5

19

template <class TYPE>
class

Singleton

{

public:
// Global access point
static TYPE *

instance

(void);

protected:
// Default constructor
Singleton (void);
// Contained instance.
TYPE instance_; };

Singleton

template <class TYPE>
TYPE * Singleton::instance_ = 0;

template <class TYPE>
TYPE * Singleton::

instance

(void)

{
if (Singleton<TYPE>::instance_ == 0)

{

Singleton<TYPE>::instance_ =

new Singleton<TYPE>;

}
return Singleton<TYPE>::instance_;
};

Przykład implementacyjny:

Template w Cpp

Inżynieria Oprogramowania, wykład 5

20

Fabryka (factory)



Fabryka nowych obiektów w zdefiniowanych

klasach wzorcowych;



Wszystkie klasy wzorcowe mają metody o tej

samej nazwie, ale o innych realizacjach;



Zaleta – możliwość modyfikowania klas

wzorcowych (tworzących) w jednym miejscu

projektu;



Popularne wersje Fabryki:



Metoda Fabrykująca,



Fabryka Abstrakcji,



Budowniczy,



Prototyp;

Inżynieria Oprogramowania, wykład 5

21

Fabryka (Factory method)



Metoda Fabrykująca (factory method)



Fabryka nie może przewidzieć, jakie obiekty i

w jaki sposób tworzyć;



Klient zna tylko interfejs klasy abstrakcyjnej;



Informacje o sposobie i odpowiedzialność za

tworzenie obiektu znajdują się w

implementacjach „metody tworzącej” klas

pochodnych;



Można tworzyć domyślny produkt, ale też dać

użytkownikowi możliwość podstawienia

swojej wyspecjalizowanej wersji;

Inżynieria Oprogramowania, wykład 5

22

Fabryka (Factory method)



Uczestnicy wzorca:



Product

•Deklaracja interfejsu produktu;



ConcreteProduct

•Implementacja interfejsu produktu;



Creator (Factory)

•Deklaracja interfejsu z metodą tworzącą produkt;
•Może tworzyć domyślny obiekt;



ConcreteCreator (ConcreteFactory)

•Potomek klasy Creator zwracający konkretny produkt;

Inżynieria Oprogramowania, wykład 5

23

Fabryka (Factory method)

<<creates>>

<<creates>>

Inżynieria Oprogramowania, wykład 5

24

Fabryka (Factory method)

Wersja z różnymi produktami oraz klientem

Inżynieria Oprogramowania, wykład 5

25

Fabryka (Factory method)

class ConcreteFactory_A extends

Factory

{

public ConcreteProduct createProduct() {
return new ConcreteProduct_A ();
}
}

...

Factory

fab_A = new ConcreteFactory_A ();

Concrete

p = fab_A.createProduct();

Przykład

implementacyjny

Inżynieria Oprogramowania, wykład 5

26

Fabryka (Abstract factory)



Fabryka Abstrakcji (abstract factory)



Tworzenie rodzin powiązanych ze sobą obiektów bez

konieczności posługiwania się ich konkretnymi

klasami;



Wprowadzenie wielu metod zwracających obiekty,

spełniające określone interfejsy;



Klient nie musi znać szczegółów budowania rodzin

obiektów;



Implementowana często z wykorzystaniem Factory

Method;

Inżynieria Oprogramowania, wykład 5

27

Fabryka (Abstract factory)



Uczestnicy wzorca:



AbstractFactory

•Deklaracja interfejsu operacji fabryki;



ConcreteFactory

•Implementuje operacje dla konkretnych produktów;



AbstractProduct

•Deklaracja interfejsu produktu;



ConcreteProduct

•Definicja konkretnego produktu;
•Implementacja interfejsu produktu abstrakcyjnego;



Client

•Obiekt używający w deklaracji interfejsu fabryki i produktu;
•Konkretyzowany w implementacji;

Inżynieria Oprogramowania, wykład 5

28

Fabryka (Abstract factory)

Factory

createProduct_AbstractProduct_A()

AbstractProduct_A

<<creates>>

ConcreteProduct_A

AbstractFactory

createProduct_AbstractProduct_A()

<<creates>>

Client

1

-theAbstractFactory

1

<<creates>>

Inżynieria Oprogramowania, wykład 5

29

Fabryka (Abstract factory)

interface AbstractFactory {
public AbstractProduct_A

createProduct_AbstractProduct_A ();

//...
}

class Factory implements AbstractFactory {
public AbstractProduct_A

createProduct_AbstractProduct_A () {

return new ConcreteProduct_A();
}
}

Przykład

implementacyjny

Inżynieria Oprogramowania, wykład 5

30

Fabryka (Abstract factory)

Wersja z różnymi produktami

Inżynieria Oprogramowania, wykład 5

31

Fabryka (Builder)



Budowniczy (builder)



Funkcjonalnie zbliżony do Fabryki Abstrakcyjnej:

•tworzą złożone twory;
•Builder tworzy stopniowo, zaś Fabryka Abstrakcyjna kładzie

nacisk na rodzinę produktów tworzonych w jednym działaniu;



Dostarcza interfejs dla klasy zarządzającej

tworzeniem obiektu (zwanej Director lub Context);



Obiekt tworzony jest wieloetapowo, na podstawie

dostarczonych argumentów;



Klasa zarządzająca ukrywa szczegóły tworzenia;

Inżynieria Oprogramowania, wykład 5

32

Fabryka (Builder)



Budowniczy (builder)

Director

construct()

Builder

buildPart()

1

1

ConcreteBuilder

Product

<<creates>>

Wywołaj bulid dla wszystkich
składowych struktury

Inżynieria Oprogramowania, wykład 5

33

Fabryka (Prototype)



Prototyp (prototype)



tworzenie obiektów przez klonowanie prototypu;



obiekty klonowane muszą umożliwiać zmianę swoich

właściwości;



stosowane, gdy tworzenie obiektów zabiera dużą

ilość czasu, np. obiekt utworzono na podstawie

odpowiedzi z zapytania do bazy danych;

Inżynieria Oprogramowania, wykład 5

34

Fabryka (Prototype)



Uczestnicy wzorca:



Prototype

•Deklaracja interfejsu dla obiektu klonowanego;



ConcretePrototype

•Implementuje operacje klonujące;



Client

•Tworzy obiekt wysyłając komunikat z poleceniem

sklonowania;

Inżynieria Oprogramowania, wykład 5

35

Fabryka (Prototype)

Inżynieria Oprogramowania, wykład 5

36

Fabryka (Prototype)



Prototyp (prototype)

class Fabryka {
Map prototypy;
public Fabryka() {
prototypy = new HashMap();
prototypy.put("tomek",new Tomek());
prototypy.put(”marek",new Marek());
}
public Klon makeObject( String s ) {
return ((Klon)prototypy.get(s)).klonuj();
}
}

interface Klon {
Klon klonuj();
}
class Tomek implements Klon {
Klon klonuj() {
return new Tomek();
}
}

Przykład

implementacyjny

Inżynieria Oprogramowania, wykład 5

37

Wzorce konstrukcyjne



Podsumowanie:



Singleton – pojedyncza instancja obiektu;



Metoda Fabrykująca – tworzenie obiektów w klasach

pochodnych;



Fabryka Abstrakcyjna – tworzenie rodzin obiektów

bez wydzielonych klas fabryk;



Budowniczy – ukrycie szczegółów tworzenia za

interfejsem zarządcy;



Prototyp – tworzenie kopii na podstawie w pełni

zainicjalizowanej instancji;

Inżynieria Oprogramowania, wykład 5

38

Wzorce strukturalne

Inżynieria Oprogramowania, wykład 5

39

Wzorce strukturalne



Stosowany do łączenia obiektów w większe struktury;



Zastosowanie np. w implementacji złożonego

interfejsu użytkownika;



Przykłady:



Fasada,



Adapter,



Most,



Kompozyt,



Dekorator,



Waga Piórkowa,



Proxy;

Inżynieria Oprogramowania, wykład 5

40

Fasada (façade)



Ujednolicony i prostszy interfejs do struktury

złożonych podsystemów;



Separacja klienta od złożonych podsystemów;



Wybór odpowiedniej struktury dla żądania klienta;



Możliwości zmian w ukrywanych podsystemach;



Przykłady:



w bibliotekach Javy: klasy pakietu java.sql (Statement,

ResultSet);



wejście usług w Service Oriented Architecture (SOA);

Inżynieria Oprogramowania, wykład 5

41

Fasada (façade)



Client



Korzysta z funkcjonalności udostępnianej przez

podsystem;



Facade



Tłumaczy zgrupowane żądania klientów na

pojedyncze wywołania metod usług i obiektów

biznesowych;



Facade_Subsystem



Złożony podsystem pracujący niezależnie od

pośredniczącego Facade;

Inżynieria Oprogramowania, wykład 5

42

Fasada (façade)

Facade_SubsystemClass_A

Facade

<<creates>>

Facade_Client

-theFacade

1

1

Inżynieria Oprogramowania, wykład 5

43

Fasada (façade)

Przykład:
Podsystemem są: ApplicationService, BusinessObject
Usługi i obiekty biznesowe są nieświadome istnienia obiektów Façade.

Inżynieria Oprogramowania, wykład 5

44

Fasada (façade)

Inżynieria Oprogramowania, wykład 5

45

Adapter



Konwertuje (dopasowuje) interfejsy jednej klasy

do interfejsu innej klasy;



Umożliwia klasom o różnych interfejsach

współpracę w jednym programie;



Niewielka elastyczność – adaptacji podlega tylko

jedna klasa (Adaptee), bez jej podklas;



Zmiana zachowania klasy Adapter może zmienić

zachowanie klasy dostosowywanej Adaptee;



Dwa sposoby realizacji:



dziedziczenie,



kompozycja;

Inżynieria Oprogramowania, wykład 5

46

Adapter



Uczestnicy wzorca



Target

•definiuje interfejs znany klasie Client;



Client

•współpracuje z obiektami zgodnymi z interfejsem Target;



Adaptee

•definiuje istniejący interfejs, wymagający adaptacji;



Adapter

•adaptuje interfejs Adaptee do interfejsu Target;

Inżynieria Oprogramowania, wykład 5

47

Adapter

Wersja z delegacją (kompozycja)

Target

request()

<<Interface>>

Client

-theTarget

1

1

Adaptee

specificRequest()

Adapter

request()

-AdapteeRef

1

1

Inżynieria Oprogramowania, wykład 5

48

Adapter

Wersja z dziedziczeniem wielobazowym

Inżynieria Oprogramowania, wykład 5

49

Adapter

class Adapter extends Target {
private Do_Adapatacji da;
public Adapter(Do_Adaptacji a)

{
da = a;
}
public void request() {
da.specificRequest();
}
// ...
Do_Adaptacji a = new Do_Adaptacji();
Target t = new Adapter(a);

class Target {
public void request() {
//...
}
}
class Do_Adaptacji {
public void specificRequest()
//...
}
}

Przykład

implementacyjny

Inżynieria Oprogramowania, wykład 5

50

Most a Adapter



podobny do wzorca Adapter;



jest to także obiekt konwertujący jeden rodzaj

interfejsu na inny;



różnice:



przeznaczeniem Adaptera jest dostosowanie

interfejsu klasy istniejącej do innej klasy;



Most odseparowuje interfejs od jego implementacji,

co daje możliwość zmiany implementacji bez

modyfikacji kodu wywołania w programie;



implementacja będzie wybrana lub zmieniona w

trakcie wykonania;

Inżynieria Oprogramowania, wykład 5

51

Kompozyt (Composite)



System złożony z podsystemów o strukturze

drzewiastej ( reprezentacja związku „całość-

część”);



Wspólny interfejs dla klas węzłów i liści –

ujednolicone widzenie kontenerów i obiektów

składowanych;



Łatwo rozszerzalny o nowe podsystemy

implementujące (określony interfejs);



Przykłady:



Przykład w bibliotekach Javy: kontenery (Panel,

JComponent, …);

Inżynieria Oprogramowania, wykład 5

52

Kompozyt (Composite)



Uczestnicy wzorca



Component

•Definiuje interfejsy: dla klasy Client oraz dla węzłów i liści

składowych;

•Implementuje domyślne zachowanie;



Leaf

•Definiuje zachowanie „prymitywów”;
•Nie ma potomków;



Composite

•Implementuje zachowanie złożonych obiektów;
•Posiada potomków;



Client

•współpracuje z obiektami kompozycji poprzez interfejs

Component;

Inżynieria Oprogramowania, wykład 5

53

Kompozyt (Composite)

Inżynieria Oprogramowania, wykład 5

54

Kompozyt (Composite)



Struktura węzłów i liści:

// Component
class Graphic {
void

Draw

();

void

AddChild

(Graphic g);

void

RemoveChild

(Graphic g);

Graphic

GetChild

(int i);

int

ChildCount

();

}

Przykład

implementacyjny

// Leaf
class Rectangle extends

Graphic {
void

Draw

(){

g.drawRectangle(x, y, w, h);

};
... }

// Composit
class Group extends Graphic {
void

Draw

(){

for(int i=0;

i<GraphicGroup.size(); i++)

{((Graphic)GraphicGroup.elementAt(i)).

Draw(); } }

... }

Operacje

nadmiarowe w

klasie liści

(Leaf)

Inżynieria Oprogramowania, wykład 5

55

Dekorator



Podstawowe zachowanie klasy musi być czasami

rozszerzone o dodatkowe operacje lub cechy;



Funkcjonalność uzupełniająca umieszczana jest w

osobnych klasach Decorator;



Stosowany zamiast dziedziczenia, które mogłoby

stworzyć zbyt wiele mało elastycznych klas;



Dekorator agreguje w sobie dekorowane obiekty i

dziedziczy z tej samej nadklasy, co te obiekty;



Dynamiczna zmiana klasy nadrzędnej;



Utworzenie klasy poprzez dodanie nowego zachowania;



Przekazanie klasy rozszerzonej do konstruktora Dekoratora;



Przykład:



w bibliotekach Javy: klasy strumieni (BufferedInputStream, …);

Inżynieria Oprogramowania, wykład 5

56

Dekorator

Inżynieria Oprogramowania, wykład 5

57

Dekorator

JPanel jp = new JPanel();
getContentPane().add( jp );
jp.add( new

JButton

(”Bazowy-A”));

jp.add( new

Decorator

( new

JButton

(”Rozszerzony-A”)) );

jp.add( new

Decorator

( new

JButton

(”Rozszerzony-B”)) );

jp.add( new

Decorator

( new

JButton

(”Rozszerzony-C”)) );

public class

Decorator

extends

JComponent

{

JComponent

comp;

public

Decorator

(

JComponent

jc ) {

setLayout( new BorderedLayout() );
add( "Center", jc )
comp = this;
... // np. obsługa zdarzeń
} }

Przykład

implementacyjny

Inżynieria Oprogramowania, wykład 5

58

Waga Piórkowa (flyweight)



Zastąpienie wielu obiektów jednym współdzielonym z opisem

stanu zubożonym w porównaniu z pierwotnym obiektem;



Zamiast przechowywać wewnątrz atrybuty stanu, obiekty

dostają wartości z zewnątrz jako parametry wywołania

metod;



Zalety:



Ograniczenie liczby tworzonych instancji obiektów;



Przesunięcie części danych z obiektu do przekazywanych

parametrów metod;



Wady:



Zwiększony koszt wywoływania metod obiektów;



Uzyskuje się przyspieszenie programów operujących na

wielu niezbyt złożonych obiektach;



Przykład: zbiory obiektów „znaków literowych”;

Inżynieria Oprogramowania, wykład 5

59

Waga Piórkowa (flyweight)

Inżynieria Oprogramowania, wykład 5

60

Pośrednik (proxy)



Punkt kontroli dostępu do rzeczywistego obiektu

-ogranicza (ukrywa) dostęp do obiektu (podobnie jak

Dekorator);



Odsunięcie w czasie tworzenia rzeczywistego obiektu;



Działania wykonywane są na Pośredniku, który działa

na właściwej klasie o tym samym interfejsie;



Stosowany, gdy obiekt docelowy jest złożony i np.

potrzebuje wiele czasu na wczytanie (patrz sieć);



Przykład:



W bibliotekach Javy: ziarna "enterprise" (Enterprise JavaBeans)

i komunikacja z bazą danych;

Inżynieria Oprogramowania, wykład 5

61

Pośrednik (proxy)



Subject



Wspólny interfejs implementowany przez obiekt Proxy i

rzeczywisty obiekt, udostępniany obiektom typu Client;



RealSubject



Definicja rzeczywistego obiektu;



Proxy



Zarządza dostępem do rzeczywistego obiektu, może zajmować

się jego tworzeniem i usuwaniem;



Client



Wykorzystuje funkcjonalność zaimplementowaną w

rzeczywistych obiektach;



Obiekty typu Client nie posługują się referencjami do obiektów

rzeczywistych;

Inżynieria Oprogramowania, wykład 5

62

Pośrednik (proxy)

Inżynieria Oprogramowania, wykład 5

63

Wzorce strukturalne



Podsumowanie:



Fasada – prosty interfejs złożonego (pod-)systemu;



Adapter – dostosowanie interfejsów różnych klas;



Most – odseparowanie interfejsu od implementacji;



Kompozyt – elementy struktury drzewiastej;



Dekorator – dynamiczne rozszerzenie obiektu;



Waga Piórkowa – lekkie instancje obiektów;



Proxy – aktualna reprezentacja obiektu docelowego;

Inżynieria Oprogramowania, wykład 5

64

Wzorce operacyjne (czynnościowe)

Inżynieria Oprogramowania, wykład 5

65

Wzorce operacyjne (czynnościowe)



W celu definiowania komunikacji pomiędzy

obiektami;



Pomagają kontrolować przepływ danych w

złożonym programie;



Przykłady:



Iterator,



Łańcuch Odpowiedzialności,



Stan,



Mediator,



Obserwator,



Strategia;

Inżynieria Oprogramowania, wykład 5

66

Iterator



Upraszcza przemieszczanie po kolekcji danych

(np. liście), z wykorzystaniem standardowego

interfejsu;



Nie wymaga znajomości wewnętrznej struktury

kolekcji danych;



Umożliwia równoczesne przeglądanie kilku

kolekcji;



Przykład:



W bibliotekach Javy: iterator w kolekcjach z pakietu

java.util;

Inżynieria Oprogramowania, wykład 5

67

Iterator

Inżynieria Oprogramowania, wykład 5

68

Łańcuch Odpowiedzialności (chain of

responsibility)



Zestaw klas obsługuje żądanie w określonej

kolejności;



Żądanie jest przekazywane pomiędzy klasami

w określonym łańcuchu;



Czasami ostatni obiekt łańcucha obsługuje

wszystkie żądania;



Przykład:



Realizacja w Javie: Frame -> Panel -> Component;

Inżynieria Oprogramowania, wykład 5

69

Łańcuch Odpowiedzialności (chain of

responsibility)

Inżynieria Oprogramowania, wykład 5

70

Łańcuch Odpowiedzialności (chain of

responsibility)

public interface Chain
{
public void addChain( Chain c );
public void sendToChain( String msg );
public Chain getChain();
}

Przykład

implementacyjny

Inżynieria Oprogramowania, wykład 5

71

Stan (state)



Tworzy obiekty pochodne z bazowej klasy State

dla każdego stanu, w którym może znaleźć się

aplikacja;



Przełączanie pomiędzy obiektami stanu, gdy

zmieni się stan aplikacji;



Wraz ze zmianą stanu i tym samym obiektu

może zmienić się zachowanie obiektu (inne

implementacje metod);



Eliminuje złożone instrukcje warunkowe (np.

switch) w metodach obiektu;



Wada: powstaje wiele małych klas;



Zaleta: upraszcza program;

Inżynieria Oprogramowania, wykład 5

72

Stan (state)

Inżynieria Oprogramowania, wykład 5

73

Mediator



Mediatora stanowi „zarządcę obiektów”;



Wprowadza luźniejsze powiązania pomiędzy

klasami – obiekty znają Mediatora a nie

koniecznie inne obiekty;



Zmiany stanu obiektów są za jego

pośrednictwem (odpowiednich metod)

propagowane do zainteresowanych obiektów;



Często jest specjalizowany dla jednego

projektu;

Inżynieria Oprogramowania, wykład 5

74

Mediator

Inżynieria Oprogramowania, wykład 5

75

Obserwator (Observer - Listener)



Ciągłe odpytywanie o stan obiektu prowadzi do

znacznego spadku wydajności aplikacji;



Obserwator (Observer) przechowuje informację o

stanie lub reaguje na zmianę stanu innych obiektów;



Luźne powiązanie z określonym obiektem;



Może być kilku obserwatorów jednego obiektu: relacja

obiektów 1:N;



Wybrany obiekt powiadamia zainteresowanych o

zmianie swojego stanu;



Przykłady użycia:



obsługa zdarzeń w okienkach,



synchronizacja modelu z widokiem;

Inżynieria Oprogramowania, wykład 5

76

Obserwator (Observer - Listener)



Uczestnicy



Subject

•Posiada referencje do obiektów Observer;
•Interfejs operacji dołączania i odłączania obiektów Observer;



Observer

•Definiuje interfejs metody aktualizującej;



Concrete Subject

•Przechowuje stan interesujący konkretny obiekt Observator;
•wysyła powiadomienia obiektom Observer;



Concrete Observer

•przechowuje referencję do Concrete Subject;
•aktualizuje swój stan razem ze stanem obiektu Concrete

Subject;

Inżynieria Oprogramowania, wykład 5

77

Obserwator (Observer - Listener)

interface Observer {
public void update( Oservable obs, Object arg );
}

Przykład

implementacyjny

Inżynieria Oprogramowania, wykład 5

78

Strategia (Strategy)



Potrzeba kilku wariantów algorytmu;



Wybór określonego wariantu poprzez powołanie

obiektu pochodnego do zdefiniowanego interfejsu

bazowego lub klasy abstrakcyjnej;



Każda wersja algorytmu jest implementowana w

osobnej klasie;



Zalety:



algorytm może używać danych, których klient nie zna;



hermetyzacja algorytmów w oddzielnych klasach

pozwala na ich modyfikację niezależnie od kontekstu;



to rozwiązanie zastępuje instrukcje wyboru lub

warunkowe;

Inżynieria Oprogramowania, wykład 5

79

Strategia (Strategy)

Client

Inżynieria Oprogramowania, wykład 5

80

Wzorce operacyjne (czynnościowe)



Podsumowanie:



Iterator – sekwencyjny dostęp do elementów

kolekcji;



Łańcuch Odpowiedzialności – sposób przekazywania

wywołań w łańcuchu obiektów;



Stan – zmiana zachowania (metod) ze zmianą stanu;



Mediator – pośredniczy w komunikacji obiektów;



Obserwator – rejestrowanie i informowanie o

zmianach;



Strategia – enkapsulacja algorytmu w klasie;

Inżynieria Oprogramowania, wykład 5

81

Wzorce - podsumowanie

Zastosowanie w wybranych

problemach

Inżynieria Oprogramowania, wykład 5

82

Wzorce - podsumowanie



Konstruowanie obiektu poprzez jawne określenie klasy:



Fabryka abstrakcji, Metoda fabrykująca, Prototyp



Zależność od platformy programowo-sprzętowej:



Fabryka abstrakcji, Most



Zależność od reprezentacji lub implementacji obiektu:



Fabryka abstrakcji, Most, Memento, Pośrednik



Zależność od wersji algorytmu:



Budowniczy, Iterator, Strategia, Szablon metod, Wizytator



Zależność od określonych operacji:



Łańcuch odpowiedzialności



Rozszerzanie funkcjonalności (przez klasy potomne):



Most, Łańcuch odpowiedzialności, Kompozyt, Dekorator, Obserwator,

Strategia



Brak możliwości lub niewygodna modyfikacja klasy:



Adapter, Dekorator, Wizytator

Inżynieria Oprogramowania, wykład 5

83

Wzorce warstw - przykład

prezentacji

logiki

integracji

Inżynieria Oprogramowania, wykład 5

84

Pojęcie wzorca