Pobierz prezentację
Pobieranie prezentacji. Proszę czekać
1
Projektowanie obiektowe
Projektowanie obiektowe Wzorce projektowe Gang of Four Memento i Wzorce rozszerzeń 1 dr inż. Radosław Adamus dr inż. Radosław Adamus 1
2
Projektowanie obiektowe
Roadmap Decorator Iterator Visitor 2 dr inż. Radosław Adamus dr inż. Radosław Adamus 2
3
Projektowanie obiektowe
Wzorce rozszerzeń Mają na celu uczynić proces rozszerzania kodu bardziej czytelnym, prostym i dostępnym 3 dr inż. Radosław Adamus dr inż. Radosław Adamus 3
4
Projektowanie obiektowe
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); Jeżeli elipsa ma metodę poszerz się dwukrotnie, to mamy do czynienia z naruszeniem zasady LSP Oznaczana też LSP (Liskov's Substitutability Principle) Zasada zamienialności głosi, że w każdym miejscu programu, gdzie może być użyty pewien obiekt klasy K, może być także użyty obiekt, którego klasą jest podklasa klasy K. Przykładowo, wszędzie tam, gdzie można użyć liczby całkowitej, można także użyć liczby naturalnej; wszędzie tam, gdzie można użyć obiektu Osoba można także użyć obiektu Pracownik. Ponieważ obiekt podklasy klasy K zawiera więcej atrybutów niż obiekt klasy K, zasada ta oznacza ignorowanie wszystkich tych atrybutów, które „wystają” poza typ oczekiwany w danym miejscu programu. Zasada ta obejmuje również metody zawarte w klasach. Ma bardziej ogólne sformułowania (dla typów obiektów). Prowadzi niestety do pewnych anomalii: np. anomalii podstawienia, anomalii wielodziedziczenia, dylematu "wariancja czy kontr-wariancja", i innych. W jakich wzorcach występuje: ? 4 dr inż. Radosław Adamus dr inż. Radosław Adamus 4
5
Projektowanie obiektowe
Decorator GoF - wzorzec strukturalny Umożliwia programistom dynamiczne tworzenie zachowania obiektów. Wzorce rozszerzeń Wzorzec strukturalny Inna nazwa to WRAPPER 5 dr inż. Radosław Adamus dr inż. Radosław Adamus 5
6
Projektowanie obiektowe
Decorator – problem Potrzebujemy rozszerzyć zachowanie klasy, ale istnieją powody, dla których nie chcemy korzystać z dziedziczenia. Potrzebujemy dodać zachowanie lub stan do wybranych obiektów w czasie-wykonania, a dziedziczenie jest nieodpowiednie z powodu statyczności i faktu, że dotyczy całej klasy. 6 dr inż. Radosław Adamus dr inż. Radosław Adamus 6
7
Projektowanie obiektowe
Decorator – rozwiązanie Stosujemy rekursywną kompozycję. Agregacja 1 do 1: „składa się” w górę hierarchii dziedziczenia. Wprowadzamy pojedynczy rdzeniowy obiekt osłonięty przez możliwie wiele opcjonalnych obiektów. 7 dr inż. Radosław Adamus dr inż. Radosław Adamus 7
8
Projektowanie obiektowe
Decorator – diagram klas Wzorce rozszerzeń Wzorzec strukturalny PROBLEM: ROZWIĄZANIE: Zastosowanie rekursywnej kompozycji. Agregacja 1 do 1: „składa się” w górę hierarchii dziedziczenia. Pojedynczy rdzeniowy obiekt osłonięty przez możliwie wiele opcjonalnych obiektów Konfiguracja użytkownika dostarczająca opcjonalnych rozwiązań/właściwości do istniejącej klasy KONSEKWENCJE: 8 dr inż. Radosław Adamus dr inż. Radosław Adamus 8
9
Projektowanie obiektowe
Decorator – przykład The Decorator attaches additional responsibilities to an object dynamically. The ornaments that are added to pine or fir trees are examples of Decorators. Lights, garland, candy canes, glass ornaments, etc., can be added to a tree to give it a festive look. The ornaments do not change the tree itself which is recognizable as a Christmas tree regardless of particular ornaments used. As an example of additional functionality, the addition of lights allows one to "light up" a Christmas tree. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] Although paintings can be hung on a wall with or without frames, frames are often added, and it is the frame which is actually hung on the wall. Prior to hanging, the paintings may be matted and framed, with the painting, matting, and frame forming a single visual component. 9 dr inż. Radosław Adamus dr inż. Radosław Adamus 9
10
Projektowanie obiektowe
Decorator – konsekwencje Dostarcza większą elastyczność niż dziedziczenie. Wykorzystując różne kombinacje osłon, tworzy się wiele różnych kombinacji zachowań. Mniejsza liczba klas, kosztem większej liczby obiektów. Elastyczność osłon zwiększa ryzyko błędów. Trudno jest ustalić tożsamość obiektu, bo właściwe obiekty są za osłonami. 2. Dziedziczenie wymagałoby większej liczby nowych klas. 3. Utrudnia to debugowanie. 4. … też cykle. 10 dr inż. Radosław Adamus dr inż. Radosław Adamus 10
11
Projektowanie obiektowe
Zależności między wzorcami Dostarczany interfejs jest: inny – adapter, ten sam – proxy, rozszerzony – decorator. Decorator i proxy mają inne zastosowanie, ale podobne struktury (warstwa pośrednicząca). Decorator pozwala zmienić „skórę” obiektu, a strategy „bebechy”. ?nie?uzyto? Composite could use Chain of Responsibility to let components access global properties through their parent. It could also use Decorator to override these properties on parts of the composition. [GoF, p349] 11 dr inż. Radosław Adamus dr inż. Radosław Adamus 11
12
Projektowanie obiektowe
Zależności między wzorcami Composite i decorator za pomocą rekursywnej kompozycji organizują dowolną liczbę obiektów. Decorator może być postrzegany jako zdegenerowany composite, z jednym komponentem, ale jego celem nie jest agregacja. Decorator i composite są używane razem, bo się uzupełniają. 12 dr inż. Radosław Adamus dr inż. Radosław Adamus 12
13
Projektowanie obiektowe
Iterator GoF - wzorzec behawioralny Udostępnia sposób sekwencyjnego dostępu do elementów kolekcji 13 dr inż. Radosław Adamus dr inż. Radosław Adamus 13
14
Projektowanie obiektowe
Iterator – problem Potrzebujemy ujednolicić mechanizm przechodzenia (przeglądania) wysoce rożnych struktur danych, tak aby można było zdefiniować algorytmy zdolne do przezroczystego wzajemnego oddziaływania z każdą z nich. 14 dr inż. Radosław Adamus dr inż. Radosław Adamus 14
15
Projektowanie obiektowe
Iterator – rozwiązanie Stosujemy polimorfizm do przemierzania (iterowania). Przemierzanie kolekcji awansuje do statusu pełnego objektu. 15 dr inż. Radosław Adamus dr inż. Radosław Adamus 15
16
Projektowanie obiektowe
Iterator – diagram klas Wzorzec rozszerzeń Wzorzec behawioralny PROBLEM: ROZWIĄZANIE: Polimorficzne przemierzanie (iterowanie), Przemierzanie kolekcji awansuje do statusu pełnego obiektu KONSEKWENCJE: 16 dr inż. Radosław Adamus dr inż. Radosław Adamus 16
17
Projektowanie obiektowe
Iterator – przykład The Iterator provides ways to access elements of an aggregate object sequentially without exposing the underlying structure of the object. Files are aggregate objects. In office settings where access to files is made through administrative or secretarial staff, the Iterator pattern is demonstrated with the secretary acting as the Iterator. Several television comedy skits have been developed around the premise of an executive trying to understand the secretary's filing system. To the executive, the filing system is confusing and illogical, but the secretary is able to access files quickly and efficiently. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] On early television sets, a dial was used to change channels. When channel surfing, the viewer was required to move the dial through each channel position, regardless of whether or not that channel had reception. On modern television sets, a next and previous button are used. When the viewer selects the "next" button, the next tuned channel will be displayed. Consider watching television in a hotel room in a strange city. When surfing through channels, the channel number is not important, but the programming is. If the programming on one channel is not of interest, the viewer can request the next channel, without knowing its number. 17 dr inż. Radosław Adamus dr inż. Radosław Adamus 17
18
Projektowanie obiektowe
Iterator – konsekwencje Jest możliwy dostęp do kolekcji obiektów bez znajomości źródła obiektów. Używając wielu obiektów iteratorów, jest łatwo posiadać i zarządzać wieloma „przemierzeniami” naraz. Klasa kolekcji może dostarczać różne rodzaje iteratorów by przemierzać kolekcje w różny sposób. (np. klucze i wartości indeksów) 18 dr inż. Radosław Adamus dr inż. Radosław Adamus 18
19
Projektowanie obiektowe
Zależności między wzorcami Polimorficzne iteratory polegają na wzorcu factory method do utworzenia odpowiedniej podklasy iteratora. Memento używany jest często w połączeniu z iteratorem. Iterator używa memento by uchwycić stan iteracji. Iterator przechowuje memento wewnętrznie. 19 dr inż. Radosław Adamus dr inż. Radosław Adamus 19
20
Projektowanie obiektowe
Visitor GoF - wzorzec behawioralny. Umożliwia programistom zdefiniowanie nowej operacji dla hierarchii bez konieczności zmiany klas zawartych w tej hierarchii. 20 dr inż. Radosław Adamus dr inż. Radosław Adamus 20
21
Projektowanie obiektowe
Visitor – problem Wiele różnych i niezwiązanych operacji trzeba przeprowadzić na obiektach węzłowych w heterogenicznej złożonej strukturze, ale: Chcemy uniknąć „zanieczyszczania” klas węzłowych w te operacje. Nie chcemy wykonywać sprawdzenia typu każdego węzła i rzutować wskaźnik do właściwego typu przed wykonaniem pożądanej operacji. 21 dr inż. Radosław Adamus dr inż. Radosław Adamus 21
22
Projektowanie obiektowe
Visitor – rozwiązanie Podwójne rozdzielenie (double dispatch). Wybór wykonywanej operacji należy uzależnić od typu dwóch obiektów. Implementacja mechanizmu umożliwiającego dodawanie operacji do istniejącej hierarchii. OO messages routinely manifest "single dispatch" - the operation that is executed depends on: the name of the request, and the type of the receiver. In "double dispatch", the operation executed depends on: the name of the request, and the type of TWO receivers (the type of the Visitor and the type of the element it visits). 22 dr inż. Radosław Adamus dr inż. Radosław Adamus 22
23
Projektowanie obiektowe
Visitor – diagram klas (double dispatch) 23 dr inż. Radosław Adamus dr inż. Radosław Adamus 23
24
Projektowanie obiektowe
Visitor – diagram klas AbstractElement wykonuje firstDispatch. Visitor wykonuje secondDispatch. The Visitor pattern is the classic technique for recovering lost type information without resorting to dynamic casts. [Vlissides, "Type Laundering", C++ Report, Feb 97, p48] 24 dr inż. Radosław Adamus dr inż. Radosław Adamus 24
25
Projektowanie obiektowe
Visitor – diagram klas realizacja z nawigacją Struktura elementów nie musi wiedzieć o wizytorach. Nawigacja jest całkowicie po stronie wizytora. 25 dr inż. Radosław Adamus dr inż. Radosław Adamus 25
26
Projektowanie obiektowe
Visitor – przykład The Visitor pattern represents an operation to be performed on the elements of an object structure without changing the classes on which it operates. This pattern can be observed in the operation of a taxi company. When a person calls a taxi company (accepting a visitor), the company dispatches a cab to the customer. Upon entering the taxi the customer, or Visitor, is no longer in control of his or her own transportation, the taxi (driver) is. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 26 dr inż. Radosław Adamus dr inż. Radosław Adamus 26
27
Projektowanie obiektowe
Visitor – konsekwencje Ułatwia dodawanie nowych operacji on strukturze obiektów. Konkretne instancje klas struktury nie mają zależności z klasami visitora. Logika nowej operacji jest umieszczona w jednej spójnej klasie tzn. konkretnej implementacji visitora. Jedne obiekt visitora przechowuje stan potrzebny do wykonania operacji na strukturze obiektów. Dodanie nowej konkretnej klasy do struktury obiektów wymaga rozbudowy każdego istniejącego visitora. Klasy struktury muszą udostępnić visitorowi odpowiedni dostęp do ich stanu do przeprowadzenia operacji. 27 dr inż. Radosław Adamus dr inż. Radosław Adamus 27
28
Projektowanie obiektowe
Zależności między wzorcami Drzewo składni interpretera to composite, więc: iterator może przemierzać composite, visitor może wykonywać operację na composite. Visitor jest silniejszy niż command ponieważ może uruchamiać odpowiednią operacją dla napotkanego rodzaju obiektu. 28 dr inż. Radosław Adamus dr inż. Radosław Adamus 28
29
Projektowanie obiektowe
Podobieństwo strukturalne wzorców wrapper, delegacja, agregacja 29 dr inż. Radosław Adamus dr inż. Radosław Adamus 29
30
Projektowanie obiektowe
Podobieństwo strukturalne wzorców hierarchia dziedziczenia promote interface to a base class and bury implementation alternatives in derived classes 30 dr inż. Radosław Adamus dr inż. Radosław Adamus 30
31
Projektowanie obiektowe
Podobieństwo strukturalne wzorców osłona hierarchii dziedziczenia 31 dr inż. Radosław Adamus dr inż. Radosław Adamus 31
32
Projektowanie obiektowe
Podobieństwo strukturalne wzorców rekursywna kompozycja 32 dr inż. Radosław Adamus dr inż. Radosław Adamus 32
33
Projektowanie obiektowe
Podobieństwo strukturalne wzorców status pełnoprawnego obiektu 33 dr inż. Radosław Adamus dr inż. Radosław Adamus 33
Podobne prezentacje
© 2024 SlidePlayer.pl Inc.
All rights reserved.