WZORCE PROJEKTOWE Software engineering has accepted as its charter How to program if you cannot. E. Djikstra 1
* Wykład 1 Wzorzec projektowy opis komunikujących się obiektów i klas dostosowanych do rozwiązania ogólnego problemu projektowego w szczególnym kontektście. Nazwa skrót opisujący problem projektowy, rozwiązanie oraz konsekwencje tego rozwiązania Problem opis kontekstu (kiedy zastosować wzorzec) Rozwiązanie opis elementów składowych, przeznaczenie, relacje i współpraca między nimi Konsekwencje koszty i zyski wynikające z zastosowania wzorca WP!= struct-prog OOP Kompozycja zamiast dziedziczenia Hermetyzacja Od ogółu do szczegółu Wzorce architektoniczne Uniwersalne, sprawdzone w praktyce rozwiązanie często pojawiających się problemów projektowych. Określają ogólną strukturę systemu informatycznego elementy składowe, zasady komunikacji między nimi Dotyczą problemów z komunikacją, tworzeniem lub organizacją systemów inf. Elastyczne oprogramowanie łatwo modyfikowalne pod kątem najbardziej prawdopodobnych kierunków rozwoju; minimalizacja: niezbędnych zmian w kodzie ilości testów łatwa pielęgnacja kodu 2
Kiedy wzorce? duża rotacja pracowników oprogramowanie duże duży stopień skomplikowania: algorytmów, specjalistyczny zmienność wymagań przewidywanie zmian w oprogramowaniu (sprzedaż innym klientom) minimalizacja czasu serwisowania oprogramowania Kiedy nie wzorce? małe grupy używanie na siłe? duża komplikacja kodu NIEPOTRZEBNA! koszty szkoleń nieefektywność zastosowań == mała elastyczność Klasyfikacja wzorców Konstrukcyjne (creational) proces tworzenia obiektów Strukturalne (structural) składanie klas lub obiektów Czynnościowe (behavioral) sposób współdziałania oraz podział zadań klas, obiektów Zasięg wzorców Klasowy statyczne relacje między klasami i ich podklasami dziedziczenie Obiektowy dynamiczne relacje między obiektami, które mogą się zmieniać w czasie wykonania programu Tabela Konstrukcyjne Strukturalne Czynnościowe Klasowe FactoryMethod Adapter(klasowy) Interpreter Template Method Obiektowe Abstract Factory Adapter (obiektowy) Chain of Responsibility Builder Bridge Command Prototype Composite Iterator Singleton Decorator Mediator Facade Memento Flyweight Proxy Observer State Strategy Visitor 3
Wykład 2 (Fasada, Adapter, Iterator) Fasada (Facade) : wzorzec obiektowy, strukturalny jednolity interfejs dla zbioru interfejsów z podsystemu. określa wyższy poziom dostępu ułatwiający korzystanie z podsystemu Uzasadnienie Problem Potrzeba wykorzystania części możliwości systemu Rozwiązanie Fasada udostępnia wymaganą część podsystemu Warunki stosowania chcemy prosty interfejs do czegoś złożonego oddzielamy złożony podsystem od klientów i innych podsystemów chcemy podzielić system na warstwy urywamy podsystem przed użytkownikami systemu stworzenie fasady jest tańsze niż zaznajomienie programistów z pełnym podsystemem Struktura Elementy Fasada zna klasy odpowiedzialne za obsługę żądań deleguje żądania do odpowiednich obiektów 4
Klasy podsystemu nie wiedzą o istnieniu fasady obsługują wszystko jak leci Współdziałanie klienci korzystają z Fasady klienci nie muszą mieć dostępu do obiektów podsystemu Konsekwencje oddzielenie klientów od komponentów podsystemu możliwość modyfikowania komponentów podsystemu bez wpływu na klientów Zachowuje możliwość odwołania się do klas podsystemu, jeśli jest to potrzebne Powiązane wzorce Fabryka abstrakcyjna : można stosować z fasadą dla tworzenia obiektów podsystemu niezależnie od podsystemów. Singleton : Fasada jest zwykle Singletonem Adapter : wzorzec klasowy/obiektowy, strukturalny przekształca interfejs klasy na oczekiwany przez klienta wspołpraca klas, które nie mogą działać ze względu na złe interfejsy Uzasadnienie Problem wszystko działa jak należy (dane, zachowanie) w obiekcie, ale ma nieodpowiedni interfejs chcemy dołączyć obiekt do hierarchii dziedziczenia innej klasy abstrakcyjnej, którą włąsnie definiujemy Rozwiązanie Adapter : obudowuje obiekt odpowiednim interfejsem Warunki stosowania istniejąca klasa bez dobrego interfejsu (dla nas) chcemy klasę wielokrotnego użytku, która współpracuje z niepowiązanymi klasami lub nieznanymi klasami 5
(adapter obiektowy) chcemy użyć istniejących podklas, ale dostosowanie interfejsów przez podklasy dla każdej z nich jest niewygodne. Adapter obiektowy może dostosować interfejs swojej klasy nadrzędnej Struktura (klasowy) Struktura (obiektowy) Elementy Cel (Target): specyficzny interfejs klienta Klient (Client): współpracuje z interfejsem klasy Target Adaptowany (Adaptee): definiuje istniejący interfejs Adapter (Adapter): adaptuje interfejs Adaptee do interfejsu Target Współdziałanie Klienci komunikują się z Adapterem, który wywołuje żądania interfejsu Adaptee 6
Konsekwencje (klasowy) klasa Adaptee dostosowana do klasy Target możliwość przesłonięcia w Adapter wybranych zachowań Adaptee nie wymaga wskaźnika w celu dostępu do klasy adaptowanej Konsekwencje (obiektowy) współdzielenie jednej klasy Adapter z wieloma obiektami Adaptee (jej podklasami) == dodawanie funkcji w Adapter do wszystkich klas Adaptee jednocześnie utrudnia zastąpienie zachowań w Adaptee == trzeba utworzyć klasę pochodną dla Adaptee, żeby to osiągnąć Powiązane wzorce Most : struktura podobna do Adaptera obiektowego, ale ma inną funkcję, tj. rozdziela abstrakcję od implementacji, a adapter zmienia interfejs Dekorator : wzbogaca zachowanie innych obiektów bez zmiany interfejsów, umożliwia składanie rekurencyjne nieosiągalne dla adapterów Proxy : podobna struktura, ale definiuje substutu innego obiektu bez modyfikacji interfejsu FASADA VS ADAPTER Tabela Fasada Adapter Istnieją wcześniej zdefiniowane klasy? Tak Tak Istnieje interfejs, który trzeba zastosować? Nie Tak Obiekty powinny być polimorficzne? Nie Prawdopodobnie Docelowy interfejs ma być prostszy? Tak Nie Iterator : wzorzec obiektowy, czynnościowy sekwencyjny dostęp do elementów kolekcji bez ujawniania wewnętrznej implementacji Uzasadnienie przeniesienie odpowiedzialności za dostęp do elementów i przechodzenie po nich z obiektu kolekcji do obiektu iteratora 7
Warunki stosowania dostęp do składników obiektu zagregowanego bez ujawniani wewnętrznej reprezentacji realizacja wielu sposobów przechodzenia przez kolekcję jednolity interfejs dla przeglądania różnych kolekcji (iteracja polimorficzna) Struktura Elementy Iterator : definiuje interfejs umożliwiający dostęp do elementów i ich przeglądanie ConcreteIterator : implementuje interfejs, przechowuje aktualną pozycję przy przechodzniu przez kolekcję Aggregate (kolekcja) : definiuje interfejs do tworzenia iteratorów ConcreteAgregate : implementuje interfejs tworzenia iteratorów Współdziałanie ConcreteIterator zna aktualny obiekt z kolekcji i może wyznaczyć następnik Konsekwencje pozwala na zmianę sposobu przechodzenia po kolekcji upraszcza interfejs kolekcji (nie musi mieć metod do przeglądania) umożliwa wiele jednoczesnych procesów przeglądania kolekcji 8
Implementacja sterowanie iteracją Iterator zewnętrzny : sterowany przez klienta (bardziej elastyczny) Iterator wewnętrzny : klient przekazuje operacje do wykonania, iterator steruje przeglądaniem kolekcji uruchamiając tę operację na elementach kolekcji wybór obiektu z algorytem przeglądania Iterator : łatwo stosować/zmieniać algorytmy przeglądania Kolekcja : iterator przechowuje stan iteracji KURSOR, klient wywołuje operację next na kolekcji z kursorem jako argument Użyteczne gdy potrzeba dostępu do zmiennych prywatnych Powiązane wzorce Composite : iteratory często stosuje się do struktur rekurencyjnych FactoryMethod : iteratory polimorficzne korzystają z metod wytwórczych do generowania obiektów klas pochodnych Iterator Memento (pamiątka) : często stosowny z iteratorem. Iterator może przechowywać Memento i korzystać z niego do zapisu stanu iteracji Wykład 3 (Strategy, TemplateMethod) Strategia (Strategy) : wzorzec obiekowy, czynnościowy zdefiniowanie rodziny algorytmów zastosowanie hermetyzacji i wykorzystywanie ich zamiennie niezależnie od wykorzystujących je obiektów Uzasadnienie Problem wybór algorytmu zależy od wykorzystującego go obiektu lub danych, którymi operuje Gdy algorytm się nie zmienia Strategia jest NIEPOTRZEBNA Rozwiązanie oddzielamy wybór wersji algorytmu od jego implementacji. umożliwia wybór algorytmu na podstawie kontekstu Warunki stosowania wiele związanych klas różni się tylko zachowaniem 9
potrzeba różnych wersji algorytmu np z różnymi złożonościami czasowymi lub pamięciowymi ukrycie przed klientem danych, z których korzysta gdy klasa definiuje wiele zachowań występujących jako złożone instrukcje warunkowe (kolejne gałęzie należy przenieść do klas pochodnych) Struktura Elementy Strategy : deklaruje wspólny interfejs dla wszystkich używanych algorytmów, Kontekst używa interfejsu do wywołania odpowiedniej Strategii ConcreteStrategy : implementuje interfejs Strategy Context Współdziałanie Strategy i Context współpracują w celu realizacji algorytmu Context może przekazywać dane wymagane przez algorytm lub referencję do siebie Context przekazuje żądania od klientów do Strategy. Konsekwencje powoduje powstanie rodziny powiązanych algorytmów alternatywa dla tworzenia podklas (hermetyzacja > dziedziczenie) eliminacja wyrażeń warunkowych umożliwia wybór implementacji - np. różniące się złożonością (WADA) klienci muszą znać konkretne strategie, aby wybrać odpowiednią koszty komunikacji Context <-> Strategy (przekazywanie niewykorzystywanych parametrów) zwiększona liczna obiektów (dodatkowe obiekty Strategy) 10
Powiązane wzorce Pyłek (Flyweight) : obiekty Strategy warto tworzyć jako pyłki Metoda Szablonowa (TemplateMethod) : wzorzec klasowy, czynnościowy zdefiniowanie ogólnego szkieletu algorytmu pozostawienie implementacji niektórych króków dla klas pochodnych można zmienić niektóre kroki algorytmu nie zmieniając jego struktury Uzasadnienie Problem istnieje stały schemat, którego kroki różnią się jedynie w szczegółach Rozwiązanie pozwala na dodefiniowanie zmiennych operacji przy zachowaniu ogólnego schematu Przykład łączenie się z dowolną bazą danych wygląda podobnie, konkretne kroki są kwestią tego czy jest to MySQL, PostgreSQL, czy MongoDB. Warunki stosowania jednarozowa implementacja niezmiennych części algorytmu zostawiając podklasom implementację zmieniającego się zachowania refaktoryzacja uogólniająca : wyodrębnienie i umieszczenie w jednej klasie zachowania wspólnego dla podklas kontrola rozszerzeń w klasach pochodnych (punkty zaczepienia) Struktura 11
Elementy AbstractClass określa proste operacje definiowane przez podklasy implementuje metodę szablonową, która wywołuje proste operacje ConcreteClass implementuje proste operacje realizujące specyficzne dla podklasy szczegóły algorytmu Współdziałanie ConcreteClass polega na AbstractClass w zakresie implementacji stałych kroków algorytmu Konsekwencje podstawowa technika wielokrotnego wykorzystania kodu odwrotna struktura sterowania (zasada Hollywood) nie dzwoń do nas, my zadzwonimy do Ciebie klasa nadrzędna wywołuje operacje pochodnej nie na odwrót Implementacja minimalizacja operacji prostych (dla ułatwienia implementacji klas pochodnych) konwencje nazewnicze (np. dodawanie przedrostka jak do doread, docreatedocument ) 12
Powiązane wzorce FactoryMethod : można traktować jako specyficzny rodzaj metody szablonowej Strategy : w TemplateMethod do modyfikacji fragmentów algorytmu wykorzystuje się dziedziczenie, w Strategy do modyfikacji całego algorytmu korzysta się z delegacji Wykład 4 (Most) Most (Bridge) : wzorzec obiektowy, strukturalny oddzielamy abstrakcję od implementacji w taki sposób żeby można było wymienić implementację w sposób niezależny od innych komponentów. Uzasadnienie Problem klasy pochodne muszą używać wielu różnych implementacji, nie powodując nadmiernego wzrostu ilości klas pochodnych Rozwiązanie zdefiniowane wspólnego interfejsu dla wszystkich implementacji i wykorzystanie go przez klasy pochodne klasy abstrakcyjnej Przykład Warunki stosowania chcemy uniknąć stałego powiązania abstrakcji i implementaji (np implementacja zmieniana w trakcie wykonania programu) 13
abstrakcja i implementacja ma być rozszerzana niezależnie od siebie przez tworzenie podklas zmiany w implementacji nie powinny wymagać rekompilacji kodu klientów chcemy aby wiele obiektów miało wspólną implementację w sposób niewidoczny dla klienta Struktura Elementy Abstraction definiuje interfejs (np rysujfigure) zawiera referencję do obiektu Implementator RefinedAbstraction rozszerza interfejs abstrakcji Implementator definiuje interfejs klas implementacji, który może się znacząco różnić od interfejsu abstrakcji ConcreteImplementator implementuje interfejs Implementatora Współdziałanie Abstrakcja przekazuje żądania klienta do Implementatora Konsekwencje sparacja abstarkcji/interfejsu od implementacji: można zmieniać implementacji w trakcie wykonania eliminacja zależności abstracji od implementacji na etapie kompilacji sprzyja stosowaniu warstw - lepsza struktura systemu zwiększona rozszerzalność (abstrakcji i implementacji, niezależnie od siebie) ukrycie szczegółów implementacyjnych przed klientami 14
Powiązane wzorce AbstractFactory : może być użyta do utworzenia i skonfigurowania mostu Adapter : może być użyty we wzorcu do zaadaptowania istniejących implementacji o różnych interfejsach. Adapter dla gotowych systemów po ich implementacji, Most dla systemów na etapie projektowania. Wykład 5 (Decorator, Composite) Dekorator (Decorator) : wzorzec obiektowy, strukturalny dodanie dodatkowych odpowiedzialności w sposób dynamiczny alternatywa dla dziedziczenia w celu rozszerzania funkcjonalności Uzasadnienie Problem istniejący obiekt posiada funkcjonalność, ale potrzeba ją rozszerzyć o operację wykonywane przed oraz/lub po wykonywanych przez obiekt działaniach Rozwiązanie roszczerzenie funkcjonalności bez wykorzystania dziedziczenia Warunki stosowania do dynamicznego i przezroczystego (nie wpływającego na inne obiekty) dodawania odpowiedzialności do obiektów potrzeba mechanizmu obsługi zadań, które można cofnąć gdy rozszerzenie przez podklasę jest niepraktyczne lub brak dostępu do interfejsu klasy bazowej Struktura 15
Elementy Component : definiuje interfejs dla zmienianego obiektu ConcreteComponent : implementuje interfejs Component Decorator : przechowuje referencję do obiektu Component i definiuje interfejs zgodny z interfejsem Component ConcreteDecorator : dodaje odpowiedzialność / zadania do komponenetu Współdziałanie obiekt Decorator przekazuje żądania do obiektu Component może wykonywać operacje przed oraz/lub po przekazaniu żądania Konsekwencje większa elastyczność niż przy dziedziczeniu dekorator i komponenet nie są identyczne, dekorowany komponent jest jednak różny od standardowej wersji (WADA) projekty z Dekoratorem często prowadzą do systemów z dużą ilością podobnych obiektów, różniących się sposobem połączenia, ale nie klasą lub wartościami zmiennych, co może utrudniać analizę kodu Powiązane wzorce Adapter : zmiania interfejs, dekorator zmienia zachowanie Composite : Dekorator ~ uproszczony obiekt złożony obejmujący jeden komponent, ale nie służy do łączenia obiektów tylko do dodawania zachowań Strategy : dekorator zmienia skórkę obiektu, strategia zmienia mechanizmy wewnętrzne 16
Kompozyt (Composite) : wzorzec tworzenie struktur drzewiastych między obiektami odzwierciedlających hierarchię typu całość - część pozwala na traktowanie złożeń w ten sam sposób co indywidualne obiekty Uzasadnienie Warunki stosowania chcemy reprezentować hierarchię obiektów chcemy umożliwić klientom zignorowanie różnicy między indywidualnymi obiektami i ich złożeniami Struktura 17
Elementy Component definiuje interfejs dla złożonych obiektów implementuje domyślne zachowanie na potrzeby interfejsu wspólnego dla wszystkich klas definiuje interfejs dostępu do komponentów podrzędnych (dzieci) Leaf reprezentuje obiekty-liście == nie mające potomków definiuje zachowanie obiektów prostych w złożeniu Composite definiuje zachowanie komponentów mających potomków przechowuje komponenty podrzędne implementuje operacje z interfejsu Component Client manipuluje złożonymi obiektami poprzez interfejs klasy Component 18
Współdziałanie klient korzysta z interfejsu klasy Composite do interakcji z klasami w jego strukturze Konsekwencje definiuje hierarchie klas składających się z obiektów prostych i złożonych proste składają się na obiekty złożone upraszcza kod klienta, bo nie trzeba sprawdzać czy korzysta się z obiektu prostego czy też złożonego ułatwia dodawanie nowych rodzajów komponentów (nowe podklasy Composite lub Leaf od razu działają z istniejącymi strukturami) może powodować, że projekt stanie się zbyt ogólny Powiązane wzorce Chain of Responsibility : powiązanie między komponentami a elementami nadrzędnymi często wykorzystywane w tym wzorcu Decorator : często używany razem z Composite (wtedy wspólna klasa nadrzędna, Dekorator obsługuje interfejs klasy Component) Flyweight : umożliwia współużytkowanie komponentów nieprzechowujących referencji do elementów nadrzędnych Iterator : może być wykorzystywany do przeglądania zawartości kompozytów Visitor : zapewnia jedną lokalizację dla operacji i zachowań, które w innych podejściach są rozproszone po klasach compozytów i liści Wykład 6 (AbstractFactory, FactoryMethod, Singleton, Observer) Fabryka Abstrakcyjna (AbstractFactory) : wzorzec obiektowy, konstrukcyjny Jeden interfejs do tworzenia rodzin powiązanych lub zależnych obiektów bez potrzeby specyfikacji ich konkretnych klas. Uzasadnienie Problem Utworzenie odpowiednich rodzin obiektów. Rozwiązanie Stworzenie osobnego obiektu, który będzie je tworzyć zgodnie z regułami wydzielonymi z obiektów użytkownika. 19
Warunki stosowania system ma być niezależny od sposobu tworzenia, składania i reprezentacji jego produktów. system ma być skonfigurowany za pomocą jednej z wielu rodzin produktów rodzina powiązanych obiektów-produktów jest zaprojektowana jedynie do działania ze sobą i trzeba wymusić jednoczesne korzystanie z tych obiektów. chcemy udostępnić klasy biblioteczne jedynie przez ich interfejsy Struktura Elementy AbstractFactory : deklaruje interfejs tworzący obiekty abstrakcyjne ConcreteFactory : implementuje interfejs abstrakcyjnej fabryki AbstractProduct : deklaruje interfejs dla produktów ConcreteProduct : implementuje interfejs produktów Client : korzysta jedynie z interfejsu AbstractFactory i AbstractProduct 20
Współdziałanie powstaje jedna instancja klasy ConcreteFactory AbstractFactory wykorzystuje swoje podklasy do tworzenia odpowiednich obiektów Konsekwencje AF izoluje klasy konkretne AF ułatwia wymianę rodzin produktów AF ułatwia zachowanie spójności między produktami AF utrudnia dodawanie obsługi produktów nowego rodzaju Powiązane wzorce FactoryMethod, Prototype : AF często implementowane za pomocą tych wzorców Singleton : fabryki konkretne często realizowane jako singletony wzorzec klasowy, konstruk- Metoda Fabryczna (FactoryMethod) : cyjny Zdefiniowanie interfejsu do tworzenia obiektu z pozostawieniem decyzji o wyborze klasy tworzonego obiektu klasom pochodnym. Uzasadnienie Problem Klasa musi stworzyć obiekt jednej z klas pochodnych innej klasy, ale nie wie dokładnie, o którą z nich chodzi. Rozwiązanie Metoda wytwórcza pozwala podjąć decyzję jej klasie pochodnej. Warunki stosowania nie można ustalić klasy obiektów, które trzeba stworzyć chcemy, żeby klasy pochodne danej klasy określały tworzone przez nią obiekty klasy delegują zadania do jednej z kilku podklas pomocniczych i chcemy zapisać w określonym miejscu informację, która z tych podklas jest delegatem 21
Struktura Elementy Produkt: interfejs obiektów tworzonych przez MF ConcreteProduct: implementuje Produkt Creator: deklaryje metodę wytwórczą może wywoływać MF by utworzyć obiekt Produkt ConcreteCreator: zastępuje MF zwracając instancję klasy ConcreteProduct Współdziałanie Klasa Creator działa na podstawie założenia, że jej klasy pochodne definują metodę wytwórcą zwracającą obiekt odpowiedniej klasy ConcreteProduct Konsekwencje MF eliminuje potrzebę umieszczania w kodzie klas specyficznych dla aplikacji. Korzysta się jedynie z interfejsu klasy Product (WADA) Klienci mogą być zmuszeni do tworzenia klas pochodnych Creator a aby wygenerować konkretny ConcreteProduct Powiązane wzorce MF można traktować jako szczególny rodzaj metody szablonowej AbstractFactory - często implementowany za pomocą MF Prototype - nie trzeba tworzyć podklas klasy Creator, często konieczne jest umieszczenie operacji init w klasie Product. MF nie wymaga takich metod. Singleton : wzorzec obiektowy, konstrukcyjny 22
Zapewnia, że klasa będzie miała jedną instancję i będzie do niej globalny dostęp Uzasadnienie Problem W wielu miejscach w kodzie trzeba korzystać z jednego obiektu, który powinien być zainicjalizowany tylko raz w programie Rozwiązanie Zagwarantowanie wystąpienia tylko jednej instancji danej klasy Warunki stosowania potrzebujemy dokładnie jednej instancji klasy dostępnej klientom w ściśle określony sposób potrzbujemy możliwości rozszerzenia jednej instancji przez tworzenie podklas, a klienci powinni użyć wzbogaconej instancji bez konieczności modyfikacji kodu Struktura Elementy Singleton operacja Instance() dająca klientom dostęp do unikatowych instancji klasy. Metoda statyczna! może być sam odpowiedzialny za tworzenie unikatowej instancji Współdziałanie Klienci mają dostęp do instancji klasy wyłącznie poprzez operację Instance() 23
Konsekwencje Kontrola dostępu do jedynej instancji klasy Zmniejszenie przestrzeni nazw w porównaniu ze zmiennymi globalnymi przechowującymi jedyne egzemplarze Możliwość rozrzerzania operacji i reprezentacji Możliwość zwiększenia ilości instancji do ustalonego limitu (zliczanie instancji w Singletonie) Większa elastyczność w porównaniu z operacjami klasowymi (WADA) Problemy ze stosowanie w środowisku współbierznym, blokowanie dwufazowe Powiązane wzorce Z pomocą singletona można budować inne wzorce AbstractFactory Builder Prototype Obserwator (Observer) : wzorzec obiektowy, czynnościowy określenie powiązania jeden-do-wielu jeden obiekt zmienia stan wiele obiektów zależnych jest automatycznie o tym powiadamianych Uzasadnienie Problem Należy powiadomić zmieniającą się listę obiektów o pewnym zdarzeniu Rozwiązanie Obiekty klasy Observer przekazują odpowiedzialność za monitorowanie do centralnej klasy Subject Warunki stosowania abstrakcja ma dwa aspekty zależne od siebie. Hermetyzacja aspektów pozwala na wykorzystanie obiektów niezależnie od siebie zmiana jednego obiektu wymaga zmiany innych lecz nie wiadomo ile jest takich obiektów obiekt powinien mieć możliwość zawiadomienia innych obiektów bez określania ich rodzaju (bez założeń o typie) 24
Struktura Elementy Subject : zna powiązanych obserwatorów (jest ich dowolna ilość) definiuje interfejs do dołączania i odpinania obiektów Observer Observer : definiuje interfejs do aktualizacji dla obiektów, które należy powiadomić o zmianach w Subject ConcreteSubject: posiada stan istotny dla ConcreteObserver wysyła powiadomienie do powiązanych Obserwatorów ConcreteObserver: referencja do obiektu ConcreteSubject zawiera stan, który ma być zgodny z CS implementuje interfejs Observer Współdziałanie ConcreteSubject : powiadamia obserwatorów o zmianie stanu ConcreteObserver : po otrzymaniu informacji o zmianie stanu może wysłać zapytanie o szczegółowe informacje, które wpłyną na zmianę jego stanu Konsekwencje pozwala na dodawanie obserwatorów bez modyfikacji podmiotu lub/i innych obserwatorów abstrakcyjne sprzężenie pomiędzy Subject i Observer. Subject nie wie nic na temat obiektów klasy Observer. wsparcie dla grupowego wysyłania komunikatów 25
(WADA) nieoczekiwane lawinowe uaktualnienia - bez specjalnego protokołu drobna operacja na Subject może powodować gigantyczną ilość zmian w Observatorach Wykład 7 (Builder, Proxy) Budowniczy (Builder) : wzorzec obiektowy, konsturkcyjny oddzielamy konstrukcję obiektu od jego reprezentacji tak, że ten sam proces konstrukcyjny może dać różne reprezentacje Uzasadnienie Warunki stosowania algorytm tworzenia obiektu powinien być niezależny od części składowych tego obiektu i sposobu ich zestawienia proces konstrukcji ma umożliwiać tworzenie różnych reprezentacji tego obiektu Struktura 26
Elementy Builder: definiuje abstrakcyjny interfejs do tworzenia Productu ConcreteBuilder: Konstruuje i łączy części Productu Implementuje interfejs Builder Dostarcza interfejs do pobierania produktów definiuje i kontroluje tworzone reprezentacje Director: konstruuje Product za pomocą interfejsu Buildera Product: reprezentuje złożony Product zawiera klasy definujące części składowe obiektu, w tym interfejsy do składania części Współdziałanie Klient tworzy obiekt Director i konfiguruje go za pomocą odpowiedniego obiektu Buildera kiedy potrzeba części produktu Director wysyła powiadomienia do Buildera Builder obsługuje żądania od Directora i dodaje odpowiednie komponenty do produktu Klient odbiera od Buildera Produkt Konsekwencje 27
możliwość modyfikacji reprezentacji wewnętrznej produktu odseparowanie kodu do służącego do tworzenia produktu od reprezentacji większa kontrola nad procesem tworzenia Powiązane wzorce AbstractFactory : przypomina Buildera, ale nacisk położony na rodziny obiektów oraz produkt jest udostępniony od razu, Builder natomiast jest tworzony krok po kroku i jest zwracany w ostatnim kroku Composite: często tworzony przy pomocy Buildera Pełnomocnik (Proxy): wzorzec obiektowy, strukturalny dostarczenie pośrednika w dostępie do określonego obiektu Warunki stosowania proxy tam gdzie trzeba wyrafinowaej referencji a nie wzkaźnik Częste zastosowania: Remote proxy : lokalna reprezentacja zdalnego obiektu z innej przestrzeni adresowej Virtual proxy : pośrednik tworzący kosztowne obiekty na żądanie Protected proxy : pośrednik, który sprawdza czy dostęp jest zaautoryzowany, dla obiektów z różnymi prawami dostępu Cache proxy : przechowuje rezultaty odwołań do zdalnych komponentów do wykorzystania przez lokalnych klientów. Syc proxy : w środowisku współbierznym dostęp do obiektu Firewall proxy : chroni lokalnych klientów przed zewnętrznym światem Smart proxy : zastępuje zwykłe odniesienie i wykonuje dodatkowe operacje, np: zliczanie referencji w celu ułatwienie sprzątania pamięci (smart pointer) ładowanie obiektu do pamięci w momencie pierwszego odwołania (ghost) sprawdzanie przed dostępem do obiektu czy jest zablokowany, by inny obiekt go nie zmienił Struktura 28
Elementy Proxy posiada referencję do rzeczywistego obiektu identyczny interfejs z obiektem, który pośredniczy kontroluje dostęp Subject definuje interfejs klas RealSubject i Proxy RealSubject rzeczywisty obiekt, do którego się dobieramy przez Proxy Współdziałanie Proxy przekazuje żądania do RealSubject Konsekwencje dodanie poziomu pośredniego przy dostępie Powiązane wzorce Adapter: tworzy nowy interfejs do obiektu, Proxy ma dokładnie ten sam Dekorator: można podobnie implementować, ale Dekorator dodaje funkcje, Proxy kontroluje dostęp do nich Wykład 8 (Chain of Responsibility, State) Łańcuch Odpowiedzialności (Chain of Responsibility): wzorzec obiektowy, czynnościowy Umożliwienie obsługi żądania większej liczbie obiektów. 29
Obiekty odbiorcze łączone są w łańcuch, wzdłuż, którego przekazywane jest żądanie do momentu obsłużenia go Uzasadnienie Warunki stosowania więcej niż jeden obiekt może obsłużyć żądanie odbiorca nie jest z góry znany i powinien być ustalony automatycznie chcemy wysłać żądanie do jednego z kilku obiektów zbiór obiektów realizujących żądanie może być stworzony dynamicznie Struktura Elementy Handler: obsługuje żądania (opcjonalnie) ma odwołanie do następnika w łąńcuchu ConcreteHandler: obsługuje żądania ma dostęp do następnika jeśli może obsłużyć to obsługuje wpp przekazuje dalej Client: inicjuje żądanie przez przekazanie do ConcreteHandler Współdziałanie Klient przekazuje żądanie do łańcucha żądanie jest przekazywane aż do obsłużenia 30
Konsekwencje zredukowane powiązanie pomiędzy wysyłającym żądanie a obsługującym zwiększenie elastyczności w zakresie przypisywania zadań obiektom (WADA)brak gwarancji obsłużenia żądania Powiązane wzorce Composite: często stosowane razem z Łańcuchem (obiekt nadrzędny może pełnić funkcję następnika) Stan (State) : wzorzec obiektowy, czynnościowy umożliwia zmianę zachowania w zależności od stanu wewnętrznego wygląda jakby obiekt zmienił klasę Uzasadnienie Warunki stosowania obiekt istotnie zmienia zachowanie w zależności od stanu chcemy uniknąć zagnieżdżonych instrukcji warunkowych State umożliwia wrzucenie gałęzi do osobnych klas Struktura Elementy Context interfejs dla klientów przechowuje bieżący ConcreteState State: definiuje interfejs reprezentujący zachowanie związane ze stanami ConcreteState Podklasy ConcreteState każda implementuje zachowanie związane z jednym stanem obiektu Context 31
Współdziałanie Context deleguje żądanie do ConcreteState Context jest interfejsem dla klientów Klasa Context decyduje o kolejności i warunkach zmiany stanu Konsekwencje zachowanie specyficzne dla określonego stanu zebrane w jednym miejscu dodawanie nowych stanów ułatwione przez podklasy ConcreteState jawność przejść międzystanowych możliwość współdzielenia obiektów stanu (wtedy to Flyweight) Powiązane wzorce Flyweight: określa, kiedy i jak współużywać obiekt State Singleton: obiekty State to często singletony Wykład 9 (Prototype, Mediator, Command, Visitor) Prototyp (Prototype) : wzorzec obiektowy, konstrukcyjny określa rodzaje tworzonych obiektów na podstawie egzemplarza-prototypu nowe obiekty przez kopiowanie prototypu Warunki stosowania system ma być niezależny od sposobu tworzenia, składania i reprezentacji produktów klasy tworzonych obiektów są określane w czasie wykonywania programu chcemy uniknąć tworzenia hierarchii fabryk instancje klasy mogą mieć jeden z niewielu stanów (wygodniej utworzyć kilka prototypów w odpowiednich stanach, a potem je klonować) Struktura Elementy Prototype: ConcretePrototype Client 32
Współdziałanie Client żąda kopii prototypu od niego ( sklonuj się ) Konsekwencje dodawanie i usuwanie produktów w czasie wykonania nowe zachowania nie przez tworzenie klas ale przez składanie obiektów tworzenie obiektów złożonych, nowe obiekty przez zmianę struktury zredukowanie liczby podklas - nie trzeba nam nowych klas jak w przypadku metody fabrycznej (WADA) : w każdej klasie Prototype trzeba zaimplementować metodę Clone(), utrudnione użycie przy gotowych klasach, które jej nie obsługują Powiązane wzorce AbstractFactory : może przechowywać zestaw prototypów stosowanych do tworzenia produktów-klonów Composite, Decorator : prototyp często wykorzystywany w projektach z tymi wzorcami Mediator (Mediator) : wzorzec obiektowy, czynnościowy hermetyzacja informacji o interakcji pomiędzy obiektami ze zbioru pozwala zachować luźne powiązanie między obiektami brak bezpośrednich odwołań obiektów między sobą Warunki stosowania zbiór obiektów komunikuje się w złożony ale dobrze określony sposób zależności są z tego powodu nieustrukturyzowane i trudne do zrozumienia ponowne użycie obiektu jest trudne, bo odwołuje się do wielu innych obiektów dostosowanie zachowania rozproszonego po kilku klasach ma nie wymagać tworzenia podklas Struktura 33
Elementy Mediator : interfejs komunikacji klas współpracujących ConcreteMediator: implementuje Mediator, zarząda współpracującymi obiektami rodzina klas Colleague: każdy obiekt współpracujący zna powiązany obiekt Mediator każdy obiekt współpracujący komunikuje się z obiektem Mediator a nie klasamy współpracującymi Współdziałanie obiekty współpracujące wysyłają i otrzymują żądania jedynie przez Mediatora Mediator zapewnia współdziałanie przez przekazywanie żądań pomiędzy odpowiednimi współpracownikami Konsekwencje uproszczeni komunikacji obiektowej. s/ wiele-do-wielu / jeden-do-wielu rozdzielenie obiektów współpracujących abstrakcja współpracy obiektów (POTENCJALNA WADA )centralizacja sterowania może powodować dużą złożoność Mediatora Powiązane wzorce Facade: różna od Mediatora, bo protokół komunikacji jest jednokierunkowy skupia się na udostępnieniu wygodnego interfejsu Mediator - wspólne realizowanie zachowań Observer: 34
obiekty mogą się komunikować z Mediatorem za pomocą wzorca Observer Komenda (Command) : wzorzec obiektowy, czynnościowy hermetyzacja żądania w obiekcie. umożliwia kolejkowanie i rejestracje żądań, jak również realizację operację cofania Warunki stosowania parametryzować obiekty przy pomocy wykonywanych działań określać, kolejkować i wywoływać żądania w różnych miejscach programu by zapewnić możliwość operacji cofania by rejestrować zmiany tak by móc je odtworzyć po awarii systemu by oprzeć strukturę systemu na wysokopoziomowych operacjach zbudowanych z podstawowych Struktura Elementy Command: definiuje interfejs ConcreteCommand definiuje powiązanie między Receiver a akcją do wykonania Implementuje Execute() przez wywołanie operacji Receiver Client tworzy ConcreteCommand i wiąże go z Receiver Invoker żąda obsłużenia żądania od Command Receiver potrafi wykonać operacje potrzebne do realizacji żądania 35
Współdziałanie Klient tworzy ConcreteCommand i wiąże z Receiver Invoker przechowuje ConcreteCommand Invoker woła Execute na ConcreteCommand ConcreteCommand woła operacje Receiver by obsłużyć żądanie Konsekwencje Command oddziela obiekty wywołujące operację od tych które je implementują Command można rozszerzać jak inne obiekty Command można łączyć w złożone polecenia Łatwo dodawać nowe polecenia Powiązane wzorce Composite: można wykorzystać do implementacji MacroCommand Memento: umożliwa zachowanie stanu potrzebnego w poleceniu do cofnięcia operacji Prototype: polecenie, które trzeba skopiować przed umieszczeniem w historii działa jak prototyp Wizytator (Visitor) : wzorzec obiektowy, czynnościowy reprezentacja operacji, która ma być wykonywana na kolekcji nie trzeba zmieniać elementów, na których działa operacja Warunki stosowania struktura zawiera wiele klas o zróżnicowanych interfejsach, a my chcemy wykonywać operacje, które zależą od innych konkretnych klas potrzeba wykonać wiele niezależnych operacji na obiektach, ale nie chcemy wrzucać ich do tych obiektów klasy definujące strukturę zmieniają się rzadko, a my chcemy dodawać nowe operacje na strukturze Struktura 36
Współdziałanie Klient tworzy ConcreteVisitor, który przechodzi przez kolekcje Element kolekcji wykonuje operację Visitora, gdy jest odwiedzany Konsekwencje łatwo dodawać nowe operacje narusza hermetyzację klas, które odwiedza akumulacja stanu (np zlicznie czegoś w kolekcji) realizowane jest całkowicie wewnętrznie, bez zmiennych globalnych, bez zmiennych globalnych, bez zmiennych globalnych Powiązane wzorce Composite : można wykorzystać Visitor do operacji na strukturze kompozytu Interpreter : można zastosować Visitor do interpretacji (zdań z języka) 37
Wykład 10 (Interpreter, Memento, Flyweight) Interpreter (Interpreter) : wzorzec klasowy, czynnościowy definiuje reprezentację gramatyki języka używa jej do interpretacji zdań z tego języka Warunki stosowania korzystamy przy interpretacji języków, w których zdania mogą być przedstawione jako AST - drzewa składni abstrakcyjnej najlepiej gdy gramatyka jest prosta najlepiej gdy wydajność nie jest czynnikiem krytycznym Struktura Elementy AbstractExpression: TerminalExpression NonTerminalExpression Context Client Współdziałanie 38
Client otrzymuje zadanie w postaci AST zbudowanego z TerminalExpression i NonTerminalExpression, następnie inicjalizuje Context i wywołuje Interpret() Każdy wierzołek klasy NonTerminalExpression definuje operację Interpret(), operacja w TerminalExpression jest przypadkiem bazowym rekurencji Konsekwencje Łatwo zmieniać i modyfikować gramatykę Łatwo zaimplementować gramatykę Złożone gramatyki są trudne w utrzymaniu bo każda reguła potrzebuje przynajmniej jednej klasy Dodawanie nowych sposobów interpretacji wyrażeń jest stosunkowo łatwe Powiązane wzorce Composite: AST można zbudować jako kompozyt Flyweight: pozwala współużywać symbole terminalne w AST Iterator: interpreter może używać go do przechodzenia po AST Visitor: można wykorzystać do wyłączenia jednej z operacji dla węzłów AST Pamiątka (Memento) : wzorzec obiektowy, czynnościowy zapis wewnętrznego stanu obiektu bez naruszenia hermetyzacji Warunki stosowania musimy zachować snapshot stanu obiektu (lub jego fragment) publiczny interfejs dający dostęp do stanu ujawnia szczegóły implementacyjne i narusza hermetyzację obiektu Struktura 39
Współdziałanie Zarządca chce dostać stan wewnętrzny (Memento) Memento jest bierne, Origin, który je utworzył przypisuje do niego stan Konsekwencje zachowanie hermetyzacji (WADA) potencjalnie wysokie koszty jeśli trzeba zapisać dużo informacji (KOPIOWANIE) (WADA) ukryte koszty przy zarządzaniu pamiątkami - usuwanie, przechowywanie może zjadać dużo pamięci Powiązane wzorce Command : może korzystać z Memento na potrzeby cofania operacji Iterator: może korzystać z Memento do zapisu stanu iteracji Pyłek (Flyweight) : wzorzec obiektowy, strukturalny użycie współdzielenia do efektywnej obsługi dużej ilości małych obiektów Warunki stosowania aplikacja używa dużej ilości obiektów koszty przechowywania obiektów są duże bo jest ich wiele większość stanu obiektów można zapisać poza nim wiele grup obiektów po przeniesieniu stanu na zewnątrz można zastąpić przez niewiele współdzielonych obiektów aplikacja nie zależy od tego, że różne obiekty będą tak na prawde tymi samymi (współdzielenie) 40
Struktura Współdziałanie stan pyłku dzielimy na wewnętrzny i zewnętrzny. stan zewnętrzny przekazuje do pyłku klient w czasie wykonywania operacji pyłki tworzone są przez FabrykęPyłków, więc są poprawnie współdzielone Konsekwencje oszczędność pamięci (WADA) koszty związane z przeliczaniem stanu poza klasą, przenoszeniem, wyszukiwaniem są duże Powiązane wzorce Composite: często stosowany razem z pyłkiem żeby zaimplementować hierarchiczną struktrę State, Strategy: często mądrze implementować jako pyłki 41
Wykład 11 (Wzorce architektoniczne) Model-View-Controller (MVC): wzorzec architektury aplikacji interkatywnych Model-View-Presenter (MVP) Layers Model-View-ViewModel (MVVM ) 42