Wykład 5. Inżynieria oprogramowania MIS s MIO s MIS n Listopad 2014

Transkrypt

1 Wykład 5 Inżynieria oprogramowania MIS s MIO s MIS n Listopad 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 5.1

2 Agenda

3 Co to jest G.R.A.S.P.? C. Larman: Applying UML and Patterns A Methodical Approach to Basic OO Design. The principles or patterns are a learning aid to help you understand essential object design and apply design reasoning in a methodical, rational, explainable way. C. Larman: Applying UML and Patterns Metodyczne podejście do podstaw projektowania obiektowego.. Zasady/wzorce sa pomoca w zrozumieniu istoty projektowania obiektowego i stosowania go w metodyczny, racjonalny i zrozumiały sposób". 5.3

4 Co to sa wzorce projektowe? Wzorzec projektowy uniwersalne, sprawdzone w praktyce rozwiazanie często pojawiajacych się, powtarzalnych problemów projektowych. Pokazuje powiazania i zależności pomiędzy klasami oraz obiektami i ułatwia tworzenie, modyfikację oraz pielęgnację kodu źródłowego. Jest opisem rozwiazania, a nie jego implementacja. Wzorce projektowe stosowane sa w projektach wykorzystujacych programowanie obiektowe. 5.4

5 G.R.A.S.P. General Responsibility Assignment Software Patterns (or Principles) 1 Controller 2 Creator 3 High Cohesion 4 Indirection 5 Information Expert 6 Low Coupling 7 Polymorphism 8 Protected Variations 9 Pure Fabrication 5.5

6 G.R.A.S.P. Ogólne zasady przydzielania odpowiedzialności w oprogramowaniu. 1 Kontroler 2 Twórca 3 Wysoka spójność 4 Pośrednictwo 5 Expert 6 Mało powiazań 7 Polimorfizm 8 Chroniona zmienność 9 Czyste wytwarzanie Nazwy nie s a najważniejsze: najważniejszy jest sens tych zasad. 5.6

7 1. Controller Kontroler Problem który obiekt (za interfejsem użytkownika) powinien obsłużyć (przejać) operację (np.: zewnętrzna) systemu? Rozwiazanie Powinna to być klasa, która: opisuje system jako całość reprezentuje główny obiekt lub urzadzenie na którym system działa albo reprezentuje przypadek użycia, w którym występuje dana operacja Opis podstawowa zasada dotycz aca oddzielenia interfejsu od logiki aplikacji. Jest realizowana w wielu wzorcach min.: Model-Widok-Kontroler 5.7

8 2. Creator Twórca Problem która klasa ma być odpowiedzialna za tworzenie obiektów klasy A? Rozwiazanie Klasa B jest odpowiedzialna za tworzenie A, gdy: klasa B komponuje lub agreguje ( ma ) obiekty klasy A B zapisuje/rejestruje/nadzoruje instancje klasy A B współpracuje (blisko!) z A B ma dane potrzebne do inicjalizacji A (patrz: Ekspert) Opis praktycznie każdy program obiektowy musi tworzyć obiekty; właściwe zorganizowanie i przypisanie które obiekty tworza jakie inne obiekty pozwala znaczaco zredukować ilość powiazań między klasami. 5.8

9 3. High Cohesion Wysoka spójność Problem jak w praktyce zachować klasę skupiona na jednej odpowiedzialności, z przejrzysta implementacja, zwiększyć szanse ponownego użycia? Rozwiazanie gdy masz wybór, przypisuj odpowiedzialność tak, by klasa była skupiona na jednym zadaniu Opis Złamanie tej zasady to anty-wzorzec projektowy "Blob": ma miejsce wtedy, gdy w programie istnieje wiele klas, ale bardzo niewiele z nich (lub jedna) ma dominujace znaczenie i zawiera się w niej prawie cała istotna funkcjonalność. Takie klasy nazywamy często (negatywnie) super-klasa, klasa-bóstwo, boss-klasa etc. W szczególności NIGDY nie należy mieszać w jednej klasie logiki aplikacji (co aplikacja naprawdę robi) z dostępem do danych (skad bierze dane) podobno za to idzie się do programistycznego piekła ;) 5.9

10 4. Indirection Pośrednictwo Problem jak unikać zależności od klas dostarczajacych funkcjonalność w specyficzny sposób? jak przerywać zbyt mocne zależności między klasami? jak korzystać z innych klas/pakietów/usług bez dostosowywania się do nich? Rozwiazanie należy stworzyć nowy pośredni obiekt, służacy jako kanał komunikacji, tak by obiekty nie kontaktowały się bezpośrednio Opis aby obniżyć ilość zależności między klasami można umieścić między nimi klasę, przez która będa się komunikować. Zmniejsza się też ogólna ilość powiazań (zachowanie Low Coupling), bo jedna klasa warstwy pośredniej może odpowiadać paru klasom warstwy pierwotnej. Przykładem sa wzorce projektowe typu: Most, Fasada, Adapter. 5.10

11 5. Information Expert Expert Problem której klasie przypisać dana odpowiedzialność (zadanie)? Rozwiazanie tej, która posiada najwięcej informacji niezbędnych do tego, by to zadanie wykonać Opis Pochopne podejmowanie decyzji może spowodować, że klasa aby wykonać zadanie będzie musiała przedostać się przez spory graf obiektów, aby uzyskać odpowiednie informacje. y Expert pozwala oddelegować odpowiedzialność do podmiotu, który na wstępie jest najlepiej przygotowany do jej podjęcie (stad: Ekspert - w sensie najlepszy spośród wszystkich kandydatów ). 5.11

12 6. Low Coupling Mało powiazań Problem jak utrzymać obiekty w niezależności od siebie? Rozwiazanie tak przypisuj odpowiedzialności do obiektów, by liczba powiazań była jak najmniejsza Opis Klasa, która ma dużo powiazań, jest zależna od wielu innych klas, co powoduje: 1 wiele lokalnych zmian spowodowanych zmianami w klasach powiazanych; 2 klasy trudniejsze do zrozumienia w izolacji; 3 zmniejszony reuse (możliwość ponownego wykorzystania), ponieważ najczęściej trzeba jednocześnie wykorzystać część klas powiazanych; Klasa która ma za dużo powiazań prawdopodobnie jest przeciażona obowiazkami, co implikuje złamanie zasady High Cohesion. 5.12

13 7. Polymorphism Polimorfizm Problem jak przypisać odpowiedzialność, która może być realizowana na kilka sposobów? Rozwiazanie przypisz odpowiedzialność do hierarchii obiektów wykorzystujac polimorfizm wbudowany w języki obiektowe Opis mechanizm polimorfizmu, pozwala automatycznie decydować o tym co się stanie w czasie działania programu na podstawie informacji jaki rodzaj obiektu został przekazany 5.13

14 8. Protected Variations Chroniona zmienność Problem jak projektować system, by umożliwić wprowadzanie zmiany, tak by nie wymuszała ona zmian na innych obiektach? Rozwiazanie zidentyfikuj punkty przewidywanego zróżnicowania/niestabilności i przypisz odpowiedzialność do stabilnego interfejsu, a nie konkretnych klas. Opis chodzi o to, by wymiana klasy A na klasę B oferujac a podobna funkcjonalność była jak najprostsza. Ta fundamentalna zasada implikuje enkapsulację, polimorfizm, data-driven desig, a nawet pliki konfiguracyjne! 5.14

15 9. Pure Fabrication Czyste wytwarzanie Problem jaki obiekt powinien otrzymać odpowiedzialność, gdy nie chcemy złamać High Cohesion i Low Coupling, a proponowany Ekspert jest (z innych przyczyn) nie do przyjęcia? Rozwiazanie należy sztucznie wytworzyć nowa czysta klasę (niezwiazan a z problemem) i jej przypisać tę odpowiedzialność Opis Ta zasada często jest używana jako złoty środek pozwalajacy utrzymać inne zasady, gdy te stoja w sprzeczności. Ponadto pomaga ona uwolnić się od dziedziny problemu i rozwiazać go czysto informatycznie. Przykłady: wzorce Singleton, Factory. 5.15

16 Jak ważne sa zasady? Pick your battles! zasady nie sa bezwzględne trzeba dażyć do najszerszego ich spełniania często trzeba wybrać jedna ponad druga trzeba rozumieć kontekst w jakim się je stosuje Jeżeli się pomyliłeś -> refaktoruj! projektowanie to proces iteracyjny różne diagramy pozwalaj a zobaczyć różne aspekty systemu 5.16