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

Projektowanie obiektowe Roadmap Decorator Iterator Visitor 2 dr inż. Radosław Adamus dr inż. Radosław Adamus 2

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

Projektowanie obiektowe Zasada podstawienia (LSP) Barbary Liskov Instancja klasy powinna funkcjonować jako instancja jej klasy nadrzędnej. np.: Wyrażenie pi = new Liczba(3.14159); 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Projektowanie obiektowe Visitor – diagram klas (double dispatch) 23 dr inż. Radosław Adamus dr inż. Radosław Adamus 23

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

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

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

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

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

Projektowanie obiektowe Podobieństwo strukturalne wzorców wrapper, delegacja, agregacja 29 dr inż. Radosław Adamus dr inż. Radosław Adamus 29

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

Projektowanie obiektowe Podobieństwo strukturalne wzorców osłona hierarchii dziedziczenia 31 dr inż. Radosław Adamus dr inż. Radosław Adamus 31

Projektowanie obiektowe Podobieństwo strukturalne wzorców rekursywna kompozycja 32 dr inż. Radosław Adamus dr inż. Radosław Adamus 32

Projektowanie obiektowe Podobieństwo strukturalne wzorców status pełnoprawnego obiektu 33 dr inż. Radosław Adamus dr inż. Radosław Adamus 33