Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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

Podobne prezentacje


Prezentacja na temat: "1 Projektowanie obiektowe Wzorce projektowe Gang of Four Wzorce odpowiedzialności."— Zapis prezentacji:

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

2 2 Roadmap Singleton Observer Mediator Proxy Flyweight Chain of responsibility

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

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

5 5 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 6 Singleton – rozwiązanie Wymuszamy określoną liczbę instancji klasy. Leniwa inicjalizacja. Dostęp globalny.

7 7 Singleton – diagram klas

8 8 Singleton – przykład

9 9 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 10 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 11 Observer GoF – wzorzec behawioralny Umożliwia oddzielić obiekt od znajomości obiektów od niego zależnych

12 12 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 13 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 14 Observer – diagram klas

15 15 Observer – przykład

16 16 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 17 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 18 Mediator GoF – wzorzec behawioralny Pozwala skupić odpowiedzialność w jednej klasie, nadzorującej interakcję innych obiektów

19 19 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 20 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 21 Mediator – diagram klas

22 22 Mediator – przykład

23 23 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 24 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 25 Proxy GoF – wzorzec strukturalny Pozwala obiektowi działać w imieniu innego obiektu

26 26 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 27 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 28 Proxy – diagram klas

29 29 Proxy – przykład

30 30 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 31 Odpowiedzialność Diagram klas z błędami

32 32 Chain of Responsibiliy GoF - wzorzec behawioralny Umożliwia przekazywanie żądania na coraz wyższe poziomy aż do znalezienia obiektu, który je obsłuży

33 33 Chain of Responsibiliy – problem Mamy potencjalnie zmienną liczbę obiektów obsługujących bądź przetwarzających oraz strumień żądań. Potrzebujemy wydajnie przetworzyć żądania nie tworząc twardych zależności i mapowań.

34 34 Chain of Responsibiliy – rozwiązanie Stosujemy rekursywną kompozycje. Jeden-do-jednego agregacja (ma) na czubku hierarchii dziedziczenia Tworzymy listę dołączaną zorientowaną-obiektowo

35 35 Chain of Responsibiliy – diagram klas

36 36 Chain of Responsibiliy – przykład Java

37 37 Chain of Responsibiliy – przykład

38 38 Chain of Responsibiliy – konsekwencje Pozwala zwolnić kod kliencki z obowiązku znajomości klas obiektów docelowych, które obsługują żądane zachowanie. Uproszczenie kodu po stronie hierarchii obiektów docelowych i po stronie klienta. Rozproszenie odpowiedzialności.

39 39 Zależności między wzorcami Chain of responsibility Chain of responsibility, command, mediator i observer dotyczą rozdzielenia nadawców i odbiorców za pomocą różnych kompromisów. Chain of responsibility: może wykorzystywać command do reprezentacji żądań jako obiekty. jest często stosowany w połączeniu z composite; rodzic komponentu może działać jako jego następca.

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

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

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

43 43 Flyweight – diagram klas

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

45 45 Flyweight – przykład

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

47 47 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. Umożliwia współdzielenie symboli terminalnych w abstrakcyjnym drzewie składni interpretera. Wyjaśnia kiedy i jak obiekty stanu mogą być współdzielone.


Pobierz ppt "1 Projektowanie obiektowe Wzorce projektowe Gang of Four Wzorce odpowiedzialności."

Podobne prezentacje


Reklamy Google