Organizacja Przedsięwzięć Programistycznych Projektowanie

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

1 Bartosz Walter Bartek.Walter@man.poznan.pl
Organizacja Przedsięwzięć Programistycznych Projektowanie Bartosz Walter

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() Wyszukaj() Wyszukaj() 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 nadklasa ZASADA 2: Asocjacje są elastyczniejsze niż dziedziczenie doAction() doAction() klasa inna klasa

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
kiedy? jak? konsekwencje? wzorzec kontekst? alternatywy? 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
Uczestnicy: 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

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

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

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 Wzorce projektowe: Observer
Uczestnicy: 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

22 Wzorce projektowe: Observer
Konsekwencje użycia: 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 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
Uczestnicy: 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

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

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 PRZED PO

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 Move method Refaktoryzacja 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 Extract class Refaktoryzacja 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 Introduce local extension
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 Change value to reference
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 (

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ć?