Efektywne tworzenie oprogramowania 20082009 Wykorzystanie wzorcw Na podstawie

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

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 2

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

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

Abstraction-Occurrence – Solution (rozwiązanie): «Abstraction» TVSeries * * series. Name producer Title name author isbn publication. Date lib. Of. Congress «Occurrence» Episode number title story. Synopsis * Library. Item bar. Code. Number 5

Abstraction-Occurrence • Antywzorce: 6

Abstraction-Occurrence • Wariant kwadratu Scheduled. Train * liczba data * * Scheduled. Leg rozkład. Czas. Odjazd rozkład. Czas. Przyjazd * początkowa Specific. Train * * Specific. Leg Aktualny. Czas. Odjazd Aktualny. Czas. Przyjazd docelowa Station 7

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 8

General Hierarchy «Node» – Solution: * «podporządkowuje» 0. . 1 «Non. Superior. Node» Employee * «kieruje» «Superior. Node» File. System. Item * 0. . 1 Secretary Technician Manager «zawiera» 0. . 1 File Directory 9

General Hierarchy • Antywzorzec: Recording Video. Recoding Music. Video Audio. Recording Jazz. Recording Classical. Recording Blues. Recording Rock. Recording 10

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

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» «Abstract. Role» «Role 1» «Role 2» 12

Player-Role • Przykład 1: 13

Player-Role • Przykład 2: 14

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 podklasy «Player» . 15

Wzorzec Delegation – Context: • Projektujemy metodę w klasie • Stwierdzamy, że inna klasa ma metodę, która dostarcza pożądaną usługę • Dziedziczenie 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 16

Delegation – Rozwiązanie: «Delegator» delegating. Method Stack push pop is. Empty «Delegate» method Linked. List add. First add. Last add. After remove. First remove. Last delete is. Empty delegating. Method() { delegate. method(); } push() { list. add. First(); } 17

Delegation Przykład: 18

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 specific. Flight. regular. Flight. flight. Number(); return get. Regular. Flight(). flight. Number(); 19

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

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 21

Read-only Interface – Rozwiązanie: «interface» «Read. Only. Interface» * «Unprivileged. Class» * «Mutator» get. Attribute «Mutable» attribute «private» get. Attribute set. Attribute 22

Read-only Interface • Przykład: «interface» Person get. Name Mutableperson first. Name last. Name set. First. Name set. Last. Name get. Name 23

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

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 25