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

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

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...

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

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”)

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()

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

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!

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

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)

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

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

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

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

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

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

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

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

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

Wzorce projektowe: Observer

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

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

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

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

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

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

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 ...

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

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

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ą

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ę

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/

Q & A ?

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