Na podstawie książki OOSE, T. C.Lethbridge, R. Laganiere Efektywne tworzenie oprogramowania 2008/2009 Wykorzystanie wzorców.

Prezentacja na temat: "Na podstawie książki OOSE, T. C.Lethbridge, R. Laganiere Efektywne tworzenie oprogramowania 2008/2009 Wykorzystanie wzorców."— Zapis prezentacji:

1 Na podstawie książki OOSE, T. C.Lethbridge, R. Laganiere Efektywne tworzenie oprogramowania 2008/2009 Wykorzystanie wzorców

2 2 Wprowadzenie do wzorców Powtarzające się aspekty projektowania są nazywane wzorcami. –Wzorzec jest opisem rozwiązania (ogólnego problemu) nadającego się do powtórnego wykorzystania w konkretnym kontekście –Wiele z nich jest systematycznie dokumentowanych do wykorzystania przez wszystkich twórców oprogramowania –Dobry wzorzec powinien Być maksymalnie ogólny Zawierać rozwiązanie wypróbowane we wskazanym kontekście

3 3 Opis wzorca Context: Ogólna sytuacja, w której stosuje się wzorzec Problem: 1 lub 2 krótkie zdania wskazujące na główne trudności Forces (siły, czynniki): Zagadnienia, które należy wziąć pod uwagę rozwiązując problem Solution (rozwiązanie): Rekomendowany sposób rozwiązania problem w danym kontekście. —‘aby zrównoważyć siły’ Antipatterns: (opcjonalnie podajemy antywzorce) Rozwiązania, które nie działają w tym kontekście (w innym mogą działać). Related patterns: (wzorce powi ą zane z danym) Wzorce podobne do tego wzorca. References: Kto rozwinął lub zainspirowawał wzorzec.

4 4 Wzorzec Abstraction-Occurrence –Context: Często w modelu dziedziny zauważamy zbiór powiązanych obiektów (occurrences - wystąpień). Elementy takiego zbioru dzielą wspólną informację –Ale równocześnie różnią się od siebie w znaczący sposób. –Problem: Jaki jest najlepszy sposób reprezentacji, w diagramie klas, takie zbioru wystąpień? – Forces: Chcemy reprezentować elementy takiego zbioru wystąpień bez dublowania wspólnej informacji.

5 5 Abstraction-Occurrence –Solution (rozwiązanie): TVSeries seriesName producer Episode number title storySynopsis ****** «Occurrence»«Abstraction» ****** Title name author LibraryItem barCodeNumber ****** isbn publicationDate libOfCongress

6 6 Abstraction-Occurrence Antywzorce:

7 7 Abstraction-Occurrence Wariant kwadratu ScheduledTrain liczba SpecificTrain data ** * * ScheduledLegSpecificLeg AktualnyCzasOdjazd * AktualnyCzasPrzyjazd rozkładCzasOdjazd rozkładCzasPrzyjazd Station początkowa docelowa **

8 8 Wzorzec General Hierarchy –Context: Obiekty w hierarchii obiektów mogą mieć jeden lub więcej obiektów powyżej w hierarchii (nadrzędnych) –i jeden lub więcej obiektów poniżej (podporządkowanych). Pewne obiekty nie mogą mieć żadnych elementów podporządkowanych –Problem: Jak reprezentować hierarchię, w której pewne obiekty nie mogą mieć elementów podporządkowanych? –Forces: Wymagany jest elastyczny sposób reprezentowania hierarchii –który zapobiega temu, aby pewne obiekty miały podporządkowane Wszystkie obiekty mają wiele wspólnych własności i operacji

9 9 General Hierarchy –Solution: «podporządkowuje» * «Node» «SuperiorNode»«NonSuperiorNode» * « kieruje» Manager Employee TechnicianSecretary 0..1 * «zawiera» Directory FileSystemItem File 0..1

10 10 General Hierarchy Antywzorzec: RockRecordingBluesRecordingClassicalRecordingJazzRecordingMusicVideoVideoRecodingAudioRecordingRecording

11 11 Wzorzec Player-Role –Context: rola jest szczególnym zbiorem własności połączonych z obiektem w określonym konkteście. obiekt może odgrywać różne role w różnych kontekstach. –Problem: Jak najlepiej zamodelować graczy i role, tak aby gracz mógł zmienić role lub mieć wiele ról?

12 12 Player-Role –Forces: jest możliwym poprawienie enkapsulacjii przez zebranie informacji związanej z każdą oddzielną rolą w klasie. chcemy zapobiec wielokrotnemu dziedziczeniu. instancja nie może zmienić klasy –Solution: «Player» «Role1»«Role2» «AbstractRole»

13 13 Player-Role Przykład 1:

14 14 Player-Role Przykład 2:

15 15 Player-Role Antywzorce: –Połączenie wszystkich własności i zachowań w pojedynczej klasie «Player» i nie korzystanie w ogóle z klas «Role». –Utworzenie ról jako podklas klasy «Player».

16 16 Wzorzec Delegation –Context: Projektujemy metodę w klasie Stwierdzamy, że inna klasa ma metodę, która dostarcza pożądaną usługę Dziedziczenie nie jest odpowiednie –np., ponieważ nie można zastosować reguły: „..jest.” –Problem: Jak można efektywnie wykorzystać metodę, która już istnieje w innej klasie? –Forces: Chcemy zoptymalizować koszty tworzenia oprogramowania

17 17 Delegation –Rozwiązanie: LinkedList addFirst addLast addAfter removeFirst removeLast delete isEmpty Stack push pop isEmpty «Delegate»«Delegator» delegatingMethod() { delegate.method(); } delegatingMethodmethod push() { list.addFirst(); }

18 18 Delegation Przykład:

19 19 Delegation Antywzorce –Nadużywanie generalizacji i dziedziczenie metody, która ma być powtórnie wykorzystana –Zamiast utworzenia pojedynczej metody w «Delegator», która nie robi nic poza wywołaniem metody w «Delegate występuje wiele różnych metod w «Delegator» wywołujących delegowaną metodę –Dostęp do klas nie sąsiadujących return specificFlight.regularFlight.flightNumber(); return getRegularFlight().flightNumber();

20 20 Wzorzec Immutable –Context: immutable obiekt, to obiekt którego stan nigdy się nie zmienia po utworzeniu –Problem: Jak utworzyć klasę, której instancje są immutable? –Forces: Nie może być „dziur”, które pozwalałyby na ‘nielegalną’ modyfikację obiektu immutable –Solution: Należy upewnić się, że konstruktor klasy, immutable class, jest jedynym miejscem, w którym wartości zmiennych instancyjnych są ustawiane lub modyfikowane. Metody instancyjne nie mogą mieć efektów ubocznych. Jeśli potrzebna jest metoda, która modyfikowałaby zmienną instancyjną, to musi zwrócić nową instancję klasy.

21 21 Wzorzec Read-only Interface –Context: Chcemy czasem, aby szczególne uprzywilejowane klasy mogły modyfikować atrybuty obiektów, które w przeciwnym razie (dla innych) są immutable –Problem: Jak utworzyć sytuację, w której pewne klasy widzą daną klasę, jako tylko do odczytu, podczas gdy inne mogą ją modyfikować? –Forces: Restrykcyjny dostęp przez wykorzystanie słów kluczowych public, protected and private nie jest adekwatny Utworzenie dostępu public powoduje, że będzie publiczna do czytania i pisania

22 22 Read-only Interface –Rozwiązanie: «UnprivilegedClass» ****** «Mutator» «Mutable» attribute «private» getAttribute setAttribute «interface» «ReadOnlyInterface» getAttribute *****

23 23 Read-only Interface Przykład: Mutableperson firstName lastName setFirstName setLastName getName «interface» Person getName

24 24 Read-only Interface Antywzorce: –Utworzenie klasy, read-only class, jako podklasy klasy «Mutable» –Nadpisanie wszystkich metod, które modyfikują własności Tak, że wyrzucają wyjątki

25 25 Materiały z LAN Każdy przynosi na następny wykład: – wydrukowane (tak, aby to było czytelne) zawartości plików (rozwiązań) z: zestawu 3 oraz z zestawu 5 (ew. skorygowanego) lub zestawu 7