: ::Rysunek : ::Figura. Rysuj() *: Rysuj() Uwaga! Modularność (spójność i niezależność składowych) to nie to samo, lecz więcej niż hermetyzacja

Transkrypt

1 Znaczenie projektowania Nie ma trudnych programów, są tylko źle zaprojektowane Jak coś jest trudne, to projektuj tak długo aż stanie się proste Kryteria jakości projektu Modularność Silne (wewnętrznie spójne) składowe (pakiety, komponenty, moduły, klasy, metody/funkcje) Niezależne (luźno powiązane) składowe Przejrzystość Modularność Nazewnictwo Złożoność składowych Modularność Możliwość pracy nad fragmentem programu Mniejsza propagacja zmian/błędów Możliwość ponownego wykorzystania składowych Spójność obiektowa Pola klasy służą do opisu pojedynczego bytu, a metody klasy operują na (wykorzystują, modyfikują) polach tej klasy Brak spójności obiektowej Brak spójności obiektowej

2 Dostęp do danych zwiększa zależność składowych Lepiej orysunek : ::Rysunek : ::Linia Rysuj Pobierz punkty() Rysuj linie() Uwaga! Modularność (spójność i niezależność składowych) to nie to samo, lecz więcej niż hermetyzacja Uniezależnienie klasy Rysunek od konkretnych figur Uniezależnienie klasy Rysunek od figur (mechanizm operacji polimorficznych) : ::Rysunek : ::Figura : Złożoność klasy Suma złożoności metod Miary złożoności metod: Liczba linii kodu Liczba warunków Złożoność cyklomatyczna liczba niezależnych ścieżek w grafie przepływu sterowania programu Cechy złego projektu Sztywność, brak elastyczności Wrażliwość, tendencja do ulegania uszkodzeniom Trudność wykorzystania fragmentów Niedostosowanie do rzeczywistości Nadmierna złożoność Niepotrzebne powtórzenia Nieprzejrzystość Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka 2

3 Zasada pojedynczej odpowiedzialności Żadna klasa nie powinna odpowiadać za dwa różne obszary odpowiedzialności Np. jedna klasa nie powinna służyć do generowania raportu i jego wyświetlania Żadna klasa nie powinna być modyfikowana z więcej niż jednego powodu Np. klasa nie powinna być modyfikowana zarówno po zmianie logiki raportu i jak i po zmianie układu graficznego Metoda CRC cards Class-Responsibility-Collaboration Klasa-Odpowiedzialność-Współpraca Może poprzedzać opracowanie diagramów sekwencji lub samodzielnie wspomagać wprowadzanie metod Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Przykład karty CRC Przykład karty CRC Odpowiedzialność Prostokąt Współpraca Odpowiedzialność Pojazd Współpraca Rysowanie Wzór linii Wzór wypełnienia Obliczanie kosztów Kategoria pojazdu Edycja interaktywna Zaznaczanie się Manipulator prostokąta Sprawdzanie wykonalności zlecenia Kategoria pojazdu Zasada otwarte-zamknięte Składowe oprogramowania powinny być otwarte na rozbudowę, ale zamknięte do modyfikacji Podstawowe mechanizmy abstrakcja i polimorfizm Np. lepsze jest uzależnienie od interfejsu niż klasy Zasada otwarte-zamknięte Nie da się przewidzieć wszystkich zmian Np. co jest niezbędne w intefejsie? Gdy mnie raz oszukasz, powinieneś się wstydzić. Gdy oszukasz mnie drugi raz, to ja powinienem się wstydzić Jeżeli jakieś rozwiązanie raz okazało się zbyt sztywne, należy je od razu zmienić Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka 3

4 Zasada podstawienia Musi istnieć możliwość zastąpienia klasy bazowej klasą pochodną Zasada odwracania zależności Naiwne rozwiązanie Czy kwadrat jest specjalizacją prostokąta? Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Lepiej Zasad zależności od abstrakcji Żadna zmienna nie powinna zawierać referencji do konkretnej klasy Żadna klasa nie powinna dziedziczyć po konkretnej klasie Żadna metoda nie powinna przykrywać metody zaimplementowanej w którejkolwiek z klas bazowych Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Zasada segregacji interfejsów Należy eliminować (rozdzielać) grube, nieporęczne interfejsy Zadania w fazie projektowania Uszczegółowienie wyników analizy Projektowanie technicznych składowych oprogramowania - innych niż składowa dziedziny problemu Poprawa efektywności systemu Określenie fizycznej struktury systemu Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka 4

5 Uszczegółowienie wyników analizy Opracowanie diagramów sekwencji Wprowadzenie związków skierowanych Określenie sposobu implementacji związków Dobór typów danych Opracowanie nagłówków operacji Opracowanie algorytmów metod Opracowanie diagramów sekwencji Wprowadzenie związków skierowanych Opiekun Pracownik Kolo naukowe Opiekun Pracownik Kolo naukowe Wprowadzenie związków skierowanych Czynniki brane pod uwagę Ograniczanie zależności składowych - modularność Zasada ograniczonego dostępu Nadmiarowość danych w przypadku związków nieskierowanych (obustronnie nawigowalnych) Efektywność Potrzeba dostępu do pól i metod powiązanych obiektów Określenie sposobu implementacji związków Wybór spośród omówionych wcześniej możliwości Najlepszym podejściem jest przyjęcie standardu dla projektu/firmy Dobór typów danych Typy danych dla: Pól Parametrów Metod Wybór typu spełniającego wymagania (np. zakres, dokładność, liczba możliwych wartości) określonych na etapie analizy Jeżeli żaden z typów standardowych i bibliotecznych nie spełnia naszych wymagań to definiowanie własnych typów: Złożonych Obiektowych (klas) inne wykorzystanie programowania obiektowego! 5

6 Opracowanie nagłówków operacji Zamiana danych wejściowych i wyjściowych na parametry i wyniki o odpowiednich typach Np. operacja obliczania kosztu przewozu Dane wejściowe Czas, Droga Dany wyjściowe Koszt przewozu double Koszt (double Czas, double Droga) lub Koszt (double Czas, double Droga, double &Koszt) Opracowanie algorytmów metod ~90% metod to metody algorytmicznie proste Algorytmy ~0% metod maja istotnie znaczenie dla systemu (np. efektywność, przejrzystość) Projektowanie technicznych składowych oprogramowania Składowa interfejsu użytkownika Składowa zarządzania pamięcią Składowa zarządzania danymi Składowa dziedziny problemu Składowa komunikacji sieciowej Składowa zarządzania zadaniami Projektowanie technicznych składowych W ogólności składowe techniczne mogą być projektowane tak, jak składowa dziedziny problemu Rzeczywistość -> Model -> Projekt W praktyce (choć nie zawsze) projektowanie tych składowych ma charakter powtarzalny, wykorzystujemy więc: Gotowe biblioteki Generatory kodu Wzorce projektowe Składowa interfejsu użytkownika Zasady projektowania IU Spójność Skróty dla doświadczonych użytkowników Potwierdzanie przyjęcia polecenia użytkownika Prosta obsługa błędów Odwoływanie akcji Wrażenie kontroli nad systemem Przestrzeganie zasady 7±2 Nieobciążanie pamięci krótkotrwałej Grupowanie powiązanych operacji Komunikaty o błędach: Jakie są efekty błędu Co użytkownik może zrobić Badania usability Grono nowych (nieskażonych) użytkowników Zadania do wykonania Informacje o problemach, niekoniecznie o rozwiązaniach Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka 6

7 Analiza zadań Np. badanie liczby operacji (np. kliknięć) potrzebnych do wykonania zadania Projektowanie składowej zarządzania danymi Dokumenty vs. na bieżąco wybierane dane Bazy danych - pliki Tabela/plik na klasę - wszystkie obiekty w jednym pliku/tabeli Odczyt/zapis na bieżąco - na żądanie Projektowanie baz danych - normalizacja, indeksy Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Problem dziedziczenia Propagacja pól w dół Adres firmowy Miasto Nazwa firmy Poznań ABC S.A. Kielce XYX z o.o. Adres osobisty Miasto Nazwisko Warszawa Jan Kowalski Wólka Zenon Nowak Propagacja pól w górę Adres Typ adresu Miasto Nazwa firmynazwisko Osobisty Warszawa Jan Kowalski Firmowy Kielce XYX z o.o. Firmowy Poznań ABC S.A. Osobisty Wólka Zenon Nowak Transformacja do zwykłego związku Adres firmowy Id adresu Nazwa firmy ABC S.A. 2 XYX z o.o. Adres osobisty Id adresu Adres Id adresu Nazwisko 3 Jan Kowalski 4 Zenon Nowak Miasto Poznań 2 Kielce 3 Warszawa 4 Wólka 7

8 Narzędzia Np. Hibernate, JPOX Transparentne mapowanie pomiędzy modelem obiektowym a relacyjnym Współpraca z większością RDBMS Sposoby implementacji składowej komunikacji sieciowej Funkcje niskopoziomowe CORBA (Common Object Request Broker Architecture) XML-RPC SOAP (Simple Object Access Protocol) Języki specyfikacji IDL, WSDL Określenie fizycznej struktury systemu Rozmieszczanie klas w modułach Podział na programy wykonywalne Projektowanie systemów rozproszonych Klient Serwer Architektura klient-serwer Cienki klient Interfejs użytkownika S. dziedziny problemu Gruby klient Interfejs użytkownika S. dziedziny problemu S. zarządzania danymi S. zarządzania danymi Architektura trójwarstwowa Warstwa prezentacji Warstwa aplikacji Interfejs użytkownika S. dziedziny problemu Poprawa efektywności systemu Kompromis pomiędzy efektywnością a jakością projektu Poprawa efektywności na poziomie programistycznym i projektowym Dobór struktur danych Dobór algorytmów Warstwa danych S. zarządzania danymi 8

9 Pierwsze prawo Jaszkiewicza ;-) Każdy nietrywialny algorytm można przyśpieszyć dwukrotnie choć kolejne iteracje są coraz trudniejsze Pytanie tylko czy warto? Kiedy nie warto przyśpieszać efektywności Kiedy algorytm nie jest wąskim gardłem Np. znajduje się w potoku przetwarzania gdzie inne kroki są dużo bardziej czasochłonne Jest wywoływany jednorazowo na żądanie użytkownika, a czas jest pomijany z punktu widzenia szybkości interakcji Rola profilingu Optymalizacja efektywności bez wcześniejszych pomiarów, to SABOTAŻ ;-) wobec pracodawcy Typowe sposoby poprawy efektywność Przechowywanie danych pośrednich Indeksowanie Obliczenia/przetwarzanie przyrostowe Efektywne obcinanie niepotrzebnych gałęzi w drzewie przeszukiwań Stosowanie heurystyk Wzorce projektowe związane z efektywnością Proxy, Flyweight Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Hermetyzacja a kompresja danych Np. obiekt opisywany przez wiele atrybutów boolowskich i wartości wyliczeniowych o niewielkim zakresie, może wewnętrznie brzydko kompresować te dane wykorzystując poszczególne bity Na zewnątrz widziane są poszczególne pola poprzez metody Set i Get Grupowanie (clustering) 9

10 Algorytm heurystyczny K zadana liczba grup Wybierz losowo K elementów i potraktuj je jako K jednoelementowych grup Powtarzaj Dla każdego niezgrupowanego elementu Oceń przydział tego elementu do każdej grupy Wykonaj przydział o najlepszej ocenie Dopóki istnieją niezgrupowane elementy Ocena grupowania Średnia odległość elementów zgrupowanych razem / średnia odległość elementów zgrupowanych w różnych grupach Kryterium minimalizowane Złożoność obliczania miary oceny N liczba zgrupowanych elementów (N + ) N / 2 Złożoność obliczania zmiany miary oceny Wystarczy obliczyć odległości rozważanego elementu od każdego elementu zgrupowanego N Poprawa efektywności (N + ) / 2 Przykład lokalne przeszukiwanie z zakazem powrotu do poprzednich rozwiązań Problem komiwojażera 00 miast Zapamiętanie jednego rozwiązania 00 B 00 milionów rozwiązań ~0 GB Duży czas weryfikacji czy nowe rozwiązanie znajduje się na liście uprzednio wygenerowanych rozwiązań. Oryginalny program 0

11 Ekstrakcja metody Powiadom Ekstrakcja interfejsu Obserwator GPS Modyfikacja w programie dodanie kolejnego czujnika GPS Ekstrakcja generalizacji Czujnik GPS Wzorce projektowe Wzorzec Observer/Listener Prawie każdy problem, także projektowy, nad którym się zastanawiasz, ktoś już rozwiązał Wzorce (patterns) zawierają dobre praktyki Antywzorce przykłady złych praktyk Wzorce mogą też przyśpieszać komunikację

12 Inne zastosowanie wzorca Listener/Observer Cechy (zalety) wzorca Observer Możliwość wielu sposobów obsługi powiadomień Przedmiot (subject) może nie znać (liczby) swoich obserwatorów Łatwość dodawania nowych przedmiotów i obserwatorów Możliwość dynamicznego łączenia przedmiotów i obserwatorów Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Przechowywanie pojedynczej wielkości Jak przechować pojedynczą wielkość? double IloscPaliwa; Problem: W jakiej jednostce przechowywane jest to pole? Litry, hektolitry, metry sześcienne, mililitry, tony? Wzorzec Quantity Quantity Amount Unit Concrete quantity Wzorzec Quantity - przykład Wielkosc Ilosc Jednostka Lub np. pole typu Wielkosc Wzorzec Quantity - cechy Informacja o jednostce jest zawsze przechowywana wraz z ilością Ilosc paliwa 2

13 Współpracujące klasy Wzorzec Client-Server Klasa Klasa 2 Client Np.: Server np.: : ::Klasa : ::Klasa 2 : ::Client : ::Server Przykład wzorca Client- Server Wzorzec Abstract server Client Client interface «interface class» Okno raportu Raport Server Okno raportu Interfejs okna raportu Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Raport Wzorzec Client-Server - cechy Zmiany klienta nie wymuszają zmian serwera Np. zmiany w klasie interfejsowej nie wymuszają zmian w klasie należącej do dziedziny problemu Serwer pełni rolę pasywną Częściowo można to obejść korzystając np. z wzorca Observer/Listener Wzorzec Client-Server dla pakietów klas Flota Optymalizacja Pojazd Rozwiazanie Typ pojazdu Wolny pojazd Trasa.. Populacja 3

14 Uniezależnienie interfejsu użytkownika od części obliczeniowej programu Model, view, controler Interfejs uzytkownika symlulatora Symulator View Controler Okno widoku symulacji Osobnik Gatunek Okno parametrów Okno statystyk Organ Model Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Wzorzec Facade Wzorzec Facade - cechy Interfejs uzytkownika symlulatora Okno widoku symulacji Okno parametrów Okno statystyk Symulator Symulator Osobnik Gatunek Organ Zmiany w pakiecie serwera nie wymuszają zmian klientów o ile fasada pozostaje taka sama Klasy wyłącznie delegujące swoje zadania (jak fasada) są często traktowane jako niepożądane Facade Niezależność współpracujących klas We wzorcu client-server klient jest zależny od serwera Jest to szczególnie niekorzystne, jeżeli współpraca z serwerem jest tylko niewielką częścią funkcjonalności serwera Jak tego uniknąć? Wzorzec Mediator Collegue Mediator Collegue 2 : ::Mediator : ::Collegue : ::Collegue 2 4

15 Przykład wzorca Mediator Wzorzec Mediator - cechy Modul harmonogramowania Modul CASE Interfejs harmonogramowania Interfejs CASE Integrator (mediator) Pozwala na współpracę klas (pakietów, modułów) całkowicie od siebie niezależnych Role aktywną pełni mediator Częściowo można to obejść korzystając np. z wzorca Observer/Listener Kosztowne obiekty Rysunek Figura Wzorzec Proxy Client Subject Request() Real subject 0.. Proxy Uchwyt pliku := Wczytaj z sieci (Adres pliku) Plik graficzny Adres pliku Uchwyt pliku Plik graficzny() Wczytaj z sieci() Request() Request() if (rreal subject = NULL) rreal subject := new Real subject; rreal subject.request (...) Przykład wzorca Proxy Rysunek Plik graficzny Adres pliku Uchwyt pliku Plik graficzny() Wczytaj z sieci() 0.. Figura Proxy pliku graficznego Adres pliku if (Plik graficzny = NULL) rplik graficzny := new Plik graficzny (Adres pliku); rplik graficzny.rysuj(...) Wzorzec Proxy - cechy Kosztowny obiekt jest konstruowany tylko wtedy jeżeli będą na nim wykonywane jakieś operacje Opóźnione konstruowanie kosztownego obiektu jest niewidoczne dla klienta Wiele obiektów klasy Proxy może być powiązanych z jednym kosztownym obietem (np. w połączeniu z wzorcem Singleton) 5

16 Rysunek Niespójne klasy Figura Wzorzec Adapter/Wrapper Client Target Rysuj(in Okno : Okno) Request() Operation() Linia Prostakat Adaptee Adapter Library Rysuj(in Okno : Okno) Rysuj(in Okno : Okno) Operation() Graphic file Draw(in pdc : CDC) Realizacja z wykorzystanie Adaptee Library Przykład wzorca Adapter Rysunek Linia Rysuj(in Okno : Okno) Figura Rysuj(in Okno : Okno) Plik graficzny Rysuj(in Okno : Okno) Prostakat Rysuj(in Okno : Okno) Wzorzec Adapter - cechy Adaptowana klasa może być wykorzystywana tak jak inne klasy implementujące standardowy interfejs Fakt korzystania z niestandardowej klasy jest niewidoczny dla klienta Graphic file Draw(in pdc : CDC) rgraphic file.draw (Onko.pDC) Potrzeba wielopoziomowej hierarchii agregacji Przykład: Rysunek składa się z figur Figury mogą tworzyć grupy W skład grupy może wchodzić inna grupa figur Pewne operacja można wykonywać zarówno na pojedynczych figurach, jak i grupach figur. Client Request() Wzorzec Composite Leaf Operation() Component Operation() Composite Operation() For each rcomponent rcomponent.operation 0.. 6

17 Przykład wzorca Composite Rysunek Linia Przesun() Przesun() Figura Przesun() Prostakat Grupa Przesun() 0.. Wzorzec Composite - cechy Hierarchia zawierania się może być dowolnie zgłębiona Liście mogą się pojawiać na dowolnym poziomie hierarchii obok grup (dowolnego poziomu) Jak tego uniknąć? For each rfigura rfigura.przesun (...) Jak oddzielić konstrukcję złożonego obiektu od jego reprezentacji Np. zapis danych programu graficznego w różnych formatach Director +Construct() Wzorzec Builder Builder +Build part() Concrete builder Product +Build part() Przykład wzorca builder Grafika Zapisywacz w XML Zapisz linie() Zapisz prostakat() Zapisz grupe() Zapisywacz Zapisz linie() Zapisz prostakat() Zapisz grupe() Zapisywacz w JPG Zapisz linie() Zapisz prostakat() Zapisz grupe() Wzorzec Builder Reżyser (director)) zna tylko ogólną strukturę budowanego obiektu Budowniczy (builder)) zna tylko elementarne kroki budowy obiektu w zadany sposób Strumien XML Rysunek JPG 7

18 Polecenia Jak zapewnić: Możliwość stosowania różnych sposobów wydawania poleceń Niezależność pomiędzy obiektem wysyłającym polecenie i odbiorcą Wzorzec Command Sender.. Command Execute() Receiver Concrete command Execute() Przykład wzorca Command Menu Pasek narzedziowy Powieksz Wykonaj() Polecenie Wykonaj() Pomniejsz Wykonaj() Rysunek Powieksz() Pomniejsz() Wzorzec Command cechy Nadawca jest niezależny od odbiorcy i vice versa To samo polecenie może być wydawane przez różnych nadawców Łączenie poleceń z nadawcami może być dynamiczne rrysunek.powieksz (...) rrysunek.pomniejsz (...) Różna reakcja na zdarzenia w zależności od stanu Zadanie Zdefiniowane Zaplanowane Zwolnij zasob() Zrealizowane Realizowane Typowa implementacja void CZadanie::Zwolnij_zasob (TZasobID Zasob) { if (State == _ZDEFNIOWANE) {... } else if (State == _ZAPLANOWANE) {... } else if (State == _REALIZOWANE) {... } else if (State == _ZREALIZOWANE) {... } } 8

19 Wzorzec State Przykład wzorca State Context Request() State Handle() rstan zadania.obsluz (...) Zadanie Zwolnij zasob() Stan zadania Obsluz() rstate.handle (...) Concrete state Handle() Concrete state 2 Handle() Zdefiniowane Obsluz() Zaplanowane Obsluz() Realizowane Obsluz() Zrealizowane Obsluz() Wzorzec State - cechy Łatwiejsze dodawanie/usuwanie stanów Konieczne konstruowanie/usuwanie/wiązanie obiektów przy zmianie stanów Trudniejsze dodawanie/usuwanie metod (trzeba je dodawać/usuwać w różnych stanach) Schemat algorytmu ewolucyjnego Znajdź populację początkową powtarzaj Selekcja Rekombinacja Mutacja dopóki nie są spełnione warunki stopu Antywzorzec Call super Algorytm ewolucyjny Główna pętla() Populacja poczatkowa() Selekcja() Rekombinacja() Mutacja() Warunek stopu() Populacja poczatkowa (...) powtarzaj Selekcja (...) Rekombinacja (...) Mutacja (...) dopoki nie Warunek stopu (...) Wzorzec Template method Abstract class Template method() Operation() Operation2()... Operation (...)... Operation2 (...)... Konkretny algorytm ewolucyjny Populacja poczatkowa() Selekcja() Rekombinacja() Mutacja() Warunek stopu() Wykonaj() Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka super.pętla główna() Concrete class Operation() Operation2() 9

20 Przykład wzorca Template method Algorytm ewolucyjny Wykonaj() Populacja poczatkowa() Selekcja() Rekombinacja() Mutacja() Warunek stopu() Populacja poczatkowa (...) powtarzaj Selekcja (...) Rekombinacja (...) Mutacja (...) dopoki nie Warunek stopu (...) Wzorzec Template method - cechy Ponownie wykorzystywany jest szkielet algorytmu przy możliwości zmiany poszczególnych kroków Konkretny algorytm ewolucyjny Populacja poczatkowa() Selekcja() Rekombinacja() Mutacja() Warunek stopu() Alternatywnie wzorzec Strategy Ogólny algorytm ewolucyjny +Pętla główna() Algorytm ewolucyjny Populacja poczatkowa() Selekcja() Rekombinacja() Mutacja() Warunek stopu() Grupowanie podobnych operacji Gdzie umieścić operacje tego samego typu dotyczące grupy klas? Algorytm ewolucyjny.populacja poczatkowa (...) powtarzaj Algorytm ewolucyjny.selekcja (...) Algorytm ewolucyjny.rekombinacja (...) Algorytm ewolucyjny.mutacja (...) dopoki nie Algorytm ewolucyjny.warunek stopu (...) Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Konkretny algorytm ewolucyjny Populacja poczatkowa() Selekcja() Rekombinacja() Mutacja() Warunek stopu() Klasyczne rozwiązanie Przykład wzorca Visitor Rysunek Figura c Figura Gosc Odwiedz linie(in Linia : Linia) Odwiedz grupe(in Grupa : Grupa) Zapisz() Zapisz() Zapisz() Zaakceptuj(in Gosc : Gosc) ZapisXML Linia Zapisz() Grupa Zapisz() 0.. Linia Zaakceptuj(in Gosc : Gosc) Pobierz dane() Grupa Zaakceptuj(in Gosc : Gosc) Pobierz dane() Odwiedz linie(in Linia : Linia) 0.. Odwiedz grupe(in Grupa : Grupa) 20

21 Wzorzec Visitor - cechy Grupuje operacje danego typu, np. kod składowej zarządzania danymi Korzystne np. przy zmianach technologii składowych technicznych Jak rozszerzyć działanie zbioru klas bez zmiany ich kodu? Np. jak w programie graficznym dodać do każdej figury i grupy figur możliwość wyświetlania nazwy? Rysunek + Rozwiązanie klasyczne - dziedziczenie Nazwa Figura Rysuj nazwe() Wzorzec Decorator Client 0.. Operation() Concrete component Component Decorator Operation() 0.. Linia Grupa 0.. Additional behaviour rcomponenet.operation (...) Additional behaviour Concrete decorator Operation() Przykład wzorca Decorator Rysunek 0.. Figura Figura z nazwa Nazwa 0.. Wzorzec Decorator - cechy Zachowanie każdego komponentu może zostać rozszerzone Rozszerzenia są niewidoczne dla klienta Linia Grupa 0.. rfigura.rysuj (...) Rysuj nazwe 2

22 Tworzenie obiektów Wzorzec Factory method Rysunek 0.. Linia Figura Prostakat Czy rysunek musi znać wszystkie manipulatory? Product 0.. Creator Factory method() Operation()... rproduct := Factory method (...) Concrete product Concrete creator Factory method() return new Concrete product Manipulator linii Manipulator prostakata Przykład wzorca Factory method 0.. Manipulator Rysunek 0.. Linia #Skonstruuj manipulator() Figura +Manipuluj() #Skonstruuj manipulator() Prostakat #Skonstruuj manipulator() Wzorzec Factory method - cechy Klient nie musi znać konkretnych klas, których obiekty są konstruowane Manipulator linii Manipulator prostakata Efektywność a model obiektowy Wzorzec Flyweight Bezpośrednia implementacja modelu obiektowego może być bardzo nieefektywna w stosunku np. do zapisu tych danych w tablicy Wiele obiektów danej klasy Czy zrezygnować z rozwiązania obiektowego? 22

23 Przykład wzorca FlyWeight Mapa Segmenty +PobierzNastepny() : Segment 0.. Segment Dane segmentów Wzorzec FlyWeight method - cechy Na zewnątrz widziany jest model obiektowy Wewnętrzna reprezentacja nie musi być obiektowa i prze to może być bardziej efektywna +UstawID(in ID) Tablica danych opisujących wszystkie segmenty Wzorzec Singleton zapewnianie istnienia tylko jednej instancji klasy Singleton #Unique instance +Instance() #Singleton() if (Unique instance == NULL) Unique instance = new Singleton (...) return Unique instance Wzorzec Singleton w C++ class CSingleton { protected: static CSingleton UniqueInstance; CSingleton () {... } public: static CSingleton Instance () { if (UniqueInstance == NULL) UniqueInstance = new CSingleton; return UniqueInstance; } }; CSingleton CSingleton::UniqueInstance = NULL;... CSingleton Singleton = CSingleton::Instance (); Wzorzec Singleton w Javie public class Singleton { static protected Singleton uniqueinstance = null; protected Singleton() {... } static public Singleton getinstance() { if(uniqueinstance == null) { uniqueinstance = new Singleton(); } return uniqueinstance; } }... Singleton singleton = Singleton.getInstance(); API Application Programming Interface 23

24 Co to jest API? Interfejs programowania aplikacji, interfejs programu użytkownika specyfikacja procedur, funkcji lub interfejsów umożliwiających komunikację z biblioteką, systemem operacyjnym lub innym systemem zewnętrznym w stosunku do aplikacji korzystającej z API (WIKIPEDIA) Cechy API API a modularność API a ponowne wykorzystanie Bardzo trudne do zmiany Potencjalnie ogromna wartość Możliwość innej implementacji Nie wiadomo jak będzie wykorzystywane Przykłady Windows API Microsoft.NET Java 2 Platform Standard Edition Java J2ME MIDP Google Maps API Facebook API... Dobre API Łatwe w nauce Łatwe w użyciu (nawet bez dokumentacji) Trudne w niepoprawnym użyciu Kod używający API powinien być łatwy w czytaniu i utrzymaniu Wystarczająco mocne Łatwe w rozszerzaniu Odpowiednie dla odbiorcy Zbierz wymagania z dozą sceptycyzmu Często otrzymasz propozycje rozwiązań, a nie wymagania Wybierz prawdziwe wymagania Scenariusze Łatwiejsze i bardziej wartościowe może być opracowanie czegoś bardziej ogólnego! Projektowanie API Zacznij od prostej/krótkiej specyfikacji Konsultuj, prototypuj Pisz kod dla swojego API Prototypowanie Przykłady Testy jednostkowe Bądź realistą Nie zaspokoisz wszystkich potrzeb Na pewno będą błędy API będzie musiało ewoluować 24

25 Zasady projektowania API Klasy funkcje do konkretnych rzeczy Jeżeli metoda, klasa, pakiet nie daje się prosto nazwać to coś jest nie tak W razie potrzeb dziel na mniejsze jednostki Tak małe jak trzeba, ale nie bardziej API musi spełniać wymagania Łatwo rozszerzyć, bardzo trudno coś usunąć Zasady projektowania API Implementacja nie powinna wpływać na API np. wewnętrzne typy Ograniczaj dostęp Klasy, pola, metody tak prywatne jak to możliwe Niezależne moduły Nazwy mają znaczenie Bez skrótów Standardy nazewnictwa Samodokumentujący się kod Zasady projektowania API Dokumentacja ma znaczenie Opisz każdą klasę, interfejs, metodę, konstruktor, parametr, wyjątek Klasa do czego służą obiekty (instancje) Metoda jej kontrakt warunki początkowe, końcowe, efekty uboczne Stany Zasady projektowania API Wpływ na efektywność Np. zwracanie typów obiektowych może oznaczać miliony niepotrzebnych alokacji/dealokacji Naśladuj standardy Nie utrudniaj życia użytkownikom API final, operacje niepolimorficzne Zasady projektowania API Stosuj dziedziczenie tylko, jeżeli ma to sens Properties extends Hashtable TextField extends Item Zaprojektuj i udokumentuj dziedziczenie lub je zablokuj Specjalizacja może być zależna od implementacji generalizacji Podejście konserwatywne wszystkie konkretne klasy finalne Zasady projektowania API Rzucaj wyjątki natychmiast po wystąpieniu błędu Ostrożnie stosuj przeciążanie Dobór typów (np. parametry, wartości funkcji) Interfejsy jako parametry wejściowe (zamiast klas) Najbardziej specyficzny typ Nie używaj stringów, jeżeli istnieje lepszy typ Unikaj typów zmiennopozycyjnych, jeżeli niezbędne stosuj typ standardowy o największej precyzji 25

26 Zasady projektowania API Stosuj standardy dotyczące kolejności parametrów Szczególnie jeżeli więcej parametrów tego samego typu Unikaj długich list parametrów Raczej nie więcej niż 3 Szczególnie niekorzystne wiele parametrów tego samego typu Jak unikać: Rozbicie metody Pomocnicze klasy Refaktoryzacja kodu Seria niewielkich modyfikacji kodu,, z których każda zmienia (poprawia) wewnętrzną strukturę programu bez zmiany jego zewnętrznego działania Do pewnego! stopnia zastępuje szczegółowe projektowanie poprzedzające implementację i pozwala na poprawę błędów projektowych Dwie drogi uzyskania dobrze zaprojektowanego oprogramowania Dobry projekt -> kod -> niewielka refaktoryzacja [Wstępny projekt] -> kod -> poważna refaktoryzacja Dlaczego refaktoryzacja Poprawa projektu Utrzymanie kodu przy życiu, ułatwienie wprowadzania zmian, umożliwienie ponownego wykorzystania Poprawa czytelności Kod dla ludzi nie dla kompilatora Zrozumienie cudzego kodu Ułatwienie wyszukiwania błędów Np. refaktoryzacja przy debugowaniu Refaktoryzacja ma przyspieszać pracę Kiedy refaktoryzować kod Kiedy istnieje potrzeba dodania/zmiany funkcjonalności i okazuje się to trudne Poprawa czytelności kodu Ułatwienie zmian Kiedy trudno znaleźć/zlokalizować błędy Poprawa czytelności kodu Przed przeglądem kodu Złe zapachy (bad smells) ) w kodzie Powielany kod Długie metody i złożone klasy Długie listy parametrów Metody odwołujące się głównie do innych klas Powtarzające się grupy danych (Praktycznie) nie używany kod Delegowanie, nic nie wnoszące generalizacje 26

27 Złe zapachy (bad smells) ) w kodzie Zmienne chwilowe Zastępowanie wyrażeniami i metodami Łańcuchy wywołań Np. foo.getbar(). ().getfoo().getthis().getthat().dosomet hing(); Nieodpowiednie, nadmierne powiązania klas Komentarze?!?! // Dochód podstaw przychód koszt D = P K; Jak weryfikować brak zmian zewnętrznego działania Testowanie Analiza formalna i nieformalna Unikanie dużych zmian Procedury proste kroki Refaktoryzacja a rozszerzanie/modyfikowanie funkcjonalności Dodanie/ zmiana możliwości systemu Nowe testy Cel - przejście testów Brak zmian w funkcjonalności Nie dodaje nowych testów? (Może je zmieniać) Testy jako weryfikacja zmian Stosunek przełożonych do refaktoryzacji Jeżeli nie jest akceptowana przez przełożonych (z braku zrozumienia), to... stosuj refaktoryzację Rób to, co według Twojej zawodowej wiedzy przynosi dobre efekty Przykłady refaktoryzacji Dodanie parametru Ekstrakcja metody Ekstrakcja klasy Przesuń pole Przesuń metodę Zamień dziedziczenie na związek klas Ukryj pole/metodę Procedura przesuwania metody Zadeklaruj metodę w klasie docelowej Przekopiuj kod metody Dodaj związek od klasy źródłowej do docelowej Zmień metodę źródłową na delegującą Skompiluj i przetestuj Znajdź miejsca wywołania metody Zmień na wywołania nowej metody Usuń metodę źródłową Skompiluj i przetestuj 27