Projektowanie obiektowe oprogramowania Wykład 3 - SOLID GRASP Wiktor Zychla 2016

Transkrypt

1 Projektowanie obiektowe oprogramowania Wykład 3 - SOLID GRASP Wiktor Zychla Taksonomia RDD Projektowanie obiektowe = określanie odpowiedzialności obiektów (klas) i ich relacji względem siebie. Wszystkie dobre praktyki, zasady, wzorce sprowadzają się do tego jak właściwie rozdzielić odpowiedzialność na zbiór obiektów (klas). Odpowiedzialność kontrakt, zobowiązanie, związane z działaniem lub wiedzą. Działanie: Wykonywanie czynności, tworzenie innego obiektu, przeprowadzanie obliczeń Inicjalizacja czynności wykonywanych przez inny obiekt Kontrola, koordynacja czynności wykonywanych przez inny obiekt Wiedza: Udostępnianie danych Wiedza o obiektach powiązanych RDD = Responsibility-Driven Development, przemyślane projektowanie obiektowe. Problem w procesie analizy obiektowej zidentyfikowano już co trzeba zrobić (przypadki użycia, mapy procesów). Na etapie projektowania architektury całych podsystemów jak i konkretnych fragmentów należy zbudować zbiory klas realizujące zidentyfikowane wymagania. Skrajności są oczywiste: system z jedną olbrzymią klasą, w której są wszystkie metody vs system z olbrzymią liczbą klas, z których każda ma jedną metodę Projektując architekturę obiektową poruszamy się między tymi skrajnościami

2 Wzorce aplikacyjne Wzorce projektowe (GoF) SOLID GRASP GRASP bardzo ogólne dobre praktyki rozdzielania odpowiedzialności SOLID zestaw 5 zasad, których nie należy łamać Wzorzec nazwana para (problem, rozwiązanie), którą można powielić w różnych kontekstach, opisana ze wskazówkami stosowania i konsekwencjami użycia. Uwaga większość systemów informatycznych ma wiele warstw w tym: warstwę dostępu do danych za pomocą której aplikacja komunikuje się z repozytoriami danych, np. bazami relacyjnymi warstwę modelu dziedzinowego w której określone są klasy będące wynikiem refaktoryzacji modelu dziedzinowego do modelu klas (patrz poprzedni wykład) warstwę logiki biznesowej gdzie zaimplementowano procesy biznesowe interfejs użytkownika warstwę interfejsu użytkownika Wszystkie składowe warstwy aplikacji nazywa się żargonowo stosem aplikacyjnym. Spośród tych warstw warstwa modelu dziedzinowego jest szczególna jej w najmniejszym stopniu dotyczą reguły projektowania obiektowego (SOLID/wzorce), ponieważ model dziedzinowy opisuje realne byty, ich odpowiedzialności i relacje między nimi. Większość zasad projektowania nie ma więc w tej warstwie nic do gadania, wszak o tym czy mysz zjada ser nie decyduje dobra praktyka, tylko po prostu tak jest. Od tej pory zajmujemy się więc takimi regułami projektowania obiektowego, które mają zastosowanie we wszystkich warstwach stosu aplikacyjnego z wyłączeniem warstwy modelu dziedzinowego. Wyjątkiem są tu reguły GRASP, one są na tyle ogólne że ich świadomość często pomaga w dobrym uchwyceniu subtelności modelu dziedzinowego.

3 2 GRASP General Responsibility Assignment Software Patterns (Principles) 1 Creator 2 Information Expert 3 Controller 4 Low Coupling 5 High Cohesion 6 Polymorphism 7 Indirection 8 Pure fabrication 9 Protected Variations 2.1 Creator Nazwa Creator (Twórca) Problem Kto tworzy instancje klasy A? Rozwiązanie Przydziel zobowiązanie tworzenia instancji klasy A klasie B, jeżeli zachodzi jeden z warunków: B zawiera A lub agreguje A (kompozycja) B zapamiętuje A B bezpośrednio używa A B posiada dane inicjalizacyjne dla A Uwagi: właściwe zarządzanie tworzeniem, niszczeniem i czasem życia obiektów to jedno z podstawowych zadań. Wydawałoby się, że przecież do tworzenia obiektów w językach obiektowych wystarczy operator new, ale w rzeczywistości ma on poważne ograniczenie wiąże klienta z konkretną implementacją. 2.2 Information Expert Nazwa Information Expert Problem Jak przydzielać obiektom zobowiązania? Rozwiązanie Przydziel zobowiązanie ekspertowi tej klasie, która ma informacje konieczne do jego realizacji. Uwagi: ta zasada często pozwala rozstrzygać wątpliwości projektowe typu Gdzie powinna być metoda X? 2.3 Controller Nazwa Controller Problem Który z obiektów poza warstwą GUI odbiera żądania operacji systemowych i kontroluje jej wykonanie? Rozwiązanie Przydziel odpowiedzialność do obiektu spełniającego jeden z warunków: Obiekt reprezentuje cały system Obiekt reprezentuje przypadek użycia w ramach którego wykonywana jest operacja (<NazwaPrzypadku>Handler, <NazwaPrzypadku>Controller) Uwagi: o wzorcach MVC/MVP będziemy mówić na wykładzie. 2.4 Low Coupling Nazwa Low Coupling Problem Jak zmniejszyć liczbę zależności I zasięg zmian, a zwiększyć możliwość ponownego wykorzystania kodu? Rozwiązanie Przydziel odpowiedzialność tak, aby ograniczyć stopień sprzężenia (liczbę

4 Sprzężenie: powiązań obiektu). Stosuj tę zasadę na etapie projektowania. Obiekt A ma atrybut typu B lub typu C związanego z B Obiekt A wywołuje metody obiektu typu B Obiekt A ma metodę związaną z typem B (typ wartości, parametru lub zmienna lokalna) Obiekt A dziedziczy po B Uwagi: istnieją wzorce pozwalające ograniczać liczbę sprzężeń, zauważmy tylko że problem nie występuje dla układu 2 klas, ale tak od 4 wzwyż zaczyna robić się interesująco. 2.5 High Cohesion Nazwa High Cohesion Problem Jak sprawić by obiekty miały jasny cel, były zrozumiałe i łatwe w utrzymaniu? Rozwiązanie Przydziel odpowiedzialność by spójność pozostawała wysoka. Spójnosć = sprzężenie w ramach jednej i tej samej klasy pomiędzy jej składowymi. Klasa o niskiej spójności wykonuje niepowiązane zadania lub ma ich zbyt dużo: Trudno je zrozumieć Trudno je ponownie wykorzystać Trudno je utrzymywać Są podatne na zmiany Uwaga zasady Low Coupling i High Cohesion stosuje się zarówno na poziomie pojedynczych klas jak i całych modułów: Klasa Moduł (*.dll, *.jar) Low Coupling Klasa ma mało zależności do innych klas Moduł ma mało zależności do innych modułów High Cohesion Metody wewnątrz klasy są ze sobą ściśle sprzężone (korzystają z siebie nawzajem) Klasy wewnątrz modułu są ze sobą ściśle sprzężone (korzystają z siebie nawzajem) 2.6 Polymorphism Nazwa Polymorphism Problem Jak obsługiwać warunki zależne od typu? Rozwiązanie Przydziel zobowiązania - przy użyciu operacji polimorficznych typom dla których to zachowanie jest różne Uwagi: wydaje się oczywiste, a jednak wymaga pewnej rutyny. 2.7 Indirection Nazwa Indirection Problem Komu przydzielić zobowiązanie jeśli zależy nam na uniknięciu bezpośredniego powiązania między obiektami? Rozwiązanie Przydzielić zobowiazanie obiektowi, który pośredniczy między innymi komponentami

5 Uwagi: to jest wprost sugestia jaki jest najprostszy sposób unikania sprzężenia. Kilka wzorców projektowych (Mediator, Observer, Event Aggregator) pokazuje jak tę zasadę realizować w praktyce. 2.8 Pure fabrication Nazwa Pure fabrication Problem Jak przydzielić odpowiedzialność by nie naruszyć zasad High Cohesion I Low Coupling a nie odpowiada nam rozwiązanie innych zasad (np. Eksperta)? Rozwiązanie Przypisz zakres odpowiedzialności sztucznej lub pomocniczej klasie, która nie reprezentuje konceptu z dziedziny problemu. Uwagi: innymi słowy wprowadź dodatkową klasę tam gdzie naprawdę nie bardzo wiadomo która istniejąca powinna robić to co trzeba zrobić. 2.9 Protected Variations Nazwa Protected Variations Problem Jak projektować obiekty, by ich zmiennić nie wywierała szkodliwego wpływu na inne elementy? Rozwiązanie Rozpoznaj punkty zmienności o otocz je stabilnym interfejsem. Uwagi: ta zasada zwana jest także Law of Demeter (prawo Demeter). Formułuje się je jako nie rozmawiaj z nieznajomymi. Co ciekawe, nie ma ono żadnego związku z mitologiczną Demeter, a tylko z projektem naukowym prowadzonym na Northeastern University pod koniec lat 90-tych ubiegłego wieku, nazwanym Project Demeter, którego celem było wypracowanie od podstaw dobrych zasad projektowania aspektowego. Więcej tu:

6 3 SOLID S O L I D SRP OCP LSP ISP DIP Single Responsibility Principle Klasa ma tylko jedną odpowiedzialność Open-Closed Principle otwarty na rozszerzenia, zamknięty na modyfikacje Liskov Substitution Principle Każda obiekt klasy w kontekście swojego użycia powinien być zastępowalny przez obiekt klasy potomnej Interface Segregation Principle Klient nie powinien być zmuszany do zależności od metod, których nie używa Dependency Inversion Principle Moduły wyższego poziomu zależą od abstrakcji, nie od implementacji 3.1 SRP, Single Responsibility Principle Żadna klasa nie może być modyfikowana z więcej niż jednego powodu Test odpowiedzialności SRP Naruszenie czasem możliwe do wykrycia za pomocą tzw. testu odpowiedzialności SRP. XXXX sam. XXXX sam. XXXX sam. Analiza SRP klasy XXXX Przykład. Klasa samochód. class SRP Examples Samochód + kieruje() : void + myje() : void + pobieraolej() : void + rusza() : void + sprawdzaolej() : void + zatrzymuje() : void + zmieniaopony(opona[]) : void Test SRP: + Samochód rusza sam. + Samochód zatrzymuje się sam.? Samochód zmienia opony sam.? Samochód kieruje sam. Analiza SRP klasy Samochód

7 ? Samochód myje sam.? Samochód sprawdza olej sam. + Samochód pobiera olej sam. Poprawiony model: class Better SRP Examples Samochód + pobieraolej() : void + rusza() : void + zatrzymuje() : void Kierowca + kieruje(samochód) : void Mechanik + sprawdzaolej(samochód) : void + zmieniaopony(opony[], Samochód) : void Myjnia + myje(samochód) : void Przykład na żywo - Sender 3.2 Open-closed Principle (=Protected Variations) Składniki oprogramowania (klasy, moduły) powinny być otwarte (na rozszerzenia, adaptowalne) i zamknięte (na modyfikacje wpływające na klientów) Typowe sposoby radzenia sobie: uzależnienie od abstrakcji zamiast od konkretnej implementacji. wykorzystanie polimorfizmu Przykład class OCPExamples Client Serv er Poprawiony diagram

8 class Beter OCPExamples Client «interface» Serv erinterface Serv er Przykład na żywo - GUIEditor 3.3 Liskov Substitution Principle = zasada dobrego dziedziczenia Musi istnieć możliwość zastępowania typów bazowych ich podtypami (w kontekście semantycznym, poprawności działania programu, a nie syntaktycznym program się skompilował) Przykład opisowy Załóżmy że mamy funkcję f przyjmującą parametr typu A. Załóżmy też że przekazanie do tej funkcji parametru typu B dziedziczącego z A powoduje błędne działanie f. Mówimy wtedy że B narusza zasadę LSP, B jest wrażliwa na LSP w kontekście f. Projektant funkcji f mógłby w jej implementacji testować argument na bycie B i uzależnić od tego implementację (naprawiając problem naruszenia LSP), ale naruszyłby wtedy OCP. Remedium: taka sytuacja zwykle oznacza, że mamy pozorne dziedziczenie, a tak obiekty nie są zależne relacją dziedziczenia. Być może na przykład są potomkami jednego, tego samego typu bazowego. Zasada: wolno osłabić warunek wejścia (precondition) lub wzmocnić warunek wyjścia (postcondition) w przeciążanych metodach. Wtedy na pewno w podstawianym kontekście da się je zawołać i wyniki będą zgodne z oczekiwaniami. False (najsilniejszy) => x > 5 && y > 1 => y > 1 => y > 1 y < 0 => True (najsłabszy) Warunek wejścia osłabić : Warunek wyjścia wzmocnić: Przykład na żywo Coffee/DecafCoffee Naruszenie zasady wzmocnienia warunku wyjścia.

9 Osłabiliśmy warunek wyjścia ponieważ zwracamy obiekt w którym właściwość ma wartość null mimo że klient się tego nie spodziewa. Kod kliencki przestaje działać Przykład na żywo List/Set Naruszenie zasady osłabienia warunku wejścia. Wzmocniliśmy warunek wejścia ponieważ wymagamy aby nowo dodawany element był różny od wszystkich poprzednio dodanych. Kod kliencki przestaje działać. 3.4 Interface Segregation Principle Klient nie powinien być zmuszany do zależności od metod których nie używa Problem dużych interfejsów: Klasa potrzebuje tylko części funkcjonalności, a musi implementować cały interfejs Zmiana innej części interfejsu wymusza zmianę klasy i wszystkich jej klientów 3.5 Dependency Inversion Principle Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu tylko od abstrakcji. Abstrakcje nie powinny zależeć od szczegółowych rozwiązań. Zależność od szczegółów powoduje małą elastyczność. 4 Inne 4.1 Don t Repeat Yourself (DRY) Zalecenie unikania powtórzeń kodu, odpowiedzialności. 4.2 Law of Demeter (LoD) (Principle of least knowledge) = Protected Variations 4.3 (Don t Make Me Think) DMMT 4.4 (Don t Optimize Prematurely) DOP 4.5 Inne