Projektowanie obiektowe Projektowanie obiektowe Wzorce projektowe Gang of Four Wzorce odpowiedzialności 1 dr inż. Radosław Adamus dr inż. Radosław Adamus 1

Projektowanie obiektowe Roadmap Singleton Observer Mediator Proxy Flyweight Chain of responsibility 2 dr inż. Radosław Adamus dr inż. Radosław Adamus 2

Projektowanie obiektowe Wzorce odpowiedzialności Udostępniają techniki centralizacji, delegowania i ograniczania odpowiedzialności zwykłych obiektów 3 dr inż. Radosław Adamus dr inż. Radosław Adamus 3

Projektowanie obiektowe Singleton GoF – wzorzec kreacyjny Umożliwienie skupienia całej odpowiedzialności w jednej instancji klasy 4 dr inż. Radosław Adamus dr inż. Radosław Adamus 4

Projektowanie obiektowe 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. 5 dr inż. Radosław Adamus dr inż. Radosław Adamus 5

Projektowanie obiektowe Singleton – rozwiązanie Wymuszamy określoną liczbę instancji klasy. Leniwa inicjalizacja. Dostęp globalny. 6 dr inż. Radosław Adamus dr inż. Radosław Adamus 6

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

Projektowanie obiektowe Singleton – przykład The Singleton pattern ensures that a class has only one instance and provides a global point of access to that instance. It is named after the singleton set, which is defined to be a set containing one element. The office of the President of the United States is a Singleton. The United States Constitution specifies the means by which a president is elected, limits the term of office, and defines the order of succession. As a result, there can be at most one active president at any given time. Regardless of the personal identity of the active president, the title, "The President of the United States" is a global point of access that identifies the person in the office. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 8 dr inż. Radosław Adamus dr inż. Radosław Adamus 8

Projektowanie obiektowe 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(). 9 dr inż. Radosław Adamus dr inż. Radosław Adamus 9

Projektowanie obiektowe 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. Abstract Factory, Builder, and Prototype can use Singleton in their implementation. 10 dr inż. Radosław Adamus dr inż. Radosław Adamus 10

Projektowanie obiektowe Observer GoF – wzorzec behawioralny Umożliwia oddzielić obiekt od znajomości obiektów od niego zależnych 11 dr inż. Radosław Adamus dr inż. Radosław Adamus 11

Projektowanie obiektowe 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. 12 dr inż. Radosław Adamus dr inż. Radosław Adamus 12

Projektowanie obiektowe Observer – rozwiązanie Struktura: Osłona/Delegacja. osłona hermetyzuje (enkapsuluje) rdzeń logiki biznesowej każda delegacja dostarcza konfigurowalną przez użytkownika, opcjonalną funkcjonalność 13 dr inż. Radosław Adamus dr inż. Radosław Adamus 13

Projektowanie obiektowe Observer – diagram klas PRZYKŁAD: Aplikacja przedstawiająca dane za pomocą wykresów, kołowych, słupkowych, tabel. Jaką rolę pełnią klasy i metody w Swing: np. JButton {addActionListener(ActionListener)}, ActionListener {actionPerformed(ActionEvent e)} 14 dr inż. Radosław Adamus dr inż. Radosław Adamus 14

Projektowanie obiektowe Observer – przykład The Observer defines a one-to-many relationship so that when one object changes state, the others are notified and updated automatically. Some auctions demonstrate this pattern. Each bidder possesses a numbered paddle that is used to indicate a bid. The auctioneer starts the bidding, and "observes" when a paddle is raised to accept the bid. The acceptance of the bid changes the bid price which is broadcast to all of the bidders in the form of a new bid. [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 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ń. 2. można spróbować zrealizować dostarczanie powiadomień asynchronicznie. If a notification can be delivered asynchronously of other threads, as is the case in the example under the Context heading, there are some additional consequences to consider. You need to ensure that the asynchronous delivery of notifications is done in a way that ensures the consistency of the objects that receive the notifications. It may also be important that notification does not block waiting for another thread for any length of time. 16 dr inż. Radosław Adamus dr inż. Radosław Adamus 16

Projektowanie obiektowe 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. The Principle of Containing Variation W jakich wzorcach występuje: Bridge, Strategy, Abstract Factory, Facade, Observer, Decorator, Template Method 17 dr inż. Radosław Adamus dr inż. Radosław Adamus 17

Projektowanie obiektowe Mediator GoF – wzorzec behawioralny Pozwala skupić odpowiedzialność w jednej klasie, nadzorującej interakcję innych obiektów 18 dr inż. Radosław Adamus dr inż. Radosław Adamus 18

Projektowanie obiektowe 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. 19 dr inż. Radosław Adamus dr inż. Radosław Adamus 19

Projektowanie obiektowe 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) 20 dr inż. Radosław Adamus dr inż. Radosław Adamus 20

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

Projektowanie obiektowe Mediator – przykład The Mediator defines an object that controls how a set of objects interact. Loose coupling between colleague objects is achieved by having colleagues communicate with the Mediator, rather than with each other. The control tower at a controlled airport demonstrates this pattern very well. The pilots of the planes approaching or departing the terminal area communicate with the tower rather than explicitly communicating with one another. The constraints on who can take off or land are enforced by the tower. It is important to note that the tower does not control the whole flight. It exists only to enforce constraints in the terminal area. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] Airlines have stream-lined operations by limiting the number of direct point-to-point flights, and relying on “hub” cities more. Each hub serves as a "concentrator". Origins and destinations are decoupled by introducing the intermediary of a hub. 22 dr inż. Radosław Adamus dr inż. Radosław Adamus 22

Projektowanie obiektowe 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. 23 dr inż. Radosław Adamus dr inż. Radosław Adamus 23

Projektowanie obiektowe 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”. 24 dr inż. Radosław Adamus dr inż. Radosław Adamus 24

Projektowanie obiektowe Proxy GoF – wzorzec strukturalny Pozwala obiektowi działać w imieniu innego obiektu 25 dr inż. Radosław Adamus dr inż. Radosław Adamus 25

Projektowanie obiektowe 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) 26 dr inż. Radosław Adamus dr inż. Radosław Adamus 26

Projektowanie obiektowe 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. 27 dr inż. Radosław Adamus dr inż. Radosław Adamus 27

Projektowanie obiektowe Proxy – diagram klas 28 dr inż. Radosław Adamus dr inż. Radosław Adamus 28

Projektowanie obiektowe Proxy – przykład The Proxy provides a surrogate or place holder to provide access to an object. A check or bank draft is a proxy for funds in an account. A check can be used in place of cash for making purchases and ultimately controls access to cash in the issuer's account. [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 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) 30 dr inż. Radosław Adamus dr inż. Radosław Adamus 30

Projektowanie obiektowe Odpowiedzialność Diagram klas z błędami 31 dr inż. Radosław Adamus dr inż. Radosław Adamus 31

Projektowanie obiektowe 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 32 dr inż. Radosław Adamus dr inż. Radosław Adamus 32

Projektowanie obiektowe 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ń. There is a potentially variable number of "handler" or "processing element" or "node" objects, and a stream of requests that must be handled. Need to efficiently process the requests without hard-wiring handler relationships and precedence, or request-to-handler mappings 33 dr inż. Radosław Adamus dr inż. Radosław Adamus 33

Projektowanie obiektowe Chain of Responsibiliy – rozwiązanie Stosujemy rekursywną kompozycje. Jeden-do-jednego agregacja („ma”) na czubku hierarchii dziedziczenia Tworzymy listę dołączaną zorientowaną-obiektowo 34 dr inż. Radosław Adamus dr inż. Radosław Adamus 34

Projektowanie obiektowe Chain of Responsibiliy – diagram klas 35 dr inż. Radosław Adamus dr inż. Radosław Adamus 35

Projektowanie obiektowe Chain of Responsibiliy – przykład Java 36 dr inż. Radosław Adamus dr inż. Radosław Adamus 36

Projektowanie obiektowe Chain of Responsibiliy – przykład The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver by giving more than one object a chance to handle the request. Mechanical coin sorting banks use the Chain of Responsibility. Rather than having a separate slot for each coin denomination coupled with a receptacle for the denomination, a single slot is used. When the coin is dropped, the coin is routed to the appropriate receptacle by the mechanical mechanisms within the bank. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 37 dr inż. Radosław Adamus dr inż. Radosław Adamus 37

Projektowanie obiektowe 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. 38 dr inż. Radosław Adamus dr inż. Radosław Adamus 38

Projektowanie obiektowe 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. Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Chain of Responsibility passes a sender request along a chain of potential receivers. Command normally specifies a sender-receiver connection with a subclass. Mediator has senders and receivers reference each other indirectly. Observer defines a very decoupled interface that allows for multiple receivers to be configured at run-time. Mediator can leverage Observer for dynamically registering colleagues and communicating with them 39 dr inż. Radosław Adamus dr inż. Radosław Adamus 39

Projektowanie obiektowe Flyweight (waga piórkowa) GoF – wzorzec strukturalny Ma na celu skupienie odpowiedzialności w drobnych, współużytkowanych obiektach 40 dr inż. Radosław Adamus dr inż. Radosław Adamus 40

Projektowanie obiektowe 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. \ 41 dr inż. Radosław Adamus dr inż. Radosław Adamus 41

Projektowanie obiektowe 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 ?jak stworzyć tuziny małych obiektów, które „incur minimal overhead” 42 dr inż. Radosław Adamus dr inż. Radosław Adamus 42

Projektowanie obiektowe Flyweight – diagram klas 43 dr inż. Radosław Adamus dr inż. Radosław Adamus 43

Projektowanie obiektowe 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 String class is designed with Flyweight design pattern. It has similar structure as above example. When you create a string constant, such constant is stored in a pool. When the second string is created, it will be checked to see if it has been created. If it is true, the second string instance will be picked up from the string pool instead of creating a new one. This is why the following code makes sense, but bothers many people. 44 dr inż. Radosław Adamus dr inż. Radosław Adamus 44

Projektowanie obiektowe Flyweight – przykład The Flyweight uses sharing to support large numbers of objects efficiently. The public switched telephone network is an example of a Flyweight. There are several resources such as dial tone generators, ringing generators, and digit receivers that must be shared between all subscribers. A subscriber is unaware of how many resources are in the pool when he or she lifts the handset to make a call. All that matters to subscribers is that a dial tone is provided, digits are received, and the call is completed. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 45 dr inż. Radosław Adamus dr inż. Radosław Adamus 45

Projektowanie obiektowe 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. 46 dr inż. Radosław Adamus dr inż. Radosław Adamus 46

Projektowanie obiektowe 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. 4. np. jeżeli instancji obiektów reprezentujących stan jest dużo i mają wspólne własności można stosować flyweight. 47 dr inż. Radosław Adamus dr inż. Radosław Adamus 47