Projektowanie obiektowe Projektowanie obiektowe Wzorce projektowe Gang of Four Behawioralne wzorce projektowe (Wzorce operacji) 1 dr inż. Radosław Adamus dr inż. Radosław Adamus 1

Projektowanie obiektowe Roadmap Template method State Strategy Command Interpreter 2 dr inż. Radosław Adamus dr inż. Radosław Adamus 2

Projektowanie obiektowe Wzorce behawioralne Wzorce operacji wzorce behawioralne umożliwiają organizację, zarządzanie i łączenie zachowań. wzorce operacji (template method, state, strategy, command, interpreter) dotyczą głównie sytuacji, gdy w projekcie potrzeba wielu metod zazwyczaj z identyczną sygnaturą. 3 dr inż. Radosław Adamus dr inż. Radosław Adamus 3

Projektowanie obiektowe Pojęcia algorytm … operacja … metoda … sygnatura … Metoda jest implementacją operacji. (inaczej: implementacja operacji jest zwana metodą) Sygnatura metody to nazwa metody wraz z typami parametrów. Typ wartości zwracanej przez metodę nie stanowi części jej sygnatury. 4 dr inż. Radosław Adamus dr inż. Radosław Adamus 4

Projektowanie obiektowe Template Method Zaimplementowanie algorytmu (w postaci metody) umożliwiając „opóźnienie” kilku kroków jego wykonania tak, aby klasy podrzędne mogły je ponownie zdefiniować. Wzorzec operacji Wzorzec behawioralny 5 dr inż. Radosław Adamus dr inż. Radosław Adamus 5

Projektowanie obiektowe Template Method – problem Dwa odmienne komponenty mają znaczące podobieństwa, ale nie korzystają z ponownego użycia ani wspólnego interfejsu ani implementacji. Jeżeli zmiana wspólnej części staje się konieczna, to niepotrzebnie dublowana jest praca. 6 dr inż. Radosław Adamus dr inż. Radosław Adamus 6

Projektowanie obiektowe Template Method – rozwiązanie Daj możliwość skonfigurowania kroku algorytmu. Określany w klasie bazowej krok algorytmu zostawiamy do zaimplementowania w klasach pochodnych. 7 dr inż. Radosław Adamus dr inż. Radosław Adamus 7

Projektowanie obiektowe Template Method – diagram klas 8 dr inż. Radosław Adamus dr inż. Radosław Adamus 8

Projektowanie obiektowe Template Method – przykład The Template Method defines a skeleton of an algorithm in an operation, and defers some steps to subclasses. Home builders use the Template Method when developing a new subdivision. A typical subdivision consists of a limited number of floor plans with different variations available for each. Within a floor plan, the foundation, framing, plumbing, and wiring will be identical for each house. Variation is introduced in the later stages of construction to produce a wider variety of models. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 9 dr inż. Radosław Adamus dr inż. Radosław Adamus 9

Projektowanie obiektowe Template Method – konsekwencje Programista piszący podklasę abstrakcyjnej klasy szablonu jest zmuszony nadpisać te metody, których implementacja jest konieczna, żeby uzupełnić logikę nadklasy. Dobrze skonstruowana klasa szablonu ma strukturę, która dostarcza programiście wskazówki dotyczące podstawowej struktury jej podklas 10 dr inż. Radosław Adamus dr inż. Radosław Adamus 10

Projektowanie obiektowe State Rozdystrybuowanie operacji na kilka klas w taki sposób, żeby każda klasa reprezentowała różny stan. Wzorzec operacji Wzorzec behawioralny 11 dr inż. Radosław Adamus dr inż. Radosław Adamus 11

Projektowanie obiektowe State - problem Zachowanie jednolitego obiektu jest zależne od jego stanu. Konieczna jest zmiana jego zachowania w czasie wykonania w zależności od bieżącego stanu. Aplikacja jest określona przez rozległe i liczne instrukcje warunkowe (if, switch, etc.), które kierunkują przepływ sterowania w zależności od stanu aplikacji. 12 dr inż. Radosław Adamus dr inż. Radosław Adamus 12

Projektowanie obiektowe State - rozwiązanie Struktura osłona/delegacja: osłona przekazuje wskaźnik do siebie („this”), delegacja współpracuje z osłoną. 13 dr inż. Radosław Adamus dr inż. Radosław Adamus 13

Projektowanie obiektowe State – diagram klas Edytor linuxowy VIM: ESC - przejście ze stanu Insert do CommandKey : - przejście ze stanu CommandKey do CommandLine itd. Przykładowy fragment kodu metody handleKey() dla stanu Insert odpowiadający theKey ESC: editor.setMode(commandKey); 14 dr inż. Radosław Adamus dr inż. Radosław Adamus 14

Projektowanie obiektowe State – przykład The State pattern allows an object to change its behavior when its internal state changes. This pattern can be observed in a vending machine. Vending machines have states based on the inventory, amount of currency deposited, the ability to make change, the item selected, etc. When currency is deposited and a selection is made, a vending machine will either deliver a product and no change, deliver a product and change, deliver no product due to insufficient currency on deposit, or deliver no product due to inventory depletion. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 15 dr inż. Radosław Adamus dr inż. Radosław Adamus 15

Projektowanie obiektowe State - konsekwencje Kod dla każdego stanu znajduje się w osobnej klasie. Można dodawać niezależnie wiele nowych stanów. Dla klienta obiektów stanu, przejścia między stanami występują pomiędzy „atomowymi” operacjami. Unikamy stosowania instrukcji switch lub łańcuchów if-else w wielu metodach, przekierowując obsługę do kodu określonego w stanie. Nie unikamy jednak instrukcji switch lub łańcuchów if-else rozdzielających obsługę zdarzenia w ramach bieżącego stanu. 16 dr inż. Radosław Adamus dr inż. Radosław Adamus 16

Projektowanie obiektowe Zasada „otwarcia i zamknięcia” Open-closed principle [Bertrand Meyer, 1988]: „Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” Zwiększenie potencjału ponownego użycia: raz zdefiniowana klasa może być wielokrotnie użyta dla stworzenia jej specjalizacji. Ewentualne modyfikacje zakończonego komponentu powinny dotyczyć poprawiania błędów. np. State: dodawanie nowych stanów (mechanizm rozszerzania) odbywa się w dużym stopniu niezależnie (brak konieczności modyfikowania istniejącej implementacji) Bridge Template Method Kolejny wzorzec Strategy u swoich podstaw ma tą właśnie zasadę. 17 dr inż. Radosław Adamus dr inż. Radosław Adamus 17

Projektowanie obiektowe Strategy Polega na hermetyzowaniu operacji umożliwiając stworzenie zamiennych implementacji. Wzorzec operacji Wzorzec behawioralny 18 dr inż. Radosław Adamus dr inż. Radosław Adamus 18

Projektowanie obiektowe Strategy - problem Złożoność kodu wynikająca z istnienia wielu strategii dotyczących określonego problemu. Potrzeba budowy oprogramowania zorientowanego-obiektowo ze zminimalizowaną liczbą zależności. 19 dr inż. Radosław Adamus dr inż. Radosław Adamus 19

Projektowanie obiektowe Strategy - rozwiązanie Daj możliwość skonfigurowania wyboru algorytmu Struktura osłona/delegacja klient jest osłoną, obiekt algorytm jest delegacją. Dodanie poziomu pośredniego dla klienta (np. interfejsu). 20 dr inż. Radosław Adamus dr inż. Radosław Adamus 20

Projektowanie obiektowe Strategy – diagram klas 21 dr inż. Radosław Adamus dr inż. Radosław Adamus 21

Projektowanie obiektowe Strategy – przykład "A Strategy defines a set of algorithms that can be used interchangeably. Modes of transportation to an airport is an example of a Strategy. Several options exist such as driving one's own car, taking a taxi, an airport shuttle, a city bus, or a limousine service. For some airports, subways and helicopters are also available as a mode of transportation to the airport. Any of these modes of transportation will get a traveler to the airport, and they can be used interchangeably. The traveler must chose the Strategy based on tradeoffs between cost, convenience, and time." [Duell, p54] 22 dr inż. Radosław Adamus dr inż. Radosław Adamus 22

Projektowanie obiektowe Strategy - konsekwencje Zachowanie obiektów klienta może być określone za pomocą obiektów. Wzorzec upraszcza klasy klienta przez zwolnienie ich z odpowiedzialności wyboru zachowania lub implementacji alternatywnych zachowań. Upraszcza kod dla obiektów klienta poprzez eliminacje instrukcji if oraz switch. W niektórych przypadkach może zwiększyć szybkość obiektów klienta ponieważ nie potrzebują dokonywać wyboru zachowania. 23 dr inż. Radosław Adamus dr inż. Radosław Adamus 23

Projektowanie obiektowe Zależności między wzorcami Dokonuje się zmiany: w części algorytmu poprzez dziedziczenie – Template Method, całości algorytmu poprzez delegacje – Strategy. Modyfikowana jest logika: całej klasy – Template Method, indywidualnych obiektów – Strategy. 24 dr inż. Radosław Adamus dr inż. Radosław Adamus 24

Projektowanie obiektowe Wzorzec Strategy czy Template Method ? Comprator dostarcza strategie porównywania 25 dr inż. Radosław Adamus dr inż. Radosław Adamus 25

Projektowanie obiektowe Command Ma na celu hermetyzowanie wywołania metody w obiekcie. Umożliwia traktowanie „wywołania metody obiektu” jako pełnoprawnego obiektu (promocja). Wzorzec operacji Wzorzec behawioralny 26 dr inż. Radosław Adamus dr inż. Radosław Adamus 26

Projektowanie obiektowe Command - problem Potrzeba wydania żądania do obiektów bez żadnej wiedzy na temat: operacji, która jest żądana, lub odnośnie odbiorcy żądania. 27 dr inż. Radosław Adamus dr inż. Radosław Adamus 27

Projektowanie obiektowe Command - rozwiązanie Polecenie („Callback”) ma być zorientowane-obiektowo, czyli zdefiniuj klasę zawierającą: wskaźnik do obiektu, wskaźnik do funkcji, wszystkie potrzebne argumenty funkcji. Zadeklaruj metodę „execute”. Zaprojektuj polecenie, aby pełniło rolę „magicznego ciasteczka”, które hermetyzuje wywołanie metody. 28 dr inż. Radosław Adamus dr inż. Radosław Adamus 28

Projektowanie obiektowe Command – diagram klas 29 dr inż. Radosław Adamus dr inż. Radosław Adamus 29

Projektowanie obiektowe Command – przykład The Command pattern allows requests to be encapsulated as objects, thereby allowing clients to be parameterized with different requests. The "check" at a diner is an example of a Command pattern. The waiter or waitress takes an order or command from a customer and encapsulates that order by writing it on the check. The order is then queued for a short order cook. Note that the pad of "checks" used by each waiter is not dependent on the menu, and therefore they can support commands to cook many different items. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 30 dr inż. Radosław Adamus dr inż. Radosław Adamus 30

Projektowanie obiektowe Command - konsekwencje Obiekt, który wywołuje polecenie, nie jest tym samym obiektem, który je wykonuje. Ta separacja umożliwia elastyczne zarządzanie poleceniami (np. kolejkowanie, grupowanie, delegowanie) Takie podejście umożliwia „nagrywanie” ciągu poleceń (np. makra) i powtarzanie ich później. Można zastosować do tego wzorzec composite. Dodawanie nowych poleceń jest uproszczone, gdyż nie zrywa się żadnych zależności. 31 dr inż. Radosław Adamus dr inż. Radosław Adamus 31

Projektowanie obiektowe Interpreter Rozdystrybuowanie operacji w taki sposób, żeby każda implementacja odnosiła się do innego typu kompozycji. Wzorzec operacji Wzorzec behawioralny 32 dr inż. Radosław Adamus dr inż. Radosław Adamus 32

Projektowanie obiektowe Interpreter - problem Pewna klasa problemów występuje wielokrotnie w dobrze określonej i dobrze zrozumianej domenie. Jeżeli domenę można opisać poprzez język, to można te problemy w prosty sposób rozwiązywać przez zastosowanie silnika interpretera. 33 dr inż. Radosław Adamus dr inż. Radosław Adamus 33

Projektowanie obiektowe Interpreter - rozwiązanie Zdefiniuj opis gramatyki języka interpretowalnego. Zbuduj kompozycje - agregacja 1 do wielu: „składa się” w górę hierarchii dziedziczenia. Zastosowanie rekursywnej kompozycji. 34 dr inż. Radosław Adamus dr inż. Radosław Adamus 34

Projektowanie obiektowe Interpreter – diagram klas Przykłady: Rzymski System Liczbowy, ONP - odwrotna notacja polska, SQL, Kompilacja, Języki skryptowe. Znaczenie kontekstu np.: przechowywanie zmiennych, działanie iteratorów (lub operatorów niealgebraicznych) np. foreach (x:tablicaLiczb) suma+=x; wynik działania prawej strony (suma+=x) zależy od wartości wyliczonej po lewej stronie. 35 dr inż. Radosław Adamus dr inż. Radosław Adamus 35

Projektowanie obiektowe Interpreter – przykład The Intepreter pattern defines a grammatical representation for a language and an interpreter to interpret the grammar. Musicians are examples of Interpreters. The pitch of a sound and its duration can be represented in musical notation on a staff. This notation provides the language of music. Musicians playing the music from the score are able to reproduce the original pitch and duration of each sound represented. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] Sama informacja o nutach jest niewystarczająca. Kontekstem interpretacji jest tempo, tonacja, itp. Muzyk interpretuje, a kontekstem (troche „naciągając”) może być instrument. 36 dr inż. Radosław Adamus dr inż. Radosław Adamus 36

Projektowanie obiektowe Interpreter - konsekwencje Elastyczność i ponowne użycie w różnych kontekstach. Rozwiązanie problemów zgodnie z tym wzorcem pogarsza wydajność, np. przez tworzenie wielu instancji obiektów dla prostych struktur (np. liczb). Alternatywne rozwiązania często wymagałyby mniejszej ilości kodu. 37 dr inż. Radosław Adamus dr inż. Radosław Adamus 37

Projektowanie obiektowe Zależności między wzorcami Drzewo składni Interpretera to Composite State może być użyty do definicji kontekstu Interpretera. State i Strategy są podobne, ale: state jest bardziej dynamiczny. Struktura wzorców State, Strategy, Bridge (i trochę Adapter) jest podobna – element uchwyt. 38 dr inż. Radosław Adamus dr inż. Radosław Adamus 38