Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Projektowanie Bartosz Walter Organizacja Przedsięwzięć Programistycznych.

Podobne prezentacje


Prezentacja na temat: "Projektowanie Bartosz Walter Organizacja Przedsięwzięć Programistycznych."— Zapis prezentacji:

1 Projektowanie Bartosz Walter Organizacja Przedsięwzięć Programistycznych

2 Agenda Czym się różni model od projektu? Parę pojęć z zakresu obiektowości Wzorce projektowe Refaktoryzacja Standard kodowania i dokumentowania kodu

3 Czym się różni model od obiektu? Biblioteka zawiera egzemplarze książek i czasopism. Każdy tytuł może posiadać wiele egzemplarzy, identyfikowanych przez karty egzemplarzy. Tytuły są umieszczone w katalogach: rzeczowym, autorskim i alfabetycznym...

4 Czym się różni model od obiektu? 1. Ile istnieje obiektów reprezentujących jeden egzemplarz? 2. Jak są zorganizowane katalogi? 3. Czy egzemplarze (karty egzemplarzy) są usuwane? 4. Czy może się zdarzyć, że egzemplarz występuje tylko w jednym katalogu? 5. Jak zapewnić, że istnieje tylko jedna instancja danego egzemplarza (lub wszystkie będą zsynchronizowane)? 6. Czy karta czytelnicza znika przy braku zdarzeń z nią związanych?

5 Parę pojęć z zakresu obiektowości Operacja – pojedynczy komunikat, który może zostać wysłany do obiektu pewnego typu Sygnatura operacji – nazwa, parametry, wartość zwracana Wyszukaj(Dziady)

6 Parę pojęć z zakresu obiektowości Interfejs – zbiór wszystkich sygnatur operacji akceptowanych przez klasę; Klasa – jednostka oprogramowania, posiadająca jeden lub więcej interfejsów, zawiera implementację metod Wyszukaj()

7 Parę pojęć z zakresu obiektowości Typ – konkretny interfejs; deklaruje operacje, które posiada klasa; klasa może mieć wiele typów Podtyp – typ posiadający operacje typu bazowego

8 Parę pojęć z zakresu obiektowości Dziedziczenie klas - służy do współdzielenia kodu i rozszerzania możliwości klasy Interface inheritance - pozwala na użycie polimorfizmu (czyli zamienianie obiektów) ZASADA 1: Należy programować pod kątem interfejsu, nie klasy!

9 Parę pojęć z zakresu obiektowości Dziedziczenie relacja niezmienna, zapisana przy kompilacji odkrywa szczegóły implementacyjne nadklasy Asocjacja relacja ustalana w trakcie wykonania każda klasa może wykonywać jedno zadanie klasa nadklasa inna klasa doAction() ZASADA 2: Asocjacje są elastyczniejsze niż dziedziczenie

10 Wzorce projektowe "The pattern describes a problem, which occurs over and over again in our environment, and the describes the core of the solution to that problem, in such a way, that you can use the solution a million times over, without ever doing it the same way twice" Christopher Alexander (architekt)

11 Wzorce projektowe: wzorzec wzorca wzorzec kiedy? jak? konsekwencje? alternatywy?kontekst? war. wstępne?

12 Wzorce projektowe: jak wybrać właściwy? Przejrzyj cele wzorców i znajdź pasujące Sprawdź, jak znalezione wzorce oddziałują na siebie Przejrzyj wzorce realizujące podobne cele Jak wzorzec rozwiązuje dany problem? Czy zmiana projektu jest uzasadniona? Zastanów się, co powinno pozostać zmienne w projekcie

13 Design patterns: hints for pattern application look at Applicability & Consequences study Structure, Participants & Collaborations compare sample code to yours choose appropriate names for participants define participants define domain-specific names for operations implement the operations

14 Wzorce projektowe: Adapter Zmienia interfejs klasy na inny, którego oczekuje klient Pozwala współpracować klasom, które normalnie nie mogłyby tego robić z powodu niezgodnych interfejsów

15 Wzorce projektowe: Adapter Target definiuje interfejs znany i akceptowany przez klasę Client Client współpracuje z obiektami zgodnymi z interfejsem Target Adaptee definiuje istniejący interfejs, który wymaga adaptacji Adapter adaptuje interfejs Adaptee do potrzeb interfejsu Target Uczestnicy:

16 Wzorce projektowe: Adapter niewielka elastyczność adaptacji podlega tylko dana klasa, a jej podklasy - nie potencjalna zmiana zachowania Adapter może zmienić zachowanie klasy Adaptee dwustronne interfejsy Adapter Adaptacja istniejącej biblioteki do potrzeb systemu Konsekwencje użycia: Przykład:

17 Wzorce projektowe: Singleton Zapewnia, że klasa ma tylko jedną instancję w całej aplikacji Udostępnia punkt dostępu do tej instancji

18 Wzorce projektowe: Singleton Singleton definiuje operację getInstance(), która pozwala na dostęp do instancji klasy może tworzyć swoją własną instancję Uczestnicy: kontrolowany dostęp do jedynej instancji ograniczenie użycia zmiennych globalnych pozwala na tworzenie podklas klasy Singleton pozwala ograniczać liczbę istniejących instancji Konsekwencje użycia:

19 Wzorce projektowe: Observer Definiuje relację obiektów 1:N tak, aby wybrany obiekt mógł powiadamiać inne o zmianie swojego stanu

20 Wzorce projektowe: Observer

21 Subject posiada referencje do obiektów Observer dostarcza funkcji dołączania i odłączania obiektów Observer Observer definiuje metodę aktualizującą Concrete Subject wysyła powiadomienia obiektom Observer Concrete Observer utrzymuje referencję do Concrete Subject aktualizuje swój stan razem z klasą Subject Uczestnicy:

22 Wzorce projektowe: Observer abstrakcyjne powiązanie pomiędzy Subject i klasami Observer modele pull i push push : Observer otrzymuje pełną informację o zmianach pull : Observer otrzymuje tylko powiadomienie, prosi Subject o dane Konsekwencje użycia: Przykłady użycia: obsługa zdarzeń synchronizacja modelu z widokiem

23 Wzorce projektowe: Bridge Deleguje implementację do innych klas Pozwala uniknąć statycznego powiązania abstrakcji z implementacją Interfejsy abstrakcji i implementacji mogą być różne Wygodny zamiennik dla dziedziczenia

24 Wzorce projektowe: Bridge Abstraction definiuje abstrakcyjny interfejs utrzymuje referencję do klasy Implementor RefinedAbstraction rozszerza interfejs Abstraction Implementor definiuje interfejs implementacji może być różny od Abstraction ConcreteImplementor implementuje interfejs Implementor Uczestnicy:

25 Wzorce projektowe: Bridge abstrakcja i implementacja zostają rozdzielone abstrakcja i implementacja mogą być niezależnie rozszerzane szczegóły implementacji są ukryte przed klientami Konsekwencje użycia:

26 Refaktoryzacja Refaktoryzacja - zmiana dokonywana w wewnętrznej strukturze oprogramowania, która ułatwia jego zrozumienie i implementację nowych funkcji refaktoryzacja nie zmienia obserwowanego zachowania oprogramowania refaktoryzacja PRZEDPO

27 Refaktoryzacja: kiedy warto? Kiedy kod cuchnie? jest zduplikowany... metody są długie... klasy są duże... metody mają długie listy parametrów... instrukcje warunkowe są skomplikowane...

28 Refaktoryzacja Move method Problem Metoda jest bardziej używana przez inną klasę Cel Przeniesienie jej do klasy, która jej używa Sposób zadeklaruj metodę w nowej klasie skopiuj jej zawartość do nowej klasy skompiluj nową klasę ustaw w pierwotnej klasie delegację do nowej klasy skompiluj i przetestuj zastanów się, czy zostawić metodę w starej klasie

29 Refaktoryzacja Extract class Problem Jedna klasa spełnia dwie funkcje Cel Podzielić klasę na dwie, przenosząc odp. pola i metody Sposób utwów nową klasę utwów asocjację między nową i starą klasą przenies pola, skompiluj i przetestuj przenies metody, skompiluj i przetestuj przejrzyj i ew. zmniejsz interfejs klas zdecyduj, czy nowa klasa powinna być dostępna przez referencję, czy jako obiekt niezmienny

30 Refaktoryzacja Introduce local extension Problem Klasa, której nie można zmienić, potrzebuje nowych metod Cel Utworzyć nową klasę z tymi metodami i uczynić ją mostkiem do oryginalnej klasy Sposób Utwórz nową klasę jako podklasę lub mostek Dodaj do nowej klasy konstruktor konwertujący Dodaj do nowej klasy nowe metody Zastąp oryginalną klasę nową

31 Refaktoryzacja Change value to reference Problem Istnieje wiele równych instancji tej samej klasy Cel Zmienić obiekt w obiekt dostępny przez referencję Sposób Zastąp konstruktor metodą tworzącą skompiluj i przetestuj zdecyduj, który obiekt jest punktem dostępowym zdecyduj, które obiekty są tworzone wcześniej, a które w locie zmień metodę tworzącą tak, aby zwracała referencję

32 Literatura, informacje K. Beck Extreme Programming explained. Embrace change S. Ambler Agile Modeling. Effective practices for XP... E. Gamma et al. Design Patterns. Elements of reusable object-oriented soft. M. Fowler et contributors Alpha List of Refactorings (http://www.refactoring.org/

33 Q & A

34 Ocena wykładu 1. Wrażenie ogólne (1 - 6) 2. Za szybko czy za wolno? 3. Czy dowiedziałeś się czegoś ważnego? 4. Co i jak poprawić?


Pobierz ppt "Projektowanie Bartosz Walter Organizacja Przedsięwzięć Programistycznych."

Podobne prezentacje


Reklamy Google