Techniki projektowania wzorce projektowe

Techniki projektowania wzorce projektowe

2 Przykład: Kasa fiskalna Opis dziedziny problemu System jest przeznaczony do obsługi procesu sprzedaży. Podstawowa funkcjonalność systemu obejmuje takie czynności jak: wprowadzanie kodów towarów kupowanych przez klienta, obliczanie kwoty do zapłaty, obsługa wszystkich rodzajów płatności (m.in. gotówka, karta kredytowa). System powinien współpracować z systemami finansowo-księgowymi. Ze względu na zmieniające się przepisy podatkowe system powinien umożliwiać zmianę reguł obliczania podatków. System musi ponadto utrzymywać aktualną bazę dostępnych towarów

3 Identyfikacja klas konceptualnych (1) Store reprezentuje sklep. Sklep opisany jest atrybutami oznaczającymi jego nazwę i fizyczną lokalizację (name, address) Register reprezentuje kasę fiskalną, na której dokonywane są transakcje Cashier reprezentuje osobę obsługującą kasę fiskalną Customer reprezentuje klienta dokonującego zakupu

4 Identyfikacja klas konceptualnych (2) ProductCatalog reprezentuje katalog produktów oferowanych do sprzedaży ProductDescription reprezentuje opis produktu. Zawiera takie atrybuty jak description (opis produktu) oraz price (cena) Payment reprezentuje płatność. Zawiera atrybut amounttendered do przechowywania zapłaconej kwoty

5 Identyfikacja klas konceptualnych (3) Sale reprezentuje bieżącą sprzedaż (i jednocześnie dokument sprzedaży). Zawiera atrybut date do przechowywania daty transakcji oraz atrybut total do przechowywania całkowitej kwoty do zapłaty SaleLineItem reprezentuje jedną pozycję na dokumencie sprzedaży. Zawiera atrybut quantity do przechowywania ilości zakupionego towaru

6 Model dziedziny

7 Przypadek użycia Przypadek użycia: Obsługa sprzedaży Wyzwalacz: Klient przychodzi do kasy z produktami, które zamierza kupić Scenariusz główny: 1. Kasjer rozpoczyna nowy proces sprzedaży 2. Kasjer skanuje kod towaru 3. System rejestruje pozycje sprzedaży, wyświetla opis produktu, cenę oraz oblicza kwotę do zapłaty 4. Kroki 2-3 są powtarzane dla wszystkich produktów 5. System wyświetla kwotę do zapłaty 6. Kasjer informuje klienta o kwocie do zapłaty 7. Klient za pośrednictwem kasjera dokonuje płatności 8. System rejestruje płatność

8 Diagram sekwencji systemowych Główny scenariusz: 1. Kasjer rozpoczyna nowy proces sprzedaży 2. Kasjer skanuje kod towaru 3. System rejestruje pozycje sprzedaży, wyświetla opis produktu, cenę oraz oblicza kwotę do zapłaty 4. Kroki 2-3 są powtarzane dla wszystkich produktów 5. System wyświetla kwotę do zapłaty 6. Kasjer informuje klienta o kwocie do zapłaty 7. Klient za pośrednictwem kasjera dokonuje płatności 8. System rejestruje płatność

9 Kontrakty dla operacji systemowych (1) Operacja: MakeNewSale() Warunki początkowe: Istnieje obiekt r klasy Register Warunki końcowe: Utworzono obiekt s klasy Sale Atrybutowi s.datetime przypisano bieżącą datę i czas Utworzono związek pomiędzy obiektem s a obiektem r

10 Kontrakty dla operacji systemowych (2) Operacja: EnterItem(itemId, quantity) Warunki początkowe: Istnieje obiekt s klasy Sale oraz obiekt pd klasy ProductDescription Warunki końcowe: Utworzono obiekt sli klasy SaleLineItem Atrybutowi sli.quantity przypisano wartość argumentu quantity Utworzono związek pomiędzy obiektem sli a obiektem s Utworzono związek pomiędzy obiektem sli a obiektem pd

11 Kontrakty dla operacji systemowych (3) Operacja: EndSale() Warunki początkowe: Istnieje obiekt s klasy Sale Warunki końcowe: Atrybutowi s.iscomplete przypisano wartość true

12 Kontrakty dla operacji systemowych (4) Operacja: MakePayment(amount) Warunki początkowe: Istnieje obiekt s klasy Sale Warunki końcowe: Utworzono obiekt p klasy Payment Atrybutowi p.amounttendered przypisano wartość argumentu amount Utworzono związek pomiędzy obiektem p a obiektem s

13 Projektowanie interakcji wg DDD wskazówki Operacja systemowa trafia do jednego z serwisów Do zadań serwisu należy pobranie z repozytorium obiektu biznesowego, którego dotyczy operacja oraz delegowanie wykonania operacji do tegoż obiektu Jeśli operacja nie może być przypisana do jednego obiektu biznesowego, wówczas serwis wykonuje wszystkie czynności wymagane przez operacje

14 Projektowanie Stan wyjściowy: Operacje systemowe są specyfikacją zachowania systemu widzianego z poziomu jego klienta (np. interfejsu użytkownika). Kontrakty dla operacji systemowych opisują stan systemu przed i po wykonaniu operacji systemowej Problem do rozwiązania: Jak przypisać odpowiedzialności do poszczególnych klas i zaprojektować interakcje obiektów, aby zrealizować warunki zapisane w kontrakcie?

15 Wzorce GRASP GRASP - General Resposibility Assignment Software Patterns GRASP to zbiór kilku wzorców projektowania obiektowego związanych z przypisywaniem odpowiedzialności do klas. Autorem wzorców GRASP jest Craig Larman Każdy ze wzorców GRASP to rodzaj zalecenia projektowego, którego uwzględnienie z reguły prowadzi do lepszego rozwiązanie problemu

16 Wzorce GRASP Ekspert (ang. Expert) Kreator (ang. Creator) Kontroler (ang. Contoller) Luźne sprzężenie (ang. Low Coupling) Wysoka spójność (ang. High Cohesion) Pure Fabrication Polimorfizm (ang. Polimorphism)

17 Wzorce GRASP - Kreator Problem: Która klasa powinna być odpowiedzialna za tworzenie nowych instancji danej klasy? Rozwiązanie: Przypisz klasie B odpowiedzialność tworzenia nowych instancji klasy A, jeśli zachodzi jeden lub kilka z poniższych warunków: Klasa B zawiera (agreguje) obiekty klasy A Klasa B rejestruje obiekty klasy A Klasa B intensywnie używa obiekty klasy A Klasa B posiada dane niezbędne do zainicjalizowania obiektów klasy A

18 Wzorce GRASP Kreator Im więcej z powyższych punktów jest spełnione, tym mocniejsze jest uzasadnienie dla wyboru klasy B jako kreatora obiektów klasy A W sytuacji, gdy kilka klas kandyduje do bycia kreatorem obiektów klasy A, wówczas wybieramy te klasę, która spełnia najwięcej z powyższych warunków

19 Kreator - przykład Problem: Która klasa powinna być odpowiedzialna za utworzenie obiektu typu SalesLineItem? Kandydaci: Sale zawiera obiekty typu SalesLineItems używa obiekty typu SalesLineItems posiada niezbędne dane (quantity) do zainicjowania obiektu typu SalesLineItems model dziedziny (fragment ) ProductDescription - jest opisem dla obiektów SalesLineItems

20 Kreator - przykład Rozwiązanie: Na podstawie wzorca Kreator obiekty klasy SalesLineItem powinny być tworzone przez obiekt klasy Sale

21 Kreator - przykład Elementy modelu projektowego: kierunek nawigacji od Register do Sale atrybut currentsale w klasie Register realizacja związku Register Sale kierunek nawigacji od Sale do SalesLineItem atrybut lineitems w klasie Sale realizacja związku Sale - SalesLineItems Model projektowy (fragment)

22 Wzorce GRASP - Ekspert Problem: Jak brzmi najbardziej ogólna zasada przypisywania odpowiedzialności? Której klasie przypisać daną odpowiedzialność? Rozwiązanie: Przypisz odpowiedzialność klasie, która ma niezbędne informacje, aby ją zrealizować

23 Wzorce GRASP - Ekspert Wzorzec Ekspert jest jedną z elementarnych zasad projektowania obiektowego Mimo iż powyższa zasada brzmi jak coś oczywistego, jej zastosowanie może nieraz nastręczać trudności Potencjalne problemy z poprawnym stosowaniem wzorca ekspert wynikają najczęściej z rozproszenia informacji po wielu różnych klasach

24 Wzorce GRASP - Ekspert Do poprawnego zastosowania wzorca Ekspert w przypadku rozproszenia informacji konieczny jest podział odpowiedzialności pomiędzy wszystkie klasy posiadające częściowe informacje Każda z klas posiadających częściowe informacje jest tzw. częściowym ekspertem Innym problemem związanym ze wzorcem Ekspert jest naturalna skłonność do przypisywania odpowiedzialności kierując się zasadą, by klasy systemu informatycznego zachowywały się podobnie jak klasy w świecie rzeczywistym, co nie zawsze jest dobrym rozwiązaniem

25 Ekspert - przykład Problem: Która klasa powinna być odpowiedzialna za obliczenie kwoty do zapłaty Kandydaci: Sale zawiera atrybut total do przechowywania kwoty do zapłaty SalesLineItem zawiera atrybut quantity niezbędny do obliczenia kwoty do zapłaty za każdy z produktów z osobna model dziedziny (fragment ) ProductDescription zawiera atrybut price z bieżącą ceną każdego z produktów

26 Ekspert - przykład Rozwiązanie: Klasy SalesLineItem i ProductDescription są częściowymi ekspertami - zawierają jedynie cześć informacji niezbędnej do obliczenia całkowitej kwoty do zapłaty Do obliczenia całkowitej kwoty do zapłaty należy zaprojektować odpowiednią interakcję pomiędzy wszystkimi klasami posiadającymi cząstkową informację

27 Ekspert - przykład Elementy modelu projektowego: kierunek nawigacji od SalesLineItem do ProductDescription atrybut description w klasie SalesLineItem realizacja związku SalesLineItem - ProductDescription Operacja GetTotal() w klasie Sale Operacja GetSubtotal() w klasie SalesLineItem Model projektowy (fragment) Operacja GetPrice() w klasie ProductDescription

28 Wzorce GRASP Kontroler Problem: Która klasa spoza interfejsu użytkownika powinna jako pierwsza obsługiwać operacje systemową? Rozwiązanie: Przypisz odpowiedzialność klasie, dla której prawdziwe jest jedno z poniższych stwierdzeń: reprezentuje cały system, podsystem, obiekt leżący najwyżej w hierarchii (ang. root object) reprezentuje przypadek użycia, w którym operacja systemowa ma miejsce

29 Wzorce GRASP Kontroler Kontroler reprezentujący cały system, podsystem itp. pełni role fasady dla całej warstwy logiki biznesowej Na ogół kontroler nie posiada wystarczającej wiedzy, aby kompletnie obsłużyć żądanie, stąd jego praca polega na znalezieniu odpowiedniego obiektu z warstwy logiki biznesowej i przekazaniu do niego sterowania (delegacja) Kontroler typu fasada stosuje się w niewielkich systemach, gdzie nie ma zbyt wielu operacji systemowych Jeśli w systemie jest dużo operacji systemowych, wówczas stosuje się kontrolery reprezentujące pojedyncze przypadki użycia, bądź też grupujące kilka przypadków użycia

30 Wzorce GRASP Kontroler Kontrolery reprezentujące przypadki użycia są w istocie w istocie tworami sztucznymi, nie mającymi odpowiednika w dziedzinie problemu Kontrolera GRASP nie należy mylić z kontrolerem ze wzorca Model-Widok- Kontroler, który jest elementem warstwy interfejsu użytkownika Kontroler GRASP należy do warstwy logiki biznesowej (znajduje się na granicy tej warstwy)

ROZWIĄZANIE I KONTROLER TYPU FASADA Klasy pełniące role kontrolerów Kontroler Zarządzanie wykonywaniem operacji systemowych Przechowywanie i udostępnianie obiektów warstwy biznesowej warstwa aplikacji warstwa logiki biznesowej 31

KONTROLER TYPU FASADA CHARAKTERYSTYKA Kontroler reprezentujący cały system, podsystem itp. pełni role fasady dla całej warstwy logiki biznesowej W zakresie odpowiedzialności kontrolera typu fasada leży: koordynacja działań związanych z wykonywaniem operacji systemowych przechowywanie i udostępnianie obiektów warstwy logiki biznesowej Kontroler typu fasada stosuje się w niewielkich systemach, gdzie nie ma zbyt wielu operacji systemowych 32

ROZWIĄZANIE II KONTROLER TYPU PRZYPADEK UŻYCIA Klasy pełniące role kontrolerów Kontroler Zarządzanie wykonywaniem operacji systemowych Repozytorium warstwa aplikacji warstwa logiki biznesowej warstwa infrastruktury Przechowywanie i udostępnianie obiektów warstwy biznesowej 33

KONTROLER TYPU PRZYPADEK UŻYCIA - CHARAKTERYSTYKA W zakresie odpowiedzialności kontrolera leży koordynacja działań związanych z wykonywaniem operacji systemowych Klasa Repozytorium jest odpowiedzialna za przechowywanie i udostępnianie obiektów warstwy biznesowej Kontrolery reprezentujące pojedyncze przypadki użycia (lub kilka przypadków użycia) stosuje się w bardziej złożonych systemach, gdzie występuje większa liczba operacji systemowych i/lub wymagane jest zapisywanie i odtwarzanie stanu systemu po wykonaniu pewnego ciągu operacji systemowych 34

REPOZYTORIUM Zasada Persistence Ignorance System należy projektować w sposób niezależny od infrastruktury, w tym od wszystkich mechanizmów dostępu do danych Cała logika związana z dostępem do bazy danych w celu odtworzenia, zapisania lub wyszukania obiektów biznesowych zaszyta jest w Repozytorium Z punktu widzenia warstwy logiki biznesowej Repozytorium pełni rolę kolekcji obiektów biznesowych 35

REPOZYTORIUM PRZYKŁAD Repozytorium wydarzeń Wydarzenie Alarm Uczestnictwo Repozytorium osób Osoba Adres 36

37 Kontroler - przykład Problem: Która klasa jako pierwsza obsługuje operacje systemowe takie jak: MakeNewSale(), EnterItem(), EndSale(), MakePayment()? model dziedziny (fragment) Kandydaci: Store - reprezentuje cały system Register - reprezentuje podsystem ProcessSaleHandler klasa utworzona specjalnie w tym celu

38 Kontroler - przykład Rozwiązanie 1: funkcje kontrolera pełni klasa Register. Jest to kontroler typu fasada - stosuje się w sytuacji, gdy liczba operacji systemowych jest nieduża Rozwiązanie 2: funkcje kontrolera pełni specjalnie w tym celu utworzona klasa ProcessSaleHandler. Jest to kontroler typu przypadek użycia - stosuje się w sytuacji, gdy liczba operacji systemowych jest znaczna Komentarz: Obydwa rozwiązania są do zaakceptowania. Niemniej praktyka pokazuje, że liczba identyfikowanych operacji systemowych w kolejnych iteracjach projektu wzrasta, stąd preferowane są rozwiązania z dedykowanym kontrolerem (rozwiązanie 2)

39 Kontroler - przykład Elementy modelu projektowego: Operacja MakeNewSale() w klasie Register Operacja EnterItem() w klasie Register Operacja MakePayment() w klasie Register Model projektowy (fragment) Operacja EndSale() w klasie Register

40 Sprzężenie Sprzężenie (ang. coupling) miara wzajemnej zależności obiektów Niski poziom sprzężeń: Stosunkowo niewielka liczba związków między klasami Możliwość grupowania klas ściślej ze sobą powiązanych Wysoki poziom sprzężeń: Duża liczba związków między klasami Brak możliwości grupowania klas wszystkie klasy są ze sobą ściśle powiązane

41 Wzorce GRASP - Luźne sprzężenie Problem: W jaki sposób spowodować, żeby zmiany we fragmencie modelu jak najmniej wpływały na pozostała część modelu? Co należy czynić, aby zwiększyć możliwość ponownego wykorzystania kodu? Rozwiązanie: Przypisuj odpowiedzialności w taki sposób, aby ograniczyć liczbę związków między klasami

42 Wzorce GRASP - Luźne sprzężenie Model zawierający dużo związków między klasami charakteryzuje wiele negatywnych cech: zmiany w jednej klasie implikują zmiany w innych klasach problem ze zrozumieniem modelu trudności w ponownym użyciu (wymaga to użycia wszystkich klas powiązanych) Z drugiej strony związki między klasami są nieodłączną cechą każdego modelu obiektowego - umożliwiają realizację zasady podziału odpowiedzialności Postulat luźnych sprzężeń nie sugeruje w żaden sposób usunięcia związków między klasami. Sugeruje jedynie, że jeśli istnieje możliwość zrealizowania określonej funkcjonalności bez zwiększania poziomu zależności, to należy taką opcję wybrać

43 Luźne sprzężenie - przykład Problem: Która klasa powinna być odpowiedzialna za utworzenie obiektu typu Payment i powiązanie go z obiektem typu Sale? Zaproponować rozwiązanie w oparciu o zasadę Luźne sprzężenie model dziedziny (fragment ) Kandydaci: Register Sale

44 Luźne sprzężenie - przykład nowy związek Rozwiązanie 1: Klasa Register jest odpowiedzialna za utworzenie obiektu klasy Payment (zastosowano wzorzec Kreator - w świecie rzeczywistym kasa fiskalna rejestruje płatności) Klasa Register odpowiada za utworzenie powiązania pomiędzy obiektem klasy Sale i obiektem klasy Payment (metoda AddPayment()) Wniosek: Rozwiązanie 1 zwiększa liczbę związków między klasami - powstał nowy związek pomiędzy klasą Register a klasą Payment

45 Luźne sprzężenie - przykład Rozwiązanie 2: (preferowane) Klasa Register deleguje do klasy Sale utworzenie obiektu klasy Payment Klasa Sale odpowiada za utworzenie obiektu klasy Payment i utworzenie powiązania pomiędzy obiektem klasy Sale i nowo utworzonym obiektem klasy Payment Wniosek: Rozwiązanie 2 nie zwiększa liczby związków między klasami - rozwiązanie preferowane z punktu widzenia zasady Luźne sprzężenie

46 Luźne sprzężenie - przykład Elementy modelu projektowego: kierunek nawigacji od Sale do Payment atrybut payment w klasie Sale realizacja związku Sales - Payment Operacja MakePayment() w klasie Sale

47 Spójność Spójność (ang. cohession) miara wzajemnego zintegrowania metod składowych klas Niski poziom spójności: Klasa A wykonuje samodzielnie wszystkie operacje Duża liczba operacji w klasie A Średni poziom spójności Klasa A deleguje odpowiedzialność do innych klas Klasa A koordynuje wszystkie operacje Wysoki poziom spójności Klasa A deleguje odpowiedzialność do innych klas Operacje w klasach pomocniczych również delegują część odpowiedzialności

48 Wzorce GRASP Wysoka spójność Problem: Jak sprawić, aby klasa była łatwa do zarządzania, zorientowana na jedno określone zadanie, a jej kod był zrozumiały? Rozwiązanie: Przypisz odpowiedzialność w taki sposób, aby spójność była jak największa

49 Wzorce GRASP Wysoka spójność Klasa, która ma zbyt wiele niezwiązanych ze sobą odpowiedzialności posiada niską spójność (kohezję) Niską kohezją charakteryzuje się również klasa, która co prawda odpowiada za jedno zadanie, ale zadanie to jest mocno skomplikowane i jest realizowane samodzielnie przez jedną klasę Aby poprawić kohezje w tym przypadku należy realizację tego zadania rozłożyć na kilka współpracujących ze sobą klas

50 Wzorce GRASP Wysoka spójność Klasa o wysokiej spójności to klasa skupiona na realizacji ściśle określonej funkcjonalności, posiłkująca się innymi klasami w sytuacji, gdy nie posiada wystarczających informacji lub realizacja funkcjonalności jest złożonym procesem Klasy o wysokiej kohezji to klasy, które posiadają stosunkowo niewiele metod, metody są ze sobą powiązane, kod metod jest krótki i czytelny, a w sytuacji bardziej złożonej logiki następuje delegacja odpowiedzialności do klas współpracujących

51 Wysoka spójność- przykład Problem: Która klasa powinna być odpowiedzialna za utworzenie obiektu typu Payment i powiązanie go z obiektem typu Sale? Zaproponować rozwiązanie w oparciu o zasadę Wysoka spójność model dziedziny (fragment ) Kandydaci: Register Sale

52 Wysoka spójność - przykład Rozwiązanie 1: Klasa Register jest odpowiedzialna za utworzenie obiektu klasy Payment (zastosowano wzorzec Kreator - w świecie rzeczywistym kasa fiskalna rejestruje płatności) Klasa Register odpowiada również za utworzenie powiązania pomiędzy obiektem klasy Sale i obiektem klasy Payment (metoda AddPayment()) Wniosek: Rozwiązanie 1 zwiększa zakres odpowiedzialność klasy Register. W tym konkretnym przypadku jest do zaakceptowania, niemniej może prowadzić do obniżenia spójności klasy Register (duża liczba odpowiedzialności)

53 Wysoka spójność - przykład Rozwiązanie 2 (preferowane): Klasa Register deleguje do klasy Sale utworzenie obiektu klasy Payment Klasa Sale odpowiada za utworzenie obiektu klasy Payment i utworzenie powiązania pomiędzy obiektem klasy Sale i nowo utworzonym obiektem klasy Payment Wniosek: Rozwiązanie 2 nie zwiększa zakresu odpowiedzialności klasy Register. Klasa Register deleguje wykonanie określonych czynności do klasy Sale - rozwiązanie preferowane z punktu widzenia zasady Wysoka spójność

54 Realizacja operacji MakeNewSale() Operacja: MakeNewSale() Warunki początkowe: Istnieje obiekt r klasy Register Warunki końcowe: Utworzono obiekt s klasy Sale Atrybutowi s.datetime przypisano bieżącą datę i czas Utworzono związek pomiędzy obiektem s a obiektem r Kontroler Kreator

55 Realizacja operacji EnterItem() Operacja: EnterItem(itemId, quantity) Warunki początkowe: Istnieje obiekt s klasy Sale oraz obiekt pd klasy ProductDescription Kontroler Warunki końcowe: Utworzono obiekt sli klasy SaleLineItem Atrybutowi sli.quantity przypisano wartość argumentu quantity Utworzono związek pomiędzy obiektem sli a obiektem s Utworzono związek pomiędzy obiektem sli a obiektem pd Kreator Ekspert

56 Realizacja operacji MakePayment() Operacja: MakePayment(amount) Warunki początkowe: Istnieje obiekt s klasy Sale Warunki końcowe: Utworzono obiekt p klasy Payment Atrybutowi p.amounttendered przypisano wartość argumentu amount Utworzono związek pomiędzy obiektem p a obiektem s Kontroler Kreator

57 Realizacja operacji EndSale() Operacja: EndSale() Warunki początkowe: Istnieje obiekt s klasy Sale Warunki końcowe: Atrybutowi s.iscomplete przypisano wartość true Kontroler Ekspert

58 Model projektowy wersja finalna

59 Literatura Craig Larman: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development