Projektowanie obiektowe Projektowanie obiektowe Wzorce projektowe Gang of Four Strukturalne wzorce projektowe (Wzorce interfejsów) 1 dr inż. Radosław Adamus dr inż. Radosław Adamus 1

Projektowanie obiektowe Roadmap Adapter Bridge Composite Facade 2 dr inż. Radosław Adamus dr inż. Radosław Adamus 2

Projektowanie obiektowe Wzorce strukturalne Wzorce interfejsów wzorce strukturalne dotyczą powszechnych sposobów organizacji obiektów różnego typu, aby mogły współpracować ze sobą. wzorce interfejsów (adapter, bridge, composite, facade) dotyczą problemów wymagających zdefiniowania lub przedefiniowania dostępu do klasy lub grup klas 3 dr inż. Radosław Adamus dr inż. Radosław Adamus 3

Projektowanie obiektowe Adapter Zaadoptowanie istniejącego interfejsu klasy do postaci oczekiwanej przez klienta. Udostępnienie interfejsu wymaganego przez klienta przy jednoczesnym wykorzystaniu usług klasy o innym interfejsie. 4 dr inż. Radosław Adamus dr inż. Radosław Adamus 4

Projektowanie obiektowe Adapter - Problem Niepowiązane klasy, komponenty rozwijane w różnym czasie lub równolegle mają ze sobą współpracować. Dobry program, do którego kodu nie mamy dostępu, ma działać i być odpowiednio wykorzystany . Niekompatybilny interfejs. Problem niezgodności impedancji (impedance mismatch). 5 dr inż. Radosław Adamus dr inż. Radosław Adamus 5

Projektowanie obiektowe Adapter - Rozwiązanie Osłaniamy istniejący kod nowymi interfejsami. Dopasowujemy impedancje starych komponentów do nowego systemu (często rozwiązanie pozorne! – tj. jak przyszycie starej łaty do nowych spodni) Struktura: Osłona/Delegacja. 6 dr inż. Radosław Adamus dr inż. Radosław Adamus 6

Projektowanie obiektowe Adapter – diagram klas 7 dr inż. Radosław Adamus dr inż. Radosław Adamus 7

Projektowanie obiektowe Adapter – diagram klas (przykład) 8 dr inż. Radosław Adamus dr inż. Radosław Adamus 8

Projektowanie obiektowe Adapter – przykład The Adapter pattern allows otherwise incompatible classes to work together by converting the interface of one class into an interface expected by the clients. Socket wrenches provide an example of the Adapter. A socket attaches to a ratchet, provided that the size of the drive is the same. Typical drive sizes in the United States are 1/2" and 1/4". Obviously, a 1/2" drive ratchet will not fit into a 1/4" drive socket unless an adapter is used. A 1/2" to 1/4" adapter has a 1/2" female connection to fit on the 1/2" drive ratchet, and a 1/4" male connection to fit in the 1/4" drive socket. [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 Adapter - Konsekwencje Klient i adaptowany komponent (klasa, metoda, itp.) pozostają niezależne. Można używać klas adaptera do określenia jaka metoda obiektu ma być wywołana przez klienta (np. jeden adapter wywołuję metodę rysującą linię ciągłą, a drugi wywołuję metodę rysującą linię przerywaną) Adapter dodaje warstwę pośrednią w programie: negatywny wpływ na wydajność, trudność zrozumienia aplikacji. 10 dr inż. Radosław Adamus dr inż. Radosław Adamus 10

Projektowanie obiektowe Co to jest delegacja? Po prostu: przekazywanie (delegowanie) żądania (operacji) przez obiekt odbierający komunikat do realizacji przez inny obiekt (tzw. delegat) Zwiększenie ponownego użycia poprzez zastosowanie agregacji zamiast dziedziczenia Delegation Delegation is a way of making composition as powerful for reuse as inheritance. In delegation, two objects are involved in handling a request: a receiving object delegates operations to its delegate. This is analogous to subclasses deferring requests to parent classes. But with inheritance, an inherited operation can always refer to the receiving object through the this member variable in C++ and self in Smalltalk. To achieve the same effect with delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver. For example, instead of making class Window a subclass of Rectangle (because windows happen to be rectangular), the Window class might reuse the behavior of Rectangle by keeping a Rectangle instance variable and delegating Rectangle-specific behavior to it. In other words, instead of a Window being a Rectangle, it would have a Rectangle. Window must now forward requests to its Rectangle instance explicitly, whereas before it would have inherited those operations. 11 dr inż. Radosław Adamus dr inż. Radosław Adamus 11

Projektowanie obiektowe Delegacja – przykład C# // <- Deklaracja (typu) delegacji mogącej wywoływać metody pobierające parametr typu string i zwracające int. delegate int Policz (string s); // <- Utworzenie obiektu delegacji Policz p = new Policz( nazwaMetody ); // <- Wywołanie metody wskazywanej przez delegację p(„10*10”); Delegacja w C# pozwala utworzyć nowy typ danych, który definiuje sygnaturę metody. Obiekty delegacji mogą wywoływać metody zgodne z ich sygnaturą. Przykładowa NazwaMetody: Kalkulator.obliczWrazenie -> static int obliczWrazenie (String obliczWyrazenie) kalk.obliczWrazenie -> int obliczWrazenie (String obliczWyrazenie) 12 dr inż. Radosław Adamus dr inż. Radosław Adamus 12

Projektowanie obiektowe Prymitywna delegacja – przykład java Interface DelegacjaPolicz { int policz(string s); } DelegacjaPolicz p = new DelegacjaPolicz() { … int policz (string s) { // wywołanie odpowiedniej metody }; p.policz(„10*10”); 13 dr inż. Radosław Adamus dr inż. Radosław Adamus 13

Projektowanie obiektowe Bridge – wprowadzenie do problemu Hierarchia klas mechanizmów szeregowania wątków Hierarchia jest zbudowana na podstawie: - algorytmu szeregowania (pierwszy dyskryminator) np. Preemtive scheduling – szeregowanie z wywłaszczeniem (np. na podstawie priorytetów wątków) api systemu operacyjnego (drugi dyskryminator) (KK) Dodanie obsługi api kolejnej platformy wymaga dodania dwóch klas. Ilu klas wymagałoby dodanie np. nowego algorytmu szeregowania (??) Takie podejście prowadzi do „eskalacji” klas 14 dr inż. Radosław Adamus dr inż. Radosław Adamus 14

Projektowanie obiektowe Bridge Oddzielenie operacji abstrakcyjnych od ich implementacji w celu umożliwienia wprowadzenia w nich niezależnych zmian Użyteczny, gdy mamy do czynienia z hierarchią abstrakcji i odpowiadającą hierarchią implementacji, w celu ich rozłączenia. 15 dr inż. Radosław Adamus dr inż. Radosław Adamus 15

Projektowanie obiektowe Bridge - Problem Brak odseparowania implementacji od interfejsu. Potrzeba poprawienia możliwości rozbudowy klas, zarówno implementacji, jak i interfejsu (m.in. przez dziedziczenie), Potrzeba ukrycia implementacji od klienta, w celu umożliwienia zmiany implementacji bez zmian interfejsu Kilka odpowiednich abstrakcji ma korzystać z tej samej implementacji Potrzeba rozbudowy hierarchii klas prowadzi do zjawiska „eskalacji” liczby klas w projekcie. 16 dr inż. Radosław Adamus dr inż. Radosław Adamus 16

Projektowanie obiektowe Bridge - Rozwiązanie Pozwolenie na zmiany implementacji oraz pozostawienie stabilnego interfejsu. Struktura: Osłona/Delegacja osłona to hierarchia, która dostarcza interfejs delegacja to hierarchia, która ukrywa bagaż implementacji Izolacja: koperta/list, (więcej niż enkapsulacja) 17 dr inż. Radosław Adamus dr inż. Radosław Adamus 17

Projektowanie obiektowe Bridge – przykład (szeregowanie wątków) Po prawej stronie (patrz rysunek) mamy hierarchie (dziedziczenia) implementacji ze wspólnym interfejsem. Po lewej stronie mamy hierarchie abstrakcji, tzn. taką którą planujemy wyposażać w nowe operacje korzystające ze wspólnej chociaż nieznanej implementacji. 18 dr inż. Radosław Adamus dr inż. Radosław Adamus 18

Projektowanie obiektowe Bridge – diagram klas Pytanie: Obiekt, z którego korzysta klient (ten należący do hierarchii abstrakcji) jest niezależny od konkretnego obiektu hierarchii implementacji. Chcemy utrzymać wyłącznie zależność z interfejsem. Jak to można zrealizować? Odpowiedzi: przekazanie w obiektu w konstruktorze, setter, itp. wymagające konfiguracji (więcej informacji kilka slajdów później) np. sterowniki urządzeń i baz danych 19 dr inż. Radosław Adamus dr inż. Radosław Adamus 19

Projektowanie obiektowe Bridge – przykład The Bridge pattern decouples an abstraction from its implementation, so that the two can vary independently. A household switch controlling lights, ceiling fans, etc. is an example of the Bridge. The purpose of the switch is to turn a device on or off. The actual switch can be implemented as a pull chain, simple two position switch, or a variety of dimmer switches. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] Np. dodanie metody reset() {off(); on();} możliwe po stronie abstrakcji. 20 dr inż. Radosław Adamus dr inż. Radosław Adamus 20

Projektowanie obiektowe Bridge - Konsekwencje Bridge utrzymuje niezależność między klasami reprezentującymi abstrakcje i dostarczającymi implementacje abstrakcji. Abstrakcja i jej implementacje mają osobną hierarchie klas, które można rozszerzać bez wzajemnego wpływu. Można mieć wiele klas implementujących dla abstrakcyjnej klasy lub wiele abstrakcji używających tej samej implementacji. Obiekty abstrakcji mogą zmieniać implementacje bez wpływu na klienta. 21 dr inż. Radosław Adamus dr inż. Radosław Adamus 21

Projektowanie obiektowe Konfiguracja na przykładzie Spring Framework Inversion of Control (Hollywood Princilple) – "don't call us, we will call you„. Framework konfiguruje aplikacje i woła komponenty użytkowe. To tak na dobrą sprawę odróżnia framework od biblioteki. Depencendy Injection – zmniejszenie zależności pomiędzy komponentami tylko do interfejsów. Problem Każda aplikacja stanowi pewien system złożony z mniejszych elementów. Na potrzeby tego artykułu będziemy je nazywać modułami, komponentami albo nawet usługami (ang. service). Pozostają one ze sobą w jakiejś relacji, tj. muszą mieć do siebie dostęp. W jaki sposób zapewnić możliwość swobodnej komunikacji tym modułom? A co w przypadku, gdy takich modułów będą dziesiątki lub nawet setki? ROZWIĄZANIE Technika projektowania obiektowego - Depencendy Injection 22 dr inż. Radosław Adamus dr inż. Radosław Adamus 22

Projektowanie obiektowe Takie podejście charakteryzuje się następującymi cechami: pozwala oddzielić interfejs od implementacji, można zdefiniować cykl życia usług (np. ich start, konfigurowanie, świadczenie faktycznej usługi i zatrzymanie), da się testować aplikację korzystając z usług zaślepek (ang. stubs), np. implementujących jedynie część funkcjonalności. 23 dr inż. Radosław Adamus dr inż. Radosław Adamus 23

Projektowanie obiektowe Composite Zdefiniowanie interfejsu uwzględniającego zarówno pojedyncze obiekty, jak i grupy obiektów. Umożliwienie odnoszenia się tak samo do pojedynczych obiektów, jak do kompozytów 24 dr inż. Radosław Adamus dr inż. Radosław Adamus 24

Projektowanie obiektowe Composite - Problem Dekompozycja złożonego obiektu na hierarchię obiektów część-całość Klient nie powinien rozróżniać między kompozycją wielu obiektów, a pojedynczym obiektem. Wiele różnych obiektów jest używanych w podobny sposób i mają prawie identyczny kod obsługi. PRZYKŁADY: system plików GUI (menu, menadżery „layout’u”) 25 dr inż. Radosław Adamus dr inż. Radosław Adamus 25

Projektowanie obiektowe Composite - Rozwiązanie Zastosowanie rekursywnej kompozycji. Agregacja 1 do wielu: „składa się” w górę hierarchii dziedziczenia. 26 dr inż. Radosław Adamus dr inż. Radosław Adamus 26

Projektowanie obiektowe Composite – diagram klas 27 dr inż. Radosław Adamus dr inż. Radosław Adamus 27

Projektowanie obiektowe Composite – diagram klas (przykład) 28 dr inż. Radosław Adamus dr inż. Radosław Adamus 28

Projektowanie obiektowe Composite – przykład The Composite composes objects into tree structures and lets clients treat individual objects and compositions uniformly. Although the example is abstract, arithmetic expressions are Composites. An arithmetic expression consists of an operand, an operator (+ - * /), and another operand. The operand can be a number, or another arithmetic expresssion. Thus, 2 + 3 and (2 + 3) + (4 * 6) are both valid expressions. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 29 dr inż. Radosław Adamus dr inż. Radosław Adamus 29

Projektowanie obiektowe Composite - Konsekwencje Udostępnienie wspólnego interfejsu do obiektów składających się na drzewiastą strukturę. Klienta nie musi interesować hierarchia komponentów. Komponenty mogą rekurencyjnie delegować przetwarzanie żądanie klienta w dół lub górę hierarchii. Konkretne komponenty mogą implementować własne unikalne operacje (ale dla uproszczenia można je przesuwać do klas ogólniejszych) Dowolna klasa wzorca Composite może być dzieckiem obiektu kompozytu. Wprowadzenie zaostrzonych reguł wymaga kodu świadomego występujących typów. Uproszczanie przez ignorancje jest podstawą wzorca Composite , więc czasem można poświęcić zasady projektowania obiektowego (np. że specjalizowane metody powinny wystąpić tylko w klasach specjalizujących). Wyjątek jest akceptowany w oparciu o doświadczenie. 30 dr inż. Radosław Adamus dr inż. Radosław Adamus 30

Projektowanie obiektowe Facade Udostępnienie prostego interfejsu ułatwiającego korzystanie z zestawu klas lub podsystemu. Dostarczenie jednego obiektu na zewnątrz w celu umożliwienia komunikacji z zestawem klas. 31 dr inż. Radosław Adamus dr inż. Radosław Adamus 31

Projektowanie obiektowe Facade - Problem Istnieje wiele zależności między klasami implementującymi abstrakcje i klasami klienta, zwiększając zauważalnie jego złożoność. Potrzeba uproszczenia klienta (np. zmniejszenie ryzyka błędów). Zwiększenie stopnia ponownego użycia systemu lub biblioteki. Zaprojektowanie klas by działały w jasno odseparowanych warstwach. 32 dr inż. Radosław Adamus dr inż. Radosław Adamus 32

Projektowanie obiektowe Facade - Rozwiązanie Osłonienie istniejącego systemu nowym interfejsem. Prosty punkt wejścia dla dużego podsystemu. Dodanie warstwy pośredniczącej ukrywającej złożoność spadkowego systemu (legacy) 33 dr inż. Radosław Adamus dr inż. Radosław Adamus 33

Projektowanie obiektowe Facade – diagram klas Podsystem jeden i trzy nie wchodzą w interakcje ze składowymi podsystemu dwa. 34 dr inż. Radosław Adamus dr inż. Radosław Adamus 34

Projektowanie obiektowe Facade – przykład The Facade defines a unified, higher level interface to a subsystem that makes it easier to use. Consumers encounter a Facade when ordering from a catalog. The consumer calls one number and speaks with a customer service representative. The customer service representative acts as a Facade, providing an interface to the order fulfillment department, the billing department, and the shipping department. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 35 dr inż. Radosław Adamus dr inż. Radosław Adamus 35

Projektowanie obiektowe Facade – przykłady Java – klasa JOptionPane pakietu javax.swing C# - klasa MessageBox pakietu System.Windows.Forms 36 dr inż. Radosław Adamus dr inż. Radosław Adamus 36

Projektowanie obiektowe Facade – wynik refaktoryzacji Aplikacja pokazująca tor lotu kuli armatniej ? PANEL WYŚWIETLAJĄCY RÓWNANIE PARAMETRYCZNE PANEL WYŚWIETLAJĄCY TOR LOTU DELEGACJA RÓWNAŃ PARAMETRYCZNYCH WYLICZENIE PARABOLI LOTU GŁÓWNE OKNO ZAWIERAJĄCE PANEL Aplikacja została zaimplementowana za pomocą trzech klas, między którymi istnieją widoczne zależności. Taka architektura posiada mały potencjał do ponownego użycia. Zależy nam na opracowaniu, dla elementów występujących w aplikacji, fasad: wzajemnie niezależnych, ogólnego zastosowania. np. panel wyświetlający tor lotu wyświetla parabolę, czyli szczególny przypadek równania parametrycznego… można te aspekty rozdzielić i uogólnić FASADA DLA KONTROLEK UI 37 dr inż. Radosław Adamus dr inż. Radosław Adamus 37

Projektowanie obiektowe Facade - Konsekwencje Wstawienie klas fasady upraszcza klasy klienta przesuwając zależności z klienta do fasady. Klient nie musi znać klas za fasadą. Zmiana implementacji (np. poprawa) klas znajdujących się za fasadą, czyli tych, które implementują abstrakcje, jest możliwa bez wpływu na kod klienta. 38 dr inż. Radosław Adamus dr inż. Radosław Adamus 38

Projektowanie obiektowe Zależności między wzorcami Umożliwienie wykorzystania elementów: już gotowych – Adapter, przed ich powstaniem – Bridge. Interfejs: nowy, całkowicie zdefiniowany – Facade. stary, ponowne użycie – Adapter . 39 dr inż. Radosław Adamus dr inż. Radosław Adamus 39