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

Projektowanie obiektowe Roadmap Memento Builder Factory Method Abstract Factory Prototype 2 dr inż. Radosław Adamus dr inż. Radosław Adamus 2

Projektowanie obiektowe Wzorce konstrukcyjne wzorce konstrukcyjne (builder, factory method, abstract factory, prototype oraz memento) pozwalają klientom tworzyć nowe obiekty inaczej niż tylko przez wywołanie konstruktorów klas. Creational patterns provide guidance on how to create objects when their creation requires making decisions. These decisions will typically involve dynamically deciding which class to instantiate or which objects an object will delegate responsibility to. The value of creational patterns is to tell us how to structure and encapsulate these decisions. 3 dr inż. Radosław Adamus dr inż. Radosław Adamus 3

Projektowanie obiektowe Memento GoF - wzorzec behawioralny wzorzec konstrukcyjny Zrekonstruowanie obiektu na podstawie jego starszej wersji, zawierającej wyłącznie stan wewnętrzny. 4 dr inż. Radosław Adamus dr inż. Radosław Adamus 4

Projektowanie obiektowe Memento – problem Gdy potrzebujemy możliwość przywracania poprzedniego (lub dawnego) stanu obiektu. 5 dr inż. Radosław Adamus dr inż. Radosław Adamus 5

Projektowanie obiektowe Memento – rozwiązanie Stosujemy metody undo i rollback. „magiczne” ciasteczko hermetyzuje zapamiętanie stanu z określonego punktu („check-point”). 6 dr inż. Radosław Adamus dr inż. Radosław Adamus 6

Projektowanie obiektowe Memento – diagram klas The Memento design pattern defines three distinct roles: Originator - the object that knows how to save itself. Caretaker - the object that knows why and when the Originator needs to save and restore itself. Memento - the lock box that is written and read by the Originator, and shepherded by the Caretaker. 7 dr inż. Radosław Adamus dr inż. Radosław Adamus 7

Projektowanie obiektowe Memento – przykład The Memento captures and externalizes an object's internal state so that the object can later be restored to that state. This pattern is common among do-it-yourself mechanics repairing drum brakes on their cars. The drums are removed from both sides, exposing both the right and left brakes. Only one side is disassembled and the other serves as a Memento of how the brake parts fit together. Only after the job has been completed on one side is the other side disassembled. When the second side is disassembled, the first side acts as the Memento. [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 Memento – konsekwencje Dane zapamiętywanej obiektu (originatora), do których powinien mieć tylko on dostęp pozostają prywatne. Upraszcza klasę originatora delegując zapisywanie i odtwarzanie do klasy memento. Przechowywanie stanów wymaga dodatkowej pamięci. Za oszczędną strategie wykorzystania memento odpowiedzialny jest klient (caretaker). 2. Originator nie przechowuje poprzednich stanów. 9 dr inż. Radosław Adamus dr inż. Radosław Adamus 9

Projektowanie obiektowe Zależności między wzorcami memento i command Mają działanie przekazywanych i wywoływanych w późniejszym czasie tokenów, które reprezentują: żądanie – command, zapamiętany wewnętrzny stan obiektu – memento. Command może wykorzystywać memento by zachować stan potrzebny do operacji undo. 10 dr inż. Radosław Adamus dr inż. Radosław Adamus 10

Projektowanie obiektowe Wzorce kreacyjne wzorce kreacyjne ułatwiają proces tworzenia obiektów, gdy wymaga on podejmowania decyzji. Creational patterns provide guidance on how to create objects when their creation requires making decisions. These decisions will typically involve dynamically deciding which class to instantiate or which objects an object will delegate responsibility to. The value of creational patterns is to tell us how to structure and encapsulate these decisions. 11 dr inż. Radosław Adamus dr inż. Radosław Adamus 11

Projektowanie obiektowe Builder Stopniowe zbieranie informacji o obiekcie przed przystąpieniem do jego konstrukcji. Wzorzec konstrukcyjny Wzorzec kreacyjny The Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. This pattern is used by fast food restaurants to construct children's meals. Children's meals typically consist of a main item, a side item, a drink, and a toy (e.g., a hamburger, fries, Coke, and toy car). Note that there can be variation in the content of the children's meal, but the construction process is the same. Whether a customer orders a hamburger, cheeseburger, or chicken, the process is the same. The employee at the counter directs the crew to assemble a main item, side item, and toy. These items are then placed in a bag. The drink is placed in a cup and remains outside of the bag. This same process is used at competing restaurants. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 12 dr inż. Radosław Adamus dr inż. Radosław Adamus 12

Projektowanie obiektowe Builder – problem Program ma umożliwiać wytworzenie wiele typów zewnętrznych reprezentacji tych samych danych. Zawartość znajduje się na drugorzędnej pamięci (secondary storage), a reprezentacja ma być zbudowana w głównej pamięci (primary storage) Klasy odpowiedzialne za dostarczanie zawartości powinny być niezależne od dowolnych zewnętrznych reprezentacji danych i klas, które je tworzą. Klasy odpowiedzialne za budowę zewnętrznych reprezentacji danych mają być niezależne od klas dostarczających zawartość. 13 dr inż. Radosław Adamus dr inż. Radosław Adamus 13

Projektowanie obiektowe Builder – rozwiązanie Za pomocą jednego „wejścia” umożliwiamy uzyskanie wielu wyników („wyjść”). Struktura: Osłona/Delegacja: osłona kieruje algorytm tworzenia/kompozycji, każda delegacja hermetyzuje docelowe wyjście. 14 dr inż. Radosław Adamus dr inż. Radosław Adamus 14

Projektowanie obiektowe Builder – diagram klas 15 dr inż. Radosław Adamus dr inż. Radosław Adamus 15

Projektowanie obiektowe Builder – konsekwencje Określanie zawartości i konstrukcja konkretnej reprezentacji danych są niezależne. Zewnętrzna reprezentacja produktu może zmieniać się bez wpływu na obiekty dostarczające zawartość. Obiekty Builder-a mogą pracować z różnymi obiektami dostarczającymi zawartość bez potrzeby żadnych zmian. 16 dr inż. Radosław Adamus dr inż. Radosław Adamus 16

Projektowanie obiektowe Factory Method Zwolnienie klienta z obowiązku „znajomości” konkretnej klasy, której instancja ma być stworzona. Wzorzec konstrukcyjny Wzorzec kreacyjny 17 dr inż. Radosław Adamus dr inż. Radosław Adamus 17

Projektowanie obiektowe Factory Method – problem Framework potrzebuje standaryzować model architektury dla wielu aplikacji, ale pozwolić indywidualnym aplikacjom definiować obiekty własnej domeny i dostarczać ich instancje. Klasy muszą inicjować kreacje obiektów nie mając zależności z klasą utworzonego obiektu. Zbiór tworzonych klas może się dynamicznie rozrastać, gdy nowe klasy zostaną udostępnione. 18 dr inż. Radosław Adamus dr inż. Radosław Adamus 18

Projektowanie obiektowe Factory Method – rozwiązanie Pośrednie tworzenie przez dziedziczenie. Stosujemy konstruktor wirtualny. Unikamy konstrukcji „new” (uznając ją za szkodliwą) 19 dr inż. Radosław Adamus dr inż. Radosław Adamus 19

Projektowanie obiektowe Factory Method – diagram klas Wzorzec konstrukcyjny Wzorzec kreacyjny PROBLEM: ROZWIĄZANIE: pośrednie tworzenie przez dziedziczenie konstruktor wirtualny unikanie konstrukcji „new” jako szkodliwej KONSEKWENCJE: 20 dr inż. Radosław Adamus dr inż. Radosław Adamus 20

Projektowanie obiektowe Factory Method – przykład: iteracja w javie Iterators static void filter(Collection<?> c) { for (Iterator<?> it = c.iterator(); it.hasNext(); ) if (!cond(it.next())) it.remove(); } for-each Construct for (Object o : collection) System.out.println(o); 21 dr inż. Radosław Adamus dr inż. Radosław Adamus 21

Projektowanie obiektowe Factory Method – diagram klasy fabryka factoryMethod jest publiczna. Klient może korzystać bezpośrednio z operacji fabrykującej. 22 dr inż. Radosław Adamus dr inż. Radosław Adamus 22

Projektowanie obiektowe Factory Method – przykład The Factory Method defines an interface for creating objects, but lets subclasses decide which classes to instantiate. Injection molding presses demonstrate this pattern. Manufacturers of plastic toys process plastic molding powder, and inject the plastic into molds of the desired shapes. The class of toy (car, action figure, etc.) is determined by the mold. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] 23 dr inż. Radosław Adamus dr inż. Radosław Adamus 23

Projektowanie obiektowe Factory Method – konsekwencje Klasa prosząca o kreacje obiektu jest niezależna od klas wyprodukowanych obiektów. Zbiór klas produktów, które mogą być utworzone, może być dynamicznie zmieniany. Dodatkowa warstwa pośrednicząca pomiędzy inicjacją kreacji obiektów a określeniem, której klasy obiekt zostanie utworzony utrudnia zrozumienie kodu programistom. 24 dr inż. Radosław Adamus dr inż. Radosław Adamus 24

Projektowanie obiektowe Abstract Factory Stworzenie rodziny obiektów posiadających określoną cechę wspólną. Wzorzec konstrukcyjny Wzorzec kreacyjny 25 dr inż. Radosław Adamus dr inż. Radosław Adamus 25

Projektowanie obiektowe Abstract Factory – przykład The purpose of the Abstract Factory is to provide an interface for creating families of related objects, without specifying concrete classes. This pattern is found in the sheet metal stamping equipment used in the manufacture of Japanese automobiles. The stamping equipment is an Abstract Factory which creates auto body parts. The same machinery is used to stamp right hand doors, left hand doors, right front fenders, left front fenders, hoods, etc. for different models of cars. Through the use of rollers to change the stamping dies, the concrete classes produced by the machinery can be changed within three minutes. [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 Abstract Factory – problem Tworzymy aplikacje, która ma być przenośna. Potrzeba hermetyzacji wieloplatformowości, np.: systemu okienkowego, operacyjnego, bazy danych. Istniejące wyrażenia #ifdef case często nie mogą być w pełni przewidziane i obsłużone. Nasz system powinien być niezależny od wielu produktów, z którymi współpracuje. DODAĆ PONIŻSZE PUNKTY NA OSOBNYM SLAJDZIE: It should be possible for a system to be configured to work with one or multiple members of a family of products. J Instances of classes intended to interface with a product should be used together and only with the product. This constraint must be enforced. The rest of a system should work with a product without being aware of the specific classes used to interface with the product. A system should be extensible so that it can work with additional products by adding additional sets of classes and changing at most only a few lines of code. L The interface that a class implements is not sufficient to distinguish it from other classes that may be instantiated to create an object. 27 dr inż. Radosław Adamus dr inż. Radosław Adamus 27

Projektowanie obiektowe Abstract Factory – rozwiązanie Dodajemy warstwę pośredniczącą, która dostarcza usługę tworzenia. Zapewniamy wsparcie dla „rodziny” produktów. Zapewniamy wsparcie wielu strategii tworzenia: wybór klasy pochodnej, ponowne użycie obiektów w cache’u, rozproszone tworzenie, wybór platformy lub przestrzeni adresowej. Unikamy konstrukcji „new” (uznając ją za szkodliwą) 28 dr inż. Radosław Adamus dr inż. Radosław Adamus 28

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

Projektowanie obiektowe Abstract Factory – diagram klas Przykładowo mogą być generowane różne elementy GUI w zależności od fabryki reprezentującej określony typ schematu stylu look&feel 30 dr inż. Radosław Adamus dr inż. Radosław Adamus 30

Projektowanie obiektowe Abstract Factory – konsekwencje Klasy klienta są niezależne od konkretnych klas produktów (widgetów), które używają. Dodawanie (w odróżnieniu od pisania) klasy fabryki, aby klient mógł pracować z dodatkowymi produktami jest proste. Wymuszenie klasom klienta przechodzenia przez interfejs fabryki, aby utworzyć konkretne obiekty produktu, zapewnia, że klient używa spójny zestaw obiektów do pracy z produktem. Napisanie nowego zestawu klas do wzajemnego oddziaływania z produktem jest pracochłonne. 2. The class of a concrete factory object usually needs to be referenced in only one place. It is also easy to change the concrete factory used to work with a particular product. J By forcing client classes to go through a FactoryIF interface to create concrete widget objects, the Abstract Factory pattern ensures that client objects use a consistent set of objects to work with a product. L 4. It can also take a lot of work to extend the set of features that the existing set of classes is able to exercise in the products that they work with.   Adding support for a new product involves writing a complete set of concrete widget classes to support that product. You must write a concrete widget class for each WidgetIF interface. If there are many WidgetIF interfaces, then it will be a lot of work to support an additional product Adding access to an additional feature of the products interfaced to can also take a lot of work if there are many supported products. It involves writing a new WidgetIF interface corresponding to the new feature and a new concrete widget class corresponding to each product. 31 dr inż. Radosław Adamus dr inż. Radosław Adamus 31

Projektowanie obiektowe Abstract Factory i Bridge Obiekty klienta mogą potrzebować zorganizowanie klas (widgetów) w hierarchie. Podstawowa wersja wzorca Abstract Factory uniemożliwia to ponieważ konkretna hierarchia klas produktów (widgetów) jest niezależna od obiektów klienta. Stosując wzorzec Bridge należy utworzyć po stronie klienta hierarchie klas widgetów niezależną od produktów. Każdą taką klasę należy wyposażyć w delegacje logiki zależnej od produktu do klasy produktu (widgeta). Java’s java.awt package contains a number of classes that are implemented using this variation. Classes like Button and TextField contain logic that is independent of the windowing system being used. These classes provide a native look and feel by delegating windowing system operations to concrete widget classes that implement interfaces defined in the java.awt.peer package. 32 dr inż. Radosław Adamus dr inż. Radosław Adamus 32

Projektowanie obiektowe Prototype Stworzenie obiektu na podstawie obiektu przykładowego. Wzorzec konstrukcyjny Wzorzec kreacyjny The Prototype pattern specifies the kind of objects to create using a prototypical instance. Prototypes of new products are often built prior to full production, but in this example, the prototype is passive and does not participate in copying itself. The mitotic division of a cell - resulting in two identical cells - is an example of a prototype that plays an active role in copying itself and thus, demonstrates the Prototype pattern. When a cell splits, two cells of identical genotvpe result. In other words, the cell clones itself. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] Prototype is unique among the other creational patterns in that it doesn't require a class – only an object. Object-oriented languages like Self and Omega that do away with classes completely rely on prototypes for creating new objects. 33 dr inż. Radosław Adamus dr inż. Radosław Adamus 33

Projektowanie obiektowe Prototype – problem System ma tworzyć obiekty nie znając dokładnie ich klasy, sposobu tworzenia oraz jakie dane reprezentują. Klasy, których instancje mają być utworzone przez system, nie są znane aż do czasu wykonania. Następujące sposoby tworzenia różnorodnych obiektów są niepożądane: bezpośrednie tworzenie (pełna zależność), factory method (ciężkie w utrzymaniu). abstract factory (wiele dodatkowych klas fabryk) Application "hard wires" the class of object to create in each "new" expression. J 3. The following approaches to allowing the creation of a large variety of objects are undesirable: a.) The classes that initiate the creation of objects directly create the objects. This makes them aware of and dependent on a large number of other classes. b.) The classes that initiate the creation of objects create the objects indirectly through a factory method class. A factory method that is able to create a large variety of objects may be very large and difficult to maintain. c.) The classes that initiate the creation of objects create the objects indirectly through an abstract factory class. In order for an abstract factory to be able to create a large variety of objects, it must have a large variety of concrete factory classes in a hierarchy that parallels the classes to be instantiated. ?The different objects that a system must create may be instances of the same class that contain different state information or data content. 34 dr inż. Radosław Adamus dr inż. Radosław Adamus 34

Projektowanie obiektowe Prototype – rozwiązanie Tworzymy obiekt niebezpośrednio – przez delegacje. Stosujemy tzw. „klonowanie” Unikamy konstrukcji „new” (uznając ją za szkodliwą) 35 dr inż. Radosław Adamus dr inż. Radosław Adamus 35

Projektowanie obiektowe Prototype – diagram klas 36 dr inż. Radosław Adamus dr inż. Radosław Adamus 36

Prototype – diagram klas z z klasą PrototypeBuilder

Projektowanie obiektowe Prototype – konsekwencje Program może dynamicznie dodawać i usuwać prototypy w czasie wykonania. Obiekt tworzący prototypy PrototypeBuilder może dostarczać określony zestaw prototypów, dodatkową elastyczność pozwalając nowym prototypom być tworzonym. (rozszerzenie zestawu obiektów prototypów lub zmiany wartości atrybutów prototypów). Obiekt klienta może tworzyć nowe rodzaje prototypów. Klient jest niezależny od klas prototypów. 1. Prototype jako jedyny wzorzec kreacyjny może dynamicznie dodawać i usuwać obiekty w czasie wykonania 4. Also, the client class does not need to know the details of how to build the prototypical objects. 38 dr inż. Radosław Adamus dr inż. Radosław Adamus 38

Projektowanie obiektowe Prototype – konsekwencje, c.d. Obiekt tworzący PrototypeBuilder hermetyzuje szczegóły konstrukcji obiektów prototypów. Klient ma określony spójny zestaw metod, które prototyp dostarcza. Prototypy nie muszą być organizowane w żadną hierarchie. Konieczny jest dodatkowy czas na napisanie klas tworzących prototypy PrototypeBuilder. Programy wykorzystujące prototype polegają na dynamicznym wiązaniu (lub podobnych mechanizmach). Utrudnia to instalacje programu. 2. By insisting that prototypical objects implement an interface such as PrototypeIF, the Prototype pattern ensures that the prototypical objects provide a consistent set of methods for the client object to use. 5. Installation of programs that rely on dynamic linkage or similar mechanisms can be more complicated. They may require information about their environment that may otherwise not be needed. 39 dr inż. Radosław Adamus dr inż. Radosław Adamus 39

Projektowanie obiektowe Zależności między wzorcami Builder dostarcza lepszą kontrolę nad konstrukcją niż inne wzorce (np. factory method) dając obiekt zarządzający krok po kroku kreacją obiektu. Pozostałe wzorce tworzą obiekt w jednym kroku. Builder często tworzy composite. Builder odnosi się do tworzenia jak strategia do algorytmu 40 dr inż. Radosław Adamus dr inż. Radosław Adamus 40

Projektowanie obiektowe Zależności między wzorcami Często projekt ewoluuje z factory method do innego bardziej elastycznego wzorca konstrukcyjnego. Klasy abstract factory są często implementowane jako factory methods lub prototype. Factory methods są często wywoływane jako template methods. ?DODAĆ? Abstract Factory, Builder, and Prototype define a factory object that's responsible for knowing and creating the class of product objects, and make it a parameter of the system. Abstract Factory has the factory object producing objects of several classes. Builder has the factory object building a complex product incrementally using a correspondingly complex protocol. Prototype has the factory object (aka prototype) building a product by copying a prototype object. [GOF, p135] 41 dr inż. Radosław Adamus dr inż. Radosław Adamus 41

Projektowanie obiektowe Zależności między wzorcami Tworzenie przez: dziedziczenie – factory method, delegację – prototype. Abstract factory może być użyte jako alternatywa dla facade by ukryć klasy zależne od platformy 42 dr inż. Radosław Adamus dr inż. Radosław Adamus 42