Projektowanie System

1
Projektowanie obiektoweWzorce projektowe
Gang of FourWzorce odpowiedzialnosci
1
2
Roadmap

• Singleton
• Observer
• Mediator
• Proxy
• Flyweight
• Chain of responsibility

2
3
Wzorce odpowiedzialnosci

• Udostepniaja techniki centralizacji, delegowania
  i ograniczania odpowiedzialnosci zwyklych obiektów

3
4
Singleton

• GoF wzorzec kreacyjny
• Umozliwienie skupienia calej odpowiedzialnosci w
  jednej instancji klasy

4
5
Singleton problem

• Aplikacja potrzebuje dokladnie jednej instancji
  klasy.
• Obiekt ten ma byc dostepny globalnie, a jego
  inicjalizacja z reguly opózniona do pierwszej
  próby dostepu.

5
6
Singleton rozwiazanie

• Wymuszamy okreslona liczbe instancji klasy.
• Leniwa inicjalizacja.
• Dostep globalny.

6
7
Singleton diagram klas


7
8
Singleton przyklad


8
9
Singleton konsekwencje

• Istnieje dokladnie jedna instancja klasy
  singleton
• Metoda getInstance() klasy singleton hermetyzuje
  polityke tworzenia dla klasy singleton tak, ze
  klasy ja uzywajace nie zaleza od szczególów
  implementacyjnych tej metody.
• Inne klasy, które chca sie odwolywac do jedynej
  instancji singleton, musza uzyc statycznej metody
  getInstance().
• Dziedziczenie po klasie singleton jest
  niewygodne
• trzeba utworzyc nie prywatny konstruktor,
• nie mozna przeslonic statycznej getInstance().

9
10
Zaleznosci miedzy wzorcami

• Nastepujace wzorce moga uzyc singletona w swojej
  implementacji
• abstract factory,
• builder,
• prototype.
• Singletony czesto to obiekty
• facade (jest potrzebny tylko jeden),
• state.

10
11
Observer

• GoF wzorzec behawioralny
• Umozliwia oddzielic obiekt od znajomosci obiektów
  od niego zaleznych

11
12
Observer problem

• Duzy monolityczny kod nie skaluje sie dobrze, gdy
  rosna wymagania w stosunku do wizualizacji i
  monitorowania aplikacji.
• Obiekt jest obarczony odpowiedzialnoscia
  informowania swoich klientów o zmianach istotnych
  atrybutów, mimo ze to klient wie, które
  atrybuty sa dla niego istotne.

12
13
Observer rozwiazanie

• Struktura Oslona/Delegacja.
• oslona hermetyzuje (enkapsuluje) rdzen logiki
  biznesowej
• kazda delegacja dostarcza konfigurowalna przez
  uzytkownika, opcjonalna funkcjonalnosc

13
14
Observer diagram klas


14
15
Observer przyklad


15
16
Observer konsekwencje

• Objekt dostarcza powiadomienia innym obiektom bez
  swiadomosci nadawcy i odbiorcy o sobie nawzajem.
• Dostarczanie powiadomien moze trwac dlugo.
• Ryzyko cyklicznych powiadomien.

16
17
Zasada hermetyzacji zmiennosci

• Polega na ukryciu za jednolitym interfejsem wielu
  róznych implementacji.
• Pozwala
• wyeliminowac powtarzalnosc kodu,
• wykorzystywac rózne elementy aplikacji
  w jednolity sposób.

17
18
Mediator

• GoF wzorzec behawioralny
• Pozwala skupic odpowiedzialnosc w jednej klasie,
  nadzorujacej interakcje innych obiektów

18
19
Mediator problem

• Potrzebujemy zaprojektowac komponenty
  wielokrotnego uzytku, ale zaleznosci miedzy
  fragmentami, które moga byc potencjalnie
  wielokrotnie uzywane, wykazuje fenomen kodu
  spagetti ?.
• Zlozonosc interakcji miedzy obiektami zbliza sie
  do najbardziej skomplikowanego ukladu.

19
20
Mediator rozwiazanie

• Wprowadzamy dodatkowy poziom posredniczacy, który
  hermetyzuje relacje wiele-do-wielu miedzy innymi
  komponentami
• Struktura Oslona/Delegacja.
• oslona jest obiektem mapujacym.
• delegacje sa sieci wspólpracujacych obiektów
• Stosujemy poprawny politycznie menadzer (tzw.
  God object)

20
21
Mediator diagram klas


21
22
Mediator przyklad


22
23
Mediator konsekwencje

• Wiekszosc zlozonosci zwiazanej z zarzadzaniem
  zaleznosciami jest przesuniete do obiektu
  mediatora. To ulatwia implementacje i utrzymanie
  innych obiektów.
• Przesuniecie logiki zaleznosci dla innych klas w
  jednej klasie mediatora ulatwia programistom
  znalezienie zaleznosci.
• Klasy mediatora z reguly nie umozliwiaja
  ponownego uzycia, poniewaz kod obslugujacy
  zaleznosci jest specyficzny dla aplikacji.

23
24
Zaleznosci miedzy wzorcami Mediator

• Mediator jest podobny do facade wylawiajac
  funkcjonalnosc istniejacych klas, z tym ze
  mediator jest znany przez klasy podsystemu i
  wprowadza do niego nowa funkcjonalnosc.
• Mediator i observer sa rywalizujacymi wzorcami
• observer rozprasza komunikacje,
• mediator hermetyzuje komunikacje.
• Mediator moze skorzystac z observera w celu
  dynamicznej rejestracji i zarzadzenia kolegów.

24
25
Proxy

• GoF wzorzec strukturalny
• Pozwala obiektowi dzialac w imieniu innego
  obiektu

25
26
Proxy problem

• Potrzebujemy obslugiwac zasobo-zerne obiekty,
  ale mozemy odlozyc ich tworzenie do momentu, gdy
  beda faktycznie zazadane przez klienta.
• Poprawny obiekt z jakiegos wzgledu nie jest w
  stanie przeprowadzic zadeklarowanych dzialan (np.
  z uwagi dlugiego czasu ladowania obiektu)

26
27
Proxy rozwiazanie

• Wprowadzamy dodatkowa warstwe posredniczaca,
  która dostarcza dodatkowa funkcjonalnosc
• rozproszona komunikacje
• logowanie, rewizje,
• smart-pointer (sprytny wskaznik).
• Struktura Oslona/Delegacja.

27
28
Proxy diagram klas


28
29
Proxy przyklad


29
30
Proxy konsekwencje

• Dostep do klas przez pozostala czesc programu
  jest realizowany przez wirtualne proxy.
• Udostepniane objekty sa tworzone dopiero, gdy sa
  potrzebne.
• Klasy wykorzystujace proxy nie potrzebuja
  wiedziec, która obslugujaca klasa jest
  zaladowana, albo czy taka klasa badz jej
  instancja istnieje
• Wszystkie klasy inne niz proxy musza odwolywac
  sie do uslug posrednio przez klase proxy.
  (Inaczej usluga moze byc zaladowana zanim bedzie
  potrzebna)

30
31
Odpowiedzialnosc Diagram klas z bledami

31
32
Chain of Responsibiliy

• GoF - wzorzec behawioralny
• Umozliwia przekazywanie zadania na coraz wyzsze
  poziomy az do znalezienia obiektu, który je
  obsluzy

32
33
Chain of Responsibiliy problem

• Mamy potencjalnie zmienna liczbe obiektów
  obslugujacych badz przetwarzajacych oraz
  strumien zadan. Potrzebujemy wydajnie przetworzyc
  zadania nie tworzac twardych zaleznosci i
  mapowan.

33
34
Chain of Responsibiliy rozwiazanie

• Stosujemy rekursywna kompozycje.
• Jeden-do-jednego agregacja (ma) na czubku
  hierarchii dziedziczenia
• Tworzymy liste dolaczana zorientowana-obiektowo

34
35
Chain of Responsibiliy diagram klas


35
36
Chain of Responsibiliy przyklad Java


36
37
Chain of Responsibiliy przyklad


37
38
Chain of Responsibiliy konsekwencje

• Pozwala zwolnic kod kliencki z obowiazku
  znajomosci klas obiektów docelowych, które
  obsluguja zadane zachowanie.
• Uproszczenie kodu po stronie hierarchii obiektów
  docelowych i po stronie klienta.
• Rozproszenie odpowiedzialnosci.

38
39
Zaleznosci miedzy wzorcami Chain of responsibility

• Chain of responsibility, command, mediator i
  observer dotycza rozdzielenia nadawców i
  odbiorców za pomoca róznych kompromisów.
• Chain of responsibility
• moze wykorzystywac command do reprezentacji zadan
  jako obiekty.
• jest czesto stosowany w polaczeniu z composite
  rodzic komponentu moze dzialac jako jego
  nastepca.

39
40
Flyweight (waga piórkowa)

• GoF wzorzec strukturalny
• Ma na celu skupienie odpowiedzialnosci w
  drobnych, wspóluzytkowanych obiektach

40
41
Flyweight problem

• Zaprojektowanie obiektów, tak aby otrzymac
  mozliwie najnizszy poziom ziarnistosci,
  dostarcza optymalnej elastycznosci, ale moze byc
  nie akceptowalne z punktu widzenia wydajnosci i
  zuzycia pamieci.

41
42
Flyweight rozwiazanie

• Pozostawiamy w klasie stan niezalezny od
  instancji.
• Stan zalezny od instancji dostarcza klient.
• Stosujemy fabryke wspomagajaca ponowne uzycie

42
43
Flyweight diagram klas


43
44
Flyweight przyklad Java
String s1 "hello" String s2 "hello"
//store in a string pool. String s3 new
String("hello") System.out.println(s1s2)
//true, share the same memory address
System.out.println(s1s3) //false

44
45
Flyweight przyklad


45
46
Flyweight konsekwencje

• Korzystanie z wspóldzielonych obiektów flyweight
  moze drastycznie zredukowac liczbe obiektów w
  pamieci.
• Zwieksza sie zlozonosc programu.
• Nie jest mozliwe rozróznienie miedzy bytami, a
  obiektami, które je reprezentuja.
• Wspóldzielone obiekty flyweight nie moga zawierac
  wskazników do obiektów rodziców.

46
47
Zaleznosci miedzy wzorcami Flyweight

• Pokazuje jak stworzyc wiele malych obiektów, a
  facade jeden reprezentujacy caly podsystem.
• Jest czesto stosowany w polaczeniu z composite,
  aby zaimplementowac wspóldzielone wezly liscie.
• Umozliwia wspóldzielenie symboli terminalnych w
  abstrakcyjnym drzewie skladni interpretera.
• Wyjasnia kiedy i jak obiekty stanu moga byc
  wspóldzielone.

47