Projektowanie obiektowe Wzorce projektowe. Gang of Four Wzorce odpowiedzialności

Wielkość: px

Rozpocząć pokaz od strony:

Download "Projektowanie obiektowe Wzorce projektowe. Gang of Four Wzorce odpowiedzialności"

Kajetan Sadowski
6 lat temu
Przeglądów:

1 Projektowanie obiektowe Wzorce projektowe Gang of Four Wzorce odpowiedzialności 1

2 Roadmap Singleton Observer Mediator Proxy Flyweight 2

3 Wzorce odpowiedzialności Udostępniają techniki centralizacji, delegowania i ograniczania odpowiedzialności zwykłych obiektów 3

4 Odpowiedzialność Kontrakt lub zobowiązanie klasyfikatora Zobowiązania związane z działaniem, to np.: wykonywanie pewnej czynności przez obiekt, jak tworzenie innego obiektu lub przeprowadzanie obliczeń inicjalizacja czynności wykonywanych przez inny obiekt (zmuszenie innego obiektu do wykonania czynności) kontrola i koordynacja czynności wykonywanych przez inne obiekty Zobowiązania związane z wiedzą, to np.: znajomość prywatnych, ukrytych danych, wiedza o obiektach powiązanych, wiedza nt. możliwości operacyjnych obiektu. 4

5 Singleton GoF wzorzec kreacyjny Umożliwienie skupienia całej odpowiedzialności w jednej instancji klasy 5

6 Singleton problem Aplikacja potrzebuje dokładnie jednej instancji klasy. Obiekt ten ma być dostępny globalnie, a jego inicjalizacja z reguły opóźniona do pierwszej próby dostępu. 6

7 Singleton rozwiązanie Wymuszamy określoną liczbę instancji klasy. Leniwa inicjalizacja. Dostęp globalny. 7

8 Singleton diagram klas 8

9 Singleton przykład 9

10 Singleton konsekwencje Istnieje dokładnie jedna instancja klasy singleton Metoda getinstance() klasy singleton hermetyzuje politykę tworzenia dla klasy singleton tak, że klasy ją używające nie zależą od szczegółów implementacyjnych tej metody. Inne klasy, które chcą się odwoływać do jedynej instancji singleton, muszą użyć statycznej metody getinstance(). Dziedziczenie po klasie singleton jest niewygodne: trzeba utworzyć nie prywatny konstruktor, nie można przesłonić statycznej getinstance(). 10

11 Zależności między wzorcami Następujące wzorce mogą użyć singletona w swojej implementacji: abstract factory, builder, prototype. Singletony często to obiekty: facade (jest potrzebny tylko jeden), state. 11

12 Observer GoF wzorzec behawioralny Umożliwia oddzielić obiekt od znajomości obiektów od niego zależnych 12

13 Observer problem Duży monolityczny kod nie skaluje się dobrze, gdy rośną wymagania w stosunku do wizualizacji i monitorowania aplikacji. Obiekt jest obarczony odpowiedzialnością informowania swoich klientów o zmianach istotnych atrybutów, mimo że to klient wie, które atrybuty są dla niego istotne. 13

14 Observer rozwiązanie Struktura: Osłona/Delegacja. osłona hermetyzuje (enkapsuluje) rdzeń logiki biznesowej każda delegacja dostarcza konfigurowalną przez użytkownika, opcjonalną funkcjonalność 14

15 Observer diagram klas 15

16 Observer przykład 16

17 Observer konsekwencje Objekt dostarcza powiadomienia innym obiektom bez świadomości nadawcy i odbiorcy o sobie nawzajem. Dostarczanie powiadomień może trwać długo. Ryzyko cyklicznych powiadomień. 17

18 Zasada hermetyzacji zmienności Polega na ukryciu za jednolitym interfejsem wielu różnych implementacji. Pozwala: wyeliminować powtarzalność kodu, wykorzystywać różne elementy aplikacji w jednolity sposób. 18

19 Mediator GoF wzorzec behawioralny Pozwala skupić odpowiedzialność w jednej klasie, nadzorującej interakcję innych obiektów 19

20 Mediator problem Potrzebujemy zaprojektować komponenty wielokrotnego użytku, ale zależności między fragmentami, które mogą być potencjalnie wielokrotnie używane, wykazuje fenomen kodu spagetti. Złożoność interakcji między obiektami zbliża się do najbardziej skomplikowanego układu. 20

21 Mediator rozwiązanie Wprowadzamy dodatkowy poziom pośredniczący, który hermetyzuje relacje wiele-do-wielu między innymi komponentami Struktura: Osłona/Delegacja. osłona jest obiektem mapującym. delegacje są sieci współpracujących obiektów Stosujemy poprawny politycznie menadżer (tzw. God object) 21

22 Mediator diagram klas 22

23 Mediator przykład 23

24 Mediator konsekwencje Większość złożoności związanej z zarządzaniem zależnościami jest przesunięte do obiektu mediatora. To ułatwia implementacje i utrzymanie innych obiektów. Przesunięcie logiki zależności dla innych klas w jednej klasie mediatora ułatwia programistom znalezienie zależności. Klasy mediatora z reguły nie umożliwiają ponownego użycia, ponieważ kod obsługujący zależności jest specyficzny dla aplikacji. 24

25 Zależności między wzorcami Mediator Mediator jest podobny do facade wyławiając funkcjonalność istniejących klas, z tym że mediator jest znany przez klasy podsystemu i wprowadza do niego nową funkcjonalność. Mediator i observer są rywalizującymi wzorcami: observer rozprasza komunikacje, mediator hermetyzuje komunikacje. Mediator może skorzystać z observera w celu dynamicznej rejestracji i zarządzenia kolegów. 25

26 Proxy GoF wzorzec strukturalny Pozwala obiektowi działać w imieniu innego obiektu 26

27 Proxy problem Potrzebujemy obsługiwać zasobo-żerne obiekty, ale możemy odłożyć ich tworzenie do momentu, gdy będą faktycznie zażądane przez klienta. Poprawny obiekt z jakiegoś względu nie jest w stanie przeprowadzić zadeklarowanych działań (np. z uwagi długiego czasu ładowania obiektu) 27

28 Proxy rozwiązanie Wprowadzamy dodatkową warstwę pośredniczącą, która dostarcza dodatkową funkcjonalność: rozproszoną komunikację logowanie, rewizje, smart-pointer (sprytny wskaźnik). Struktura: Osłona/Delegacja. 28

29 Proxy diagram klas 29

30 Proxy przykład 30

31 Proxy konsekwencje Dostęp do klas przez pozostałą część programu jest realizowany przez wirtualne proxy. Udostępniane objekty są tworzone dopiero, gdy są potrzebne. Klasy wykorzystujące proxy nie potrzebują wiedzieć, która obsługująca klasa jest załadowana, albo czy taka klasa bądź jej instancja istnieje Wszystkie klasy inne niż proxy muszą odwoływać się do usług pośrednio przez klasę proxy. (Inaczej usługa może być załadowana zanim będzie potrzebna) 31

32 Odpowiedzialność Diagram klas z błędami 32

33 Zasada podstawienia (LSP) Barbary Liskov Instancja klasy powinna funkcjonować jako instancja jej klasy nadrzędnej. np.: Wyrażenie pi = new Liczba( ); Elipsa o = new Okrag(6); 33

34 Flyweight (waga piórkowa) GoF wzorzec strukturalny Ma na celu skupienie odpowiedzialności w drobnych, współużytkowanych obiektach 34

35 Flyweight problem Zaprojektowanie obiektów, tak aby otrzymać możliwie najniższy poziom ziarnistości, dostarcza optymalnej elastyczności, ale może być nie akceptowalne z punktu widzenia wydajności i zużycia pamięci. 35

36 Flyweight rozwiązanie Pozostawiamy w klasie stan niezależny od instancji. Stan zależny od instancji dostarcza klient. Stosujemy fabrykę wspomagającą ponowne użycie 36

37 Flyweight diagram klas 37

38 Flyweight przykład Java String s1 = "hello"; String s2 = "hello"; //store in a string pool. String s3 = new String("hello"); System.out.println(s1==s2); //true, share the same memory address System.out.println(s1==s3); //false 38

39 Flyweight przykład 39

40 Flyweight konsekwencje Korzystanie z współdzielonych obiektów flyweight może drastycznie zredukować liczbę obiektów w pamięci. Zwiększa się złożoność programu. Nie jest możliwe rozróżnienie między bytami, a obiektami, które je reprezentują. Współdzielone obiekty flyweight nie mogą zawierać wskaźników do obiektów rodziców. 40

41 Zależności między wzorcami Flyweight Pokazuje jak stworzyć wiele małych obiektów, a facade jeden reprezentujący cały podsystem. Jest często stosowany w połączeniu z composite, aby zaimplementować współdzielone węzły liście. 41

Podobne dokumenty

Projektowanie obiektowe Wzorce projektowe

Projektowanie obiektowe Wzorce projektowe Gang of Four Kreacyjne wzorce projektowe (wzorce konstrukcyjne) 1 Roadmap Memento Factory Method Abstract Factory Prototype Builder 2 Wzorce konstrukcyjne wzorce