Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00186 008698 10442864 na godz. na dobę w sumie
Projektowanie zorientowane obiektowo. Wzorce projektowe. Wydanie II - książka
Projektowanie zorientowane obiektowo. Wzorce projektowe. Wydanie II - książka
Autor: , Liczba stron: 368
Wydawca: Helion Język publikacji: polski
ISBN: 83-7361-782-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> wzorce projektowe
Porównaj ceny (książka, ebook, audiobook).

Zmień podejście do programowania - zastosuj wzorce projektowe

Wzorce projektowe to modele rozwiązań wielu zagadnień programistycznych, oparte na zasadach programowania obiektowego. Zastosowanie ich w projektach informatycznych zapewnia szybszą i bardziej efektywną pracę zarówno podczas projektowania i tworzenia oprogramowania, jak i na etapie jego wdrożenia. Sprawne korzystanie z wzorców projektowych wiąże się jednak z koniecznością poznania metod modelowania obiektowego, zrozumienia zasad obiektowości i umiejętności podzielenia projektowanego systemu na komponenty.

Książka 'Programowanie zorientowane obiektowo. Wzorce projektowe. Wydanie drugie' to przewodnik po wzorcach projektowych, przedstawiający je od strony najbardziej istotnej dla programisty - od strony praktycznej. Przykłady w języku Java, diagramy UML i wyczerpujące komentarze - wszystko to sprawia, że po przeczytaniu tej ksiażki staniesz się ekspertem w dziedzinie wzorców projektowych i będziesz wykorzystywać je we wszystkich swoich projektach.

Korzystając z wzorców projektowych, zwiększysz szybkość i efektywność swojej pracy nad aplikacjami.

O autorach:
Alan Shalloway pracuje w branży informatycznej od ponad 20 lat, często występuje na konferencjach, takich jak SD Expo, Java One, OOP czy też OOPSLA. [więcej...\

James R. Trott w trakcie swojej 20-letniej kariery programisty i projektanta wielokrotnie korzystał z technik analizy obiektowej i wzorców projektowych. [więcej...\

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Projektowanie zorientowane obiektowo. Wzorce projektowe. Wydanie II Autorzy: Alan Shalloway, James R. Trott T³umaczenie: Piotr Rajca ISBN: 83-7361-782-5 Tytu³ orygina³u: Design Patterns Explained A New Perspective on Object-Oriented Design, 2nd Edition Format: B5, stron: 368 Zmieñ podejġcie do programowania — zastosuj wzorce projektowe • Skorzystaj z metod modelowania obiektowego w jêzyku UML • Poznaj ró¿ne typy wzorców projektowych • Wykorzystaj wzorce projektowe w swoich programach Wzorce projektowe to modele rozwi¹zañ wielu zagadnieñ programistycznych, oparte na zasadach programowania obiektowego. Zastosowanie ich w projektach informatycznych zapewnia szybsz¹ i bardziej efektywn¹ pracê zarówno podczas projektowania i tworzenia oprogramowania, jak i na etapie jego wdro¿enia. Sprawne korzystanie z wzorców projektowych wi¹¿e siê jednak z koniecznoġci¹ poznania metod modelowania obiektowego, zrozumienia zasad obiektowoġci i umiejêtnoġci podzielenia projektowanego systemu na komponenty. Ksi¹¿ka „Programowanie zorientowane obiektowo. Wzorce projektowe. Wydanie drugie” to przewodnik po wzorcach projektowych, przedstawiaj¹cy je od strony najbardziej istotnej dla programisty — od strony praktycznej. Przyk³ady w jêzyku Java, diagramy UML i wyczerpuj¹ce komentarze — wszystko to sprawia, ¿e po przeczytaniu tej ksia¿ki staniesz siê ekspertem w dziedzinie wzorców projektowych i bêdziesz wykorzystywaæ je we wszystkich swoich projektach. • Zasady obiektowoġci • Modelowanie obiektowe w jêzyku UML • Standardowe rozwi¹zania obiektowe • Wprowadzenie do wzorców projektowych • Zasady stosowania wzorców projektowych • Katalog wzorców projektowych • Projektowanie i programowanie z zastosowaniem wzorców projektowych Korzystaj¹c z wzorców projektowych, zwiêkszysz szybkoġæ i efektywnoġæ swojej pracy nad aplikacjami. Spis treści Wstęp ...................................................z.......................................... 11 Od obiektowości poprzez wzorce projektowe do prawdziwej obiektowości ................. 13 Od sztucznej inteligencji poprzez wzorce aż do prawdziwej obiektowości..................... 17 Informacje o konwencjach zastosowanych w niniejszej książce ..................................... 19 Nowości dodane w drugim wydaniu książki ...................................................w................ 21 Część I Wprowadzenie do programowania obiektowego ...............23 Rozdział 1. Obiektowość ...................................................z................................ 25 Przegląd...................................................w...................................................w................. .... 25 Zanim pojawiły się obiekty: dekompozycja funkcjonalna............................................... 26 Problem określenia wymagań...................................................w....................................... 27 Zmiany wymagań a dekompozycja funkcjonalna...................................................w......... 29 Postępowanie w sytuacji zmieniających się wymagań ...................................................w. 31 Obiektowość...................................................w...................................................w..............34 Programowanie obiektowe w praktyce...................................................w......................... 40 Szczególne rodzaje metod ...................................................w............................................ 42 Podsumowanie ...................................................w...................................................w.......... 43 Pytania kontrolne...................................................w...................................................w....... 44 Rozdział 2. Język UML ...................................................z.................................... 47 .... 47 Przegląd...................................................w...................................................w................. Czym jest język UML?...................................................w................................................. 47 Zastosowanie języka UML...................................................w........................................... 48 Diagram klas ...................................................w...................................................w.............49 Diagramy interakcji ...................................................w...................................................w... 54 Podsumowanie ...................................................w...................................................w.......... 57 Pytania kontrolne...................................................w...................................................w....... 57 Część II Ograniczenia tradycyjnie pojmowanego projektowania obiektowego ............................................59 Rozdział 3. Problem wymagający rozwiązania uniwersalnego............................... 61 .... 61 Przegląd...................................................w...................................................w................. Pozyskanie informacji z systemu CAD/CAM ...................................................w.............. 61 Terminologia dziedziny zastosowań...................................................w............................. 62 6 Projektowanie zorientowane obiektowo. Wzorce projektowe Opis problemu ...................................................w...................................................w........... 64 Prawdziwe wyzwania i rozwiązania ...................................................w............................. 65 Podsumowanie ...................................................w...................................................w.......... 68 Pytania kontrolne...................................................w...................................................w....... 69 Rozdział 4. Standardowe rozwiązanie obiektowe................................................. 71 .... 71 Przegląd...................................................w...................................................w................. Rozwiązanie wykorzystujące specjalizację ...................................................w.................. 71 Podsumowanie ...................................................w...................................................w.......... 78 Pytania kontrolne...................................................w...................................................w....... 79 Część III Wzorce projektowe...................................................r......81 Rozdział 5. Wprowadzenie do wzorców projektowych.......................................... 83 Przegląd...................................................w...................................................w................. .... 83 Wzorce projektowe wywodzą się z architektury i antropologii....................................... 84 Wzorce projektowe — od architektury do programowania ............................................. 86 Po co studiować wzorce projektowe?...................................................w........................... 89 Inne zalety studiowania wzorców projektowych ...................................................w.......... 93 Podsumowanie ...................................................w...................................................w.......... 94 Pytania kontrolne...................................................w...................................................w....... 95 Rozdział 6. Wzorzec fasady...................................................z............................. 97 .... 97 Przegląd...................................................w...................................................w................. Wprowadzenie do fasady ...................................................w............................................. 97 Fasada...................................................w...................................................w................... Praktyczne uwagi na temat zastosowania fasady...................................................w........ 100 Zastosowanie fasady w rozwiązaniu problemu CAD/CAM .......................................... 101 Podsumowanie ...................................................w...................................................w........ 101 Pytania kontrolne...................................................w...................................................w..... 102 ..... 98 Rozdział 7. Wzorzec adaptera ...................................................z....................... 105 .. 105 Przegląd...................................................w...................................................w................. Wprowadzenie do wzorca adaptera ...................................................w............................ 105 Adapter...................................................w...................................................w.................. Praktyczne uwagi na temat zastosowania adaptera...................................................w..... 111 Zastosowanie adaptera w celu rozwiązania problemu CAD/CAM................................ 113 Podsumowanie ...................................................w...................................................w........ 113 Pytania kontrolne...................................................w...................................................w..... 114 .. 106 Rozdział 8. Poszerzamy horyzonty ...................................................z................. 115 .. 115 Przegląd...................................................w...................................................w................. Obiekty — w rozumieniu tradycyjnym i nowym ...................................................w....... 116 Hermetyzacja — w rozumieniu tradycyjnym i nowym ................................................. 118 Określ zmienność i hermetyzuj ją ...................................................w.............................. 121 Analiza wspólności i zmienności a klasy abstrakcyjne.................................................. 124 Cechy programowania inteligentnego ...................................................w........................ 127 Podsumowanie ...................................................w...................................................w........ 131 Pytania kontrolne...................................................w...................................................w..... 131 Rozdział 9. Wzorzec strategii ...................................................z........................ 133 Omówienie ...................................................w...................................................w.............. 133 Sposób obsługi nowych wymagań ...................................................w............................. 133 Studium problemu — międzynarodowy system do handlu elektronicznego: początkowe wymagania ...................................................w........................................... 136 Spis treści 7 Obsługa nowych wymagań...................................................w......................................... 136 Wzorzec strategii...................................................w...................................................w..... 144 Praktyczne uwagi na temat stosowania wzorca strategii ............................................... 146 Podsumowanie ...................................................w...................................................w........ 147 Pytania kontrolne...................................................w...................................................w..... 148 Rozdział 10. Wzorzec mostu ...................................................z........................... 149 .. 149 Przegląd...................................................w...................................................w................. Wprowadzenie do wzorca mostu...................................................w................................ 149 Przykład problemu wymagającego zastosowania mostu.............................................. 150 Obserwacja dotycząca zastosowań wzorców projektowych .......................................... 159 Wyprowadzenie wzorca mostu...................................................w................................... 160 Wzorzec mostu — retrospekcja...................................................w.................................. 167 Praktyczne uwagi na temat zastosowań mostu ...................................................w........... 167 Podsumowanie ...................................................w...................................................w........ 171 Pytania kontrolne...................................................w...................................................w..... 173 Rozdział 11. Wzorzec fabryki abstrakcyjnej ...................................................z..... 175 .. 175 Przegląd...................................................w...................................................w................. Wprowadzenie do wzorca fabryki abstrakcyjnej ...................................................w........ 175 Fabryka abstrakcyjna — przykład zastosowania ...................................................w........ 176 Implementacja wzorca fabryki abstrakcyjnej ...................................................w............. 182 Praktyczne uwagi na temat stosowania fabryki abstrakcyjnej ....................................... 187 Zastosowanie fabryki abstrakcyjnej w rozwiązaniu problemu CAD/CAM................... 190 Podsumowanie ...................................................w...................................................w........ 190 Pytania kontrolne...................................................w...................................................w..... 190 Część IV Projektowanie z wykorzystaniem wzorców.....................193 Rozdział 12. W jaki sposób projektują eksperci? ................................................ 195 .. 195 Przegląd...................................................w...................................................w................. Tworzenie przez dodawanie wyróżnień ...................................................w..................... 195 Podsumowanie ...................................................w...................................................w........ 201 Pytania kontrolne...................................................w...................................................w..... 202 Rozdział 13. Rozwiązanie problemu CAD/CAM z wykorzystaniem wzorców projektowych ...................................................z................ 203 Przegląd...................................................w...................................................w................. .. 203 Przypomnienie problemu CAD/CAM ...................................................w........................ 204 Projektowanie z wykorzystaniem wzorców...................................................w................ 205 Projektowanie z wykorzystaniem wzorców — etap 1 ...................................................w 206 Projektowanie z wykorzystaniem wzorców — etap 2a ................................................. 207 Projektowanie z wykorzystaniem wzorców — etap 2b ................................................. 210 Projektowanie z wykorzystaniem wzorców — etap 2c ................................................. 214 Projektowanie z wykorzystaniem wzorców — powtórzone etapy 2a i 2b (fasada) ..... 214 Projektowanie z wykorzystaniem wzorców — etapy 2a i 2b (adapter) ......................... 215 Projektowanie z wykorzystaniem wzorców — etapy 2a i 2b (fabryka abstrakcyjna).... 216 Projektowanie z wykorzystaniem wzorców — etap 3 ...................................................w 216 Porównanie z poprzednimi wersjami rozwiązania...................................................w...... 217 Podsumowanie ...................................................w...................................................w........ 218 Pytania kontrolne...................................................w...................................................w..... 219 8 Projektowanie zorientowane obiektowo. Wzorce projektowe Część V Zdążając w kierunku nowego sposobu projektowania ....221 Rozdział 14. Zasady i strategie projektowania z wykorzystaniem wzorców .......... 223 .. 223 Przegląd...................................................w...................................................w................. Zasada otwarcia i zamknięcia...................................................w..................................... 224 Zasada projektowania w kontekście ...................................................w........................... 225 Zasada hermetyzacji zmienności ...................................................w................................ 229 Klasy abstrakcyjne a interfejsy...................................................w................................... 230 Zasada zdrowego sceptycyzmu ...................................................w.................................. 232 Podsumowanie ...................................................w...................................................w........ 232 Pytania kontrolne...................................................w...................................................w..... 233 Rozdział 15. Analiza wspólności i zmienności ...................................................z.. 235 Przegląd...................................................w...................................................w................. .. 235 Analiza wspólności i zmienności a projektowanie aplikacji.......................................... 235 Rozwiązanie problemu CAD/CAM przy wykorzystaniu analizy wspólności i zmienności . 236 Podsumowanie ...................................................w...................................................w........ 242 Pytania kontrolne...................................................w...................................................w..... 242 Rozdział 16. Macierz analizy ...................................................z........................... 243 .. 243 Przegląd...................................................w...................................................w................. Zmienność w świecie rzeczywistym...................................................w........................... 243 Studium zmienności: międzynarodowy system handlu elektronicznego....................... 244 Uwagi praktyczne...................................................w...................................................w.... 251 Podsumowanie ...................................................w...................................................w........ 255 Pytania kontrolne...................................................w...................................................w..... 255 Rozdział 17. Wzorzec dekoratora ...................................................z.................... 257 .. 257 Przegląd...................................................w...................................................w................. Nowe szczegóły...................................................w...................................................w....... 257 Wzorzec dekoratora...................................................w...................................................w. 259 Zastosowanie dekoratora w omawianym studium problemu......................................... 260 Inne zastosowania: operacje wejścia i (lub) wyjścia...................................................w... 263 Praktyczne uwagi na temat stosowania dekoratora...................................................w..... 265 Istota wzorca dekoratora...................................................w............................................. 265 Podsumowanie ...................................................w...................................................w........ 267 Pytania kontrolne...................................................w...................................................w..... 268 Część VI Inne zalety wzorców ...................................................r..269 Rozdział 18. Wzorzec obserwatora ...................................................z.................. 271 .. 271 Przegląd...................................................w...................................................w................. Kategorie wzorców...................................................w...................................................w.. 271 Nowe wymagania aplikacji wspomagającej handel elektroniczny ................................ 273 Wzorzec obserwatora ...................................................w................................................. 274 Zastosowanie wzorca obserwatora ...................................................w............................. 274 Praktyczne uwagi na temat zastosowania obserwatora.................................................. 279 Podsumowanie ...................................................w...................................................w........ 281 Pytania kontrolne...................................................w...................................................w..... 281 Rozdział 19. Wzorzec metody szablonu ...................................................z........... 283 .. 283 Przegląd...................................................w...................................................w................. Nowe wymagania ...................................................w...................................................w.... 283 Wzorzec metody szablonu...................................................w.......................................... 284 Zastosowanie wzorca metody szablonu...................................................w...................... 284 Spis treści 9 Zastosowanie wzorca metody szablonu do redukcji nadmiarowości............................. 286 Praktyczne uwagi na temat zastosowania szablonu metody .......................................... 291 Podsumowanie ...................................................w...................................................w........ 292 Pytania kontrolne...................................................w...................................................w..... 293 Część VII Fabryki ...................................................r.....................295 Rozdział 20. Wnioski płynące ze stosowania wzorców projektowych — fabryki.... 297 .. 297 .. 297 Przegląd...................................................w...................................................w................. Fabryki ...................................................w...................................................w.................. Uniwersalny kontekst raz jeszcze...................................................w............................... 299 Fabryki działają zgodnie z wytycznymi ...................................................w..................... 301 Ograniczanie wektorów zmian ...................................................w................................... 302 Inny sposób rozumienia...................................................w.............................................. 303 Różne zastosowania fabryk ...................................................w........................................ 303 Praktyczne uwagi dotyczące fabryk ...................................................w........................... 304 Podsumowanie ...................................................w...................................................w........ 304 Pytania kontrolne...................................................w...................................................w..... 305 Rozdział 21. Wzorzec singletonu oraz wzorzec blokowania dwufazowego ............. 307 .. 307 Przegląd...................................................w...................................................w................. Wprowadzenie do wzorca singletonu ...................................................w......................... 308 Zastosowanie wzorca singletonu ...................................................w................................ 308 Wariant: wzorzec blokowania dwufazowego ...................................................w............. 310 Reflekcje ...................................................w...................................................w................ . 314 Praktyczne uwagi na temat zastosowania singletonu i blokowania dwufazowego ........... 314 Podsumowanie ...................................................w...................................................w........ 315 Pytania kontrolne...................................................w...................................................w..... 315 Rozdział 22. Wzorzec puli obiektów ...................................................z................ 317 .. 317 Przegląd...................................................w...................................................w................. Problem wymagający zarządzania obiektami ...................................................w............. 318 Wzorzec puli obiektów...................................................w............................................... 325 Obserwacje: tworzenie obiektów nie jest jedynym możliwym zastosowaniem fabryk . 325 Podsumowanie ...................................................w...................................................w........ 327 Pytania kontrolne...................................................w...................................................w..... 328 Rozdział 23. Wzorzec metody fabryki ...................................................z.............. 329 .. 329 Przegląd...................................................w...................................................w................. Nowe wymaganie ...................................................w...................................................w.... 329 Wzorzec metody fabryki ...................................................w............................................ 330 Wzorzec metody fabryki a obiektowe języki programowania....................................... 331 Praktyczne uwagi dotyczące zastosowania wzorca metody fabryki .............................. 331 Podsumowanie ...................................................w...................................................w........ 332 Pytania kontrolne...................................................w...................................................w..... 333 Rozdział 24. Fabryki — podsumowanie ...................................................z........... 335 .. 335 Przegląd...................................................w...................................................w................. Etapy procesu tworzenia oprogramowania ...................................................w............... 335 Podobieństwa fabryk i zasad programowania ekstremalnego........................................ 336 Skalowanie ...................................................w...................................................w.............. 337 10 Projektowanie zorientowane obiektowo. Wzorce projektowe Część VIII Podsumowanie...................................................r..........339 Rozdział 25. Wzorce projektowe i nowa perspektywa projektowania obiektowego ... 341 .. 341 Przegląd ...................................................w...................................................w................. Podsumowanie zasad obiektowości...................................................w............................ 342 Hermetyzacja implementacji za pomocą wzorców projektowych ................................. 343 Analiza wspólności i zmienności a wzorce projektowe................................................. 343 Dekompozycja dziedziny problemu poprzez określenie odpowiedzialności ................. 344 Wzorce i projektowanie w kontekście ...................................................w........................ 345 Powiązania wewnątrz wzorców...................................................w.................................. 346 Wzorce projektowe i praktyki programowania inteligentnego ...................................... 347 Uwagi praktyczne...................................................w...................................................w.... 347 Podsumowanie ...................................................w...................................................w........ 348 Pytania kontrolne...................................................w...................................................w..... 348 Rozdział 26. Bibliografia ...................................................z................................. 351 Programowanie zorientowane obiektowo: strony WWW.............................................. 351 Zalecana lektura ...................................................w...................................................w...... 352 Lektura przeznaczona dla programistów korzystających z języka Java ........................ 353 Lektura przeznaczona dla programistów korzystających z języka C++ ........................ 354 Lektura przeznaczona dla programistów korzystających z języka COBOL .................. 355 Lektura dotycząca metodyki programowania ekstremalnego .......................................... 355 Zalecana lektura dotycząca programowania ...................................................w............... 356 Ulubiona lektura autorów ...................................................w........................................... 356 Dodatki ...................................................r....................................359 Skorowidz...................................................z................................... 361 Rozdział 8. Poszerzamy horyzonty Przegląd W rozdziale W poprzednich rozdziałach omówiłem trzy podstawowe koncepcje, na których opiera się projektowanie obiektowe: obiekty, hermetyzację oraz klasy abstrakcyjne. Właściwe zrozumienie tych pojęć przez pro- jektanta jest niezwykle istotne. Tradycyjne sposoby ich rozumienia mają wiele ograni- czeń, dlatego też w niniejszym rozdziale powrócę raz jeszcze do omawianej wcześniej problematyki. Moją intencją będzie przedstawienie nowych sposobów rozumienia pro- jektowania obiektowego, które wynikają z perspektywy wzorców projektowych. Niestety, tradycyjne sposoby mają bardzo duże ograniczenia. W rozdziale ponownie zastanowię się nad zagadnieniami przedstawionymi we wcześniej- szej części książki, jak również zaprezentuję kilka nowych tematów. Chciałbym przed- stawić czytelnikowi nowy sposób spojrzenia na projektowanie obiektowe, perspektywę, która wyłania się dzięki zrozumieniu wzorców projektowych. Następnie opiszę kluczowe cechy kodu o wysokiej jakości. Znaczenie tych cech podkreślają propagatorzy i zwo- lennicy programowania inteligentnego (ang. agile coding), czyli tworzenia kodu zgodnie z zasadami programowania ekstremalnego (ang. extreme programming, programowa- nia bazującego na testowaniu). Co ciekawe, te same cechy występują także we wzorcach projektowych, a jeśli będziemy postępować zgodnie z zasadami i metodologią wzorców projektowych, to pojawią się one w sposób naturalny. Mam nadzieję, że prezentując te cechy zarówno pod kątem programowania inteligentnego, jak i wzorców projektowych, wypełnię lukę występującą pomiędzy tymi dwoma podejściami do projektowania. Niniejszy rozdział:   przedstawia i porównuje tradycyjny sposób rozumienia obiektów (jako zestawu danych i metod) z nowym sposobem (jako bytów o określonej odpowiedzialności), przedstawia i porównuje tradycyjny sposób rozumienia hermetyzacji (jako ukrywania danych) z nowym sposobem (jako możliwości ukrycia w ogóle); szczególnie istotne będzie tu zrozumienie tego, że hermetyzacja służyć może także jako sposób ukrycia różnic w zachowaniu obiektów, 116 Część III ♦ Wzorce projektowe      przedstawia i porównuje różne sposoby obsługi różnic w zachowaniu, przedstawia i porównuje tradycyjny sposób wykorzystania dziedziczenia (służący specjalizacji oraz ponownemu wykorzystaniu istniejącego kodu) z nowym sposobem (polegającym na wykorzystaniu dziedziczenia w celu klasyfikacji obiektów); pokazuje również, że sposoby te umożliwiają zawarcie zmienności w zachowaniu obiektów, opisuje analizę wspólności i zmienności, przedstawia to, jak perspektywy koncepcji, specyfikacji oraz implementacji mają się do klas abstrakcyjnych i ich klas pochodnych, porównuje wzorce projektowe oraz programowanie inteligentne; choć początkowo może się wydawać, iż oba te podejścia nie są ze sobą zgodne, to okazuje się jednak, że zwracają one uwagę na podobne jakości programowania — nadmiarowość, czytelność oraz łatwość testowania. Podziękowanie Przedstawiona przeze mnie nowa perspektywa obiektowości nie jest zupełnie oryginalna. Stosowali ją z pewnością projektanci poszukujący wzorców projektowych. Jest także zgodna z wynikami prac Christophera Alexandra, Jima Copliena (do jego pracy będę się odwoływać w dalszej części rozdziału) oraz Bandy Czworga1. Mimo to perspektywa obiektowości nie doczekała się dotąd takiego przedstawienia, jakie zamieszczam w niniejszym rozdziale książki. Powstało ono na podstawie anali- zy wzorców projektowych i sposobu ich opisu przez innych autorów. Pisząc tutaj o „nowej” perspektywie obiektowości mam na myśli to, że przedstawiony dalej sposób rozumienia obiektowości będzie prawdopodobnie nowością dla wielu projektantów. Podobnie jak był dla mnie, kiedy po raz pierwszy zapoznawałem się z tematyką wzorców projektowych. Obiekty — w rozumieniu tradycyjnym i nowym Rozumienie tradycyjne: dane oraz metody Tradycyjnie przez obiekty rozumiemy dane oraz operujące na nich metody. Jeden z moich wykładowców nazwał je też kiedyś „inteli- gentnymi danymi”, gdyż chciał odróżnić je od bazy danych. Obiekty są zatem postrzegane jako inteligentny sposób obsługi danych: „Za- cznijmy od danych opisujących stan dziedziny problemu, dodajmy do nich metody operujące na tych danych (czyli niezbędne działanie) i voilà — mamy gotowe obiekty!”. Jednak jest to zbyt uproszczony sposób patrzenia na obiekty, można by rzec — sposób jednowymiarowy. Taki sposób widzenia obiektów mieści się jed- nak w perspektywie implementacji. i 1 Gdyż pisząc niniejszą książkę, udało mi się poznać kilka osób zajmujących się tworzeniem programów w języku Smalltalk. Niemal wszystkie one miały takie samo podejście do projektowania obiektowego jak to, które prezentuję w niniejszej książce. Rozdział 8. ♦ Poszerzamy horyzonty 117 Nowe rozumienie: byty posiadające odpowiedzialność Bardziej przydatna okazuje się tu definicja obiektu powstająca w per- spektywie koncepcji — jako bytu o określonej odpowiedzialności. Odpowiedzialność ta określa z kolei sposób zachowania obiektu. Dla- tego też czasami możemy w skrócie powiedzieć, że obiekt reprezentuje byt o określonym zachowaniu. Zaletą nowej definicji jest to, że pomaga ona skoncentrować się na zadaniach obiektu, a nie na sposobie ich implementacji. Dzięki temu w procesie tworzenia oprogramowania możemy wyróżnić dwa etapy: 1. wstępnego projektu — na etapie tym możemy uniknąć zajmowania się szczegółami implementacji. 2. implementacji projektu. Skoncentrowanie uwagi na tym, co obiekt ma robić, pozwala także nie przejmować się zbyt wcześnie szczegółami jego implementacji. Pozwala na ukrycie szczegółów tej implementacji. To z kolei pomaga w pisaniu oprogramowania, które w przyszłości będzie można łatwiej modyfikować… oczywiście jeśli zajdzie taka konieczność. Jest to możliwe dzięki temu, iż zwracając uwagę na działanie obiektu, koncentrujemy się jedynie na jego interfejsie publicznym, czyli na „oknie komunikacyjnym”, za pomocą którego można poprosić obiekt o wykonanie pewnej czynności. Dysponując dobrym interfejsem, można „poprosić” obiekt o wykonanie dowolnej czynności mieszczącej się w granicach jego odpowiedzialności i jednocześnie mieć pewność, że obiekt ją wyko- nana. Nie trzeba przy tym dysponować żadnymi informacjami odnośnie zdarzeń za- chodzących wewnątrz obiektu. Nie trzeba wiedzieć, w jaki sposób obiekt wykorzysta przekazane do niego informacje ani jak zdobędzie inne dane, które są mu potrzebne. Przekazujemy odpowiedzialność obiektowi i więcej nic nas nie interesuje. Zastanówmy się na przykład nad obiektem klasy (KIWTC, którego odpowiedzialność bę- dzie stanowić:    przechowanie informacji o jego położeniu na ekranie, narysowanie własnej reprezentacji na ekranie, usunięcie reprezentacji z ekranu. Istnienie tych obowiązków określa wprost zestaw potrzebnych metod:  RQDKGT2QNQGPKG   T[UWL(KIWTG   WUWP(KIWTG  Nie określam przy tym żadnych szczegółów wewnętrznej implementacji obiektu, a je- dynie wymieniam jego obowiązki. Obiekt może przechowywać odpowiednie atrybuty lub posiadać dodatkowe metody, które wyznaczą odpowiednie wartości (na przykład na podstawie informacji zawartych w innych obiektach). Obiekt klasy (KIWTC może więc zawierać atrybuty określające jego położenie lub pobierać te informacje na przykład z obiektu reprezentującego bazę danych. W ten sposób uzyskujemy wysoką elastycz- ność ułatwiającą osiągnięcie zadań projektowania (bądź zmianę kodu, jeśli cele ulegną zmianie). 118 Część III ♦ Wzorce projektowe Czytelnik z pewnością zauważy też, że koncentracja na motywacji (a nie na implemen- tacji) jest koncepcją powtarzającą się we wzorcach projektowych. Wynika to z faktu, iż użycie interfejsu do ukrycia implementacji w zasadniczy sposób oddziela ją od obiektów, które z niej korzystają. Proponuję, by czytelnik przyjął zaprezentowany tu sposób widzenia obiektów. Rezul- tatem takiej decyzji będzie lepsza jakość tworzonych rozwiązań. Hermetyzacja — w rozumieniu tradycyjnym i nowym Mój obiektowy parasol Podczas wykładów poświęconych wzorcom projektowym często zadaję moim studentom pytanie: „Kto z Państwa spotkał się z definicją her- metyzacji mówiącą o ukrywaniu danych?”. Prawie wszyscy podnoszą w odpowiedzi rękę. Następnie opowiadam im historię mojego parasola. Proszę pamiętać, że mieszkam w Seattle, które posiada — nieco przesadzoną — opinię wyjątkowo deszczowej okolicy. Prawdą jest jednak, że od jesieni do wiosny jest tutaj dość mokro i wtedy parasole i kurtki z kapturem należą do artykułów pierwszej potrzeby. Opowiem teraz o moim wielkim parasolu. Jest tak duży, że oprócz mnie mogą się pod nim zmieścić jeszcze trzy, a nawet cztery osoby! Kiedy już jesteśmy w jego wnętrzu, czyli poza zasięgiem deszczu, możemy się za jego pomocą przemieszczać. Dodatko- wo zabawia nas w tym czasie jego system stereofoniczny, a klimatyzacja zapewnia odpowiednią temperaturę. Prawda, że to niezwykły parasol? Jest przy tym bardzo wygodny w użyciu. Nie muszę go ze sobą nosić, bo zawsze czeka na mnie na zewnątrz. Wyposażony jest ponadto w koła, żeby łatwiej można się było przemieszczać. Ale nie muszę go pchać ani ciągnąć, ponieważ posiada własny napęd. Korzystam z niego nawet wtedy, gdy nie pada. Jeśli świeci słońce i chcę nacieszyć się jego promieniami, otwieram górną część parasola (powód, dla którego używam parasola nawet wtedy, gdy nie pada, nie jest dla mnie jasny). Mieszkańcy Seattle używają setki tysięcy podobnych parasoli w przeróżnych kolorach. Większość ludzi nazywa je jednak samochodami. Sam jednak częściej myślę o moim samochodzie jak o parasolu, ponieważ zwykle chroni mnie przed deszczem. Czekając na kogoś na dworze często siadam pod moim „paraso- lem”, aby nie zmoknąć. Definicje mogą narzucać ograniczenia Jednak samochód nie jest parasolem. Możemy go wykorzystywać jako schronienie przed deszczem, ale jest to dość ograniczony sposób wyko- rzystania możliwości, jakie daje samochód. Podobnie jest z hermetyzacją — nie służy ona jedynie do ukrywania danych. Taki sposób myśle- nia o hermetyzacji ogranicza moje możliwości jako projektanta. Rozdział 8. ♦ Poszerzamy horyzonty 119 W jaki sposób myśleć o hermetyzacji O hermetyzacji powinno myśleć się jak o ukrywaniu w ogóle. Innymi słowy — hermetyzacja może służyć do ukrycia danych. Ale może także ukrywać:  sposób implementacji,  klasy pochodne,  szczegóły projektowe,  reguły tworzenia obiektów. We wcześniejszych rozważaniach dotyczących ukrywania implementacji w zasadzie „hermetyzowałem” ją. Aby posunąć się jeszcze dalej, przeanalizujmy diagram przed- stawiony na rysunku 8.1, który został po raz pierwszy zamieszczony w rozdziale 7., zatytułowanym „Wzorzec adaptera”. Klasy 2WPMV, .KPKC, -YCFTCV oraz 1MTCI dziedziczą po klasie (KIWTC. Dodatkowo klasa 1MTCI „opakowuje” lub zawiera klasę ::1MTCI. Rysunek 8.1 przedstawia kilka rodzajów hermetyzacji. Rysunek 8.1. Dostosowanie klasy XXOkrag za pomocą klasy Okrag Kilka poziomów hermetyzacji Diagram ten przedstawia wiele sposobów zastosowania hermetyzacji:  Hermetyzację danych — dane wewnątrz obiektów klas 2WPMV, .KPKC oraz -YCFTCV są ukryte przed obiektami innych klas.    Hermetyzację metod — na przykład metoda RQDKGT2QNQGPKG w klasie 1MTCI. Hermetyzację innych obiektów — jedynie obiekt klasy 1MTCI posiada dostęp do zawartego w nim obiektu klasy ::1MTCI. Hermetyzację typów — użytkownicy klasy (KIWTC nie wiedzą o istnieniu klas 2WPMV, .KPKC, -YCFTCV. Hermetyzację typów uzyskuje się zatem w przypadku, gdy istnieje klasa abstrakcyjna mająca kilka klas pochodnych (lub interfejs wraz z jego implementacjami) wykorzy- stywanych w oparciu o zasady polimorfizmu. Użytkownik korzystający z tej klasy 120 Część III ♦ Wzorce projektowe abstrakcyjnej nie zna typu klasy pochodnej obiektu, którym się w danej chwili posłu- guje. To właśnie ten rodzaj hermetyzacji ma zazwyczaj na myśli Banda Czworga. Zalety tej nowej definicji Rozumienie hermetyzacji w szerszy sposób przyczynia się do uzyskania lepszej struktury programu. Hermetyzacja ułatwia określenie interfej- sów, na których opiera się projekt. Ukrywając za pomocą klasy (KIWTC istnienie klas reprezentujących poszczególne rodzaje figur, można później dodawać ich kolejne rodzaje bez obawy o to, że będzie to wymagać zmian w programie użytkownika. Podobnie — ukrywając istnienie obiektu klasy ::1MTCI wewnątrz klasy 1MTCI, można później zmienić w dowolny sposób implementację rysowania okręgu. Dziedziczenie jako pojęcie a dziedziczenie jako sposób wielokrotnego zastosowania W początkowym okresie (tuż po zaprezentowaniu paradygmatu obiek- towego) uważano, że jedną z jego najważniejszych zalet jest możliwość ponownego wykorzystania istniejącego kodu poprzez tworzenie klas po- chodnych za pomocą dziedziczenia z istniejących klas bazowych. W ten sposób powstał termin specjalizacja, który służy do określenia procesu tworzenia klas pochodnych (dlatego też klasy pochodne nazywa się cza- sem klasami wyspecjalizowanymi, a klasy bazowe — klasami ogólnymi). Nie zamierzam tutaj podważać słuszności takiego twierdzenia. Proponuję jednak wyko- rzystanie dziedziczenia w sposób, który uważam za bardziej doskonały. Załóżmy, na przykład, że chciałbym posługiwać się pięciokątem. Definiuję zatem klasę 2KGEKQMCV, która będzie zawierać stan nowej figury oraz metody pozwalające na jej wyświetlenie, usunięcie itd. Nieco później okazuje się, że potrzebny mi jest pięciokąt ze specjalnymi krawędziami. Mogę zatem użyć klasy 2KGEKQMCV i na jej podstawie stworzyć bardziej wyspecjalizowaną klasę pochodną dysponująca niezbędnym algorytmem wyświetlania krawędzi (rysunek 8.2). Rysunek 8.2. Klasa PieciokatZKrawedzia dziedziczy po klasie Pieciokat Był to przykład zastosowania dziedziczenia w celu specjalizacji. Wykorzystałem klasę 2KGEKQMCV, aby stworzyć nową klasę — 2KGEKQMCV -TCYGFKC. Rozwiązanie to spisuje się dobrze, choć przysparza trzech problemów opisanych w tabeli 8.1. Innym sposobem zastosowania dziedziczenia jest klasyfikacja klas pod kątem identycz- nego zachowania. Zagadnienie to rozwinę w dalszej części rozdziału. Rozdział 8. ♦ Poszerzamy horyzonty 121 Tabela 8.1. Problemy, jakich przysparza zastosowanie dziedziczenia w celu specjalizacji. Problem Opis Może przyczyniać się do występowania niskiego stopnia spójności. Ogranicza możliwości wielokrotnego stosowania kodu. Utrudnia obsługę zmian. Zastanówmy się, co by się stało, gdyby istniało wiele różnych typów krawędzi? Okazuje się, że w takim przypadku klasa 2KGEKQMCV (oraz jej klasy pochodne) nie opisuje już wyłącznie samej figury, lecz także jej krawędzie, a to sprawia, iż klasa ta musi zajmować się dodatkowymi problemami. Co więcej, w klasie mogą się także pojawić inne zmienne aspekty (na przykład rodzaj wypełnienia pięciokąta). Jeśli stworzę w klasie 2KGEKQMCV (i jej klasach pochodnych) kod obsługujący różne rodzaje krawędzi, to w jaki sposób będę mógł z niego skorzystać w innych klasach? Zadanie to byłoby bardzo trudne, gdyż za każdym razem zmienia się kontekst, a co więcej, gdyż kod obsługujący znajduje się w klasie 2KGEKQMCV i raczej nie będzie dostępny poza nią. Metoda specjalizacji w celu wielokrotnego zastosowania doskonale nadaje się do przedstawiania w klasie, gdyż można ją zademonstrować i przejść do dalszych zagadnień, zanim ktokolwiek zdąży zapytać, co się stanie, gdy pojawi się możliwość modyfikacji jakiegoś innego czynnika. Na przykład co zrobić, jeśli pojawią się dwa różne rodzaje cieniowania? Aby je obsłużyć, trzeba by stworzyć nowe, bardziej wyspecjalizowane wersje klasy 2KGEKQMCV (co oznaczałoby częściowe powielenie kodu). Określ zmienność i hermetyzuj ją Wzorce projektowe wykorzystujące dziedziczenie w celu sklasyfikowania odmiennego zachowania Autorzy książki Design Patterns: Elements of Reusable Object-Oriented Software sugerują, co następuje: Spróbujmy określić, co jest zmienną w naszym projekcie. Takie podejście stanowi przeciwieństwo koncentrowania się na przyczynach zmian w projekcie. Zamiast zastanawiać się, co może spowodować wprowadzenie zmian do projektu, skoncentrujmy się na tym, co możemy zmienić bez konieczności modyfikacji projektu. Skoncentrujmy się zatem na hermetyzacji tego, co ulega zmianie, czyli sposobie stosowanym przez wiele wzorców projektowych2. Osobiście preferuję nieco inne ujęcie tej samej kwestii: Znajdź, co się zmienia i hermetyzuj to. Takie stwierdzenie, może wydać się czytelnikowi mało zrozumiałe, jeśli nadal myśleć będzie o hermetyzacji jak o ukrywaniu danych. Stanie się dużo bardziej czytelne, jeśli czytelnik pomyśli o hermetyzacji jako o ukrywaniu klas pochodnych za pomocą klasy abstrakcyjnej lub interfejsu — czyli o „hermetyzacji typu”3. Udostępnienie referencji i 2 3 Gamma E., Helm R., Johnson R., Vlissides J., Design Patterns: Elements of Reusable Object-Oriented Software, Boston: Addison-Wesley, 1995, s. 29. Ogólnie rzecz biorąc, to właśnie o tym rodzaju hermetyzacji myśli Banda Czworga, używając terminu „hermetyzacja”. 122 Część III ♦ Wzorce projektowe do takiej abstrakcyjnej klasy lub interfejsu (agregacja) ukrywa klasy pochodne repre- zentujące różnice w sposobie działania. Innymi słowy, pewna klasa posiada referencję do klasy abstrakcyjnej lub do interfejsu posiadających więcej niż jedną klasę pochodną. Jednak te klasy pochodne są ukryte (hermetyzowane) przez klasę, która ich używa. Wiele wzorców projektowych stosuje hermetyzację w celu utworzenia warstw pomiędzy obiektami, co umożliwia wprowadzanie zmian po jednej ze stron warstwy bez wpływu na obiekty znajdujące się po przeciwnej stronie warstwy. Jest to możliwe dzięki wprowa- dzeniu przez wzorzec niskiego stopnia powiązania pomiędzy obiektami po obu stronach warstwy. Zawieranie zmienności danych a zmienności zachowania Sposób ten stanowi podstawę działania wzorca mostu, który przedstawię w rozdziale 10. zatytułowanym „Wzorzec mostu”. Wcześniej chciał- bym jednak omówić pewien błąd, który często popełniają projektanci. Przypuśćmy, że pracuję nad projektem, który tworzy modele przezna- czone do opisu różnych cech zwierząt. Wymagania będą w tym przy- padku określone następująco:     zwierzęta mogą posiadać różną liczbę nóg, obiekty reprezentujące zwierzęta muszą umożliwić przechowanie tej informacji i jej uzyskanie, różne zwierzęta mogą poruszać się w różny sposób, obiekty reprezentujące zwierzęta muszą umożliwić uzyskanie informacji o tym, ile czasu zajmie im pokonanie określonego dystansu na danym terenie. Typowym sposobem, w jaki programista poradzi sobie z problemem różnej ilości nóg, będzie utworzenie zmiennej składowej wewnątrz obiektu, która przechowywać będzie odpowiednią wartość, a także metod umożliwiających nadanie wartości zmiennej i po- branie jej wartości. Jednak — aby uporać się z problemem zmienności w zachowaniu obiektów — potrzebne będzie inne rozwiązanie. Przypuśćmy, że określone są dwa sposoby poruszania się: chodzenie i latanie. Dla każde- go z nich potrzebny będzie osobny fragment kodu, gdyż sama zmienna niczego tutaj nie rozwiąże (choć można jej użyć w celu określenia, jaki sposób poruszania się jest dostępny). W tym wypadku programista wybierze raczej jedno z dwu rozwiązań:  utworzenie zmiennej składowej, która przechowywać będzie informację o sposobie poruszania się zwierzęcia,  utworzenie osobnej klasy pochodnej klasy bazowej YKGTG dla reprezentacji zwierząt, które chodzą, i osobnej klasy dla tych, które latają. Okazuje się jednak, że w sytuacjach, gdy problem staje się złożony, to oba te rozwiązania zawodzą. Doskonale spełniają swe zadania, gdy istnieje tylko jeden zmienny czynnik (sposób poruszania się), jednak co się stanie, gdy liczba tych czynników wzrośnie? Na przykład co w sytuacji, jeśli pojawią się orły (latające drapieżniki), lwy (drapieżniki po- ruszające się na lądzie), wróble (ptaki roślinożerne) oraz krowy (zwierzęta roślinożerne poruszające się po lądzie)? Wykorzystanie instrukcji wyboru do określania typu zwie- rzęcia spowodowałoby skojarzenie sposobów poruszania się oraz odżywiania — czyli Rozdział 8. ♦ Poszerzamy horyzonty 123 czynników, które nie wydają się być ze sobą połączone. Z kolei wykorzystanie dziedzi- czenia do obsługi każdej z sytuacji wyjątkowych prowadzi do ogromnego wzrostu ilości klas. Poza tym co się stanie, jeśli zwierzęta raz przejawiają jeden sposób za- chowania, a w innych przypadkach zachowują się inaczej (na przykład większość ptaków potrafi zarówno latać, jak i poruszać się po lądzie)? Istnieje jeszcze inny problem. Tworzenie klas obsługujących coraz to więcej czynni- ków zmiennych (na przykład wykorzystując w tym celu instrukcje wyboru) może do- prowadzić do zmniejszenia spójności kodu. Oznacza to, że im więcej przypadków szczególnych obsługuje klasa, tym trudniej jest zrozumieć jej kod. Innym rozwiązaniem może okazać się umieszczenie wewnątrz obiektu klasy YKGTG obiektu określającego sposób poruszania się, co ilustruje diagram pokazany na rysunku 8.3. Obsługa zmienności działania poprzez zastosowanie obiektów Rysunek 8.3. Obiekt klasy Zwierze zawiera obiekt klasy SposobRuchu To nie jest żadna przesada Rozwiązanie to może na pierwszy rzut oka wyglądać nadmiarowo. Jednak w praktyce oznacza ono jedynie tyle, że obiekt klasy YKGTG zawiera odpowiedni obiekt określający sposób jego poruszania się. Jest więc analogiczne do rozwiązania, w którym zmienną wykorzystu- jemy do przechowania informacji o liczbie nóg zwierzęcia (z tą różnicą, że w tym przypadku zmienna składowa reprezentuje różnicę w zachowaniu, a nie w liczbie). Może jedynie wydawać się, że oba te rozwiązania się różnią, choćby na podstawie różnic w diagramach przedstawionych na rysunkach 8.3 i 8.4. Rysunek 8.4. Obiekt zawierający atrybuty Porównanie obu rozwiązań Wielu projektantów uważa, że pomiędzy zawieraniem przez obiekt innego obiektu, a zawieraniem przez obiekt atrybutów istnieje różnica. Jednak mimo że atrybuty są zmiennymi typów prostych (na przykład FQWDNG, KPVGIGT) i nie przypominają obiektów, to są nimi z punktu widzenia projektowania obiektowego. Pamiętajmy, że w programowaniu obiektowym wszystko stanowi obiekt (nawet podstawowe typy danych, których zachowanie okre- śla arytmetyka). Specyficzna składnia posługiwania się tymi obiektami (na przykład Z [ odpowiadająca ZCFF [ ) ukrywa jedynie fakt, iż są to obiekty o określonym za- chowaniu. 124 Część III ♦ Wzorce projektowe W ten sposób rozwiązanie zastosowane w przypadku zmienności atrybutów i rozwiązanie w przypadku zmienności zachowania okazują się do siebie podobne. Najłatwiej będzie to pokazać na przykładzie. Załóżmy, że opracować muszę system obsługi punktu sprze- daży. Kluczowy element tego systemu stanowić będzie faktura. Na fakturze tej znajdzie się całkowita wartość zakupu. Początkowo dla jej reprezentacji mógłbym użyć typu prostego FQWDNG. Jeśli jednak system będzie musiał wystawiać faktury w różnych walu- tach, to szybko pojawi się problem odpowiedniej konwersji. Dlatego też zdecyduję się raczej utworzyć klasę 2KGPKCF, która przechowywać będzie informacje o kwocie i jej walucie. Tak więc suma na fakturze będzie teraz manifestacją obiektu klasy 2KGPKCF. Choć może wydawać się na początku, że jedynym zadaniem obiektu klasy 2KGPKCF jest przechowanie odpowiedniej informacji, to jednak szybko okaże się, że zgodnie z zasadą odpowiedzialności obiekty tej klasy muszą posiadać także metody służące konwersji pomiędzy różnymi walutami. Jak się okazuje, zadanie konwersji nie sprowadza się tyl- ko do przechowania w obiekcie kolejnej informacji (o aktualnym przeliczniku walut). Komplikację wprowadzić może na przykład konieczność dokonywania konwersji po- między walutami na podstawie ich kursów pochodzących z przeszłości. W takim przy- padku atrybut można by zastąpić klasą 9CNWVC. Dodawanie zachowań do klasy 2KGPKCF lub 9CNWVC dodaje je także do klasy 4CEJWPGM, która zależy od umieszczonych w niej obiektów 2KGPKCF (a zatem także i obiektów 9CNWVC). Niemniej jednak takie rozwiązanie ani nie powoduje zwiększenia stopnia złożoności klasy 4CEJWPGM, ani nie wymaga wprowadzania w niej jakichkolwiek zmian. Strategię polegającą na uzyskiwaniu określonego zachowania obiektu w zależności od rodzaju zawieranego obiektu zademonstruję omawiając kilka następnych wzorców projektowych. Analiza wspólności i zmienności a klasy abstrakcyjne Analiza wspólności i zmienności Książka Copliena omawiająca problem analizy wspólności i zmienności, pokazuje, jak odnajdywać w dziedzinie problemu czynniki zmienne oraz elementy wspólne: „Określ, gdzie („analiza wspólności”) oraz jak („analiza zmienności”) elementy się od siebie różnią”. Analiza wspólności Coplien stwierdza, iż: „Analiza wspólności polega na poszukiwaniu wspólnych elementów, które pozwalają zrozumieć, na czym polega podobieństwo członków tej samej rodziny”4. Pod pojęciem „człon- ków rodziny” Coplien rozumie elementy, które są ze sobą powiązane ze względu na sytuację, w jakiej się pojawiają, lub funkcje, jakie wykonują. Proces odnajdywania cech wspólnych definiuje rodzinę, do której należą elementy (a zatem, także, jakie są różnice pomiędzy nimi). Na przykład, gdyby ktoś pokazał nam flamaster do pisania na tablicy, pióro oraz ołówek, to moglibyśmy stwierdzić, iż ich wspólną cechę jest i Coplien J., Multi-Paradigm Design for C++, Boston: Addison-Wesley, 1998, str. 63. 4 Rozdział 8. ♦ Poszerzamy horyzonty 125 przeznaczenie — wszystko są to przedmioty służące do pisania. Proces, jaki wykona- liśmy, aby określić wszystkie te przedmioty w identyczny sposób, nazywamy analizą wspólności. Dysponując cechami wspólnymi (przedmioty do pisania), łatwiej można określić, czym poszczególne przedmioty różnią się od siebie (na czym się pisze, kształt przedmiotu i tak dalej). Analiza zmienności Analiza zmienności ma na celu określenie, czym poszczególni człon- kowie rodziny różnią się od siebie. Te odmienności mają sens wyłącz- nie w odniesieniu do elementów, dla których określono cechy wspólne: Analiza wspólności poszukuje struktury, która jest niezmienna, natomiast analiza zmienności poszukuje struktury, która może się zmieniać.n Analiza zmienności ma sens wyłącznie w kontekście zdefiniowanym przez odpowiednią analizę wspólności… W odniesieniu do architektury analiza wspólności zapewnia jej długowieczność, natomiast analiza zmienności — przydatność5. Innymi słowy, jeśli czynnikiem zmiennym są konkretne klasy należące do dziedziny problemu, to czynniki wspólne definiują te pojęcia dziedziny, które łączą te klasy ze sobą. Pojęcia wspólne będą reprezentowane przez klasy abstrakcyjne. Różnice wskaza- ne przez analizę zmienności będą implementowane przez konkretne klasy (to znaczy przez klasy pochodne klasy abstrakcyjnej). Nowy paradygmat znajdowania obiektów Często niedoświadczeni projektanci programów obiektowych są in- struowani, aby analizować dziedzinę problemu oraz „odnajdywać istniejące rzeczowniki i tworzyć klasy, które będą je reprezentować, a następnie odnajdywać czasowniki (czyli akcje) i implementować je poprzez dodawanie metod do wcześniej utworzonych obiektów”. Taki proces, polegający na skoncentrowaniu uwagi na rzeczownikach i czasownikach, za- zwyczaj prowadzi do powstawania większych hierarchii klas, niż można by sobie tego życzyć. Sugeruję, by podstawowym narzędziem podczas tworzenia obiektów była ana- liza wspólności i zmienności, gdyż metoda ta jest lepsza od wyróżniania rzeczowni- ków i czasowników (jest ona częściowo zgodna z metodą postulowaną przez Copliena). Projektowanie obiektowe obejmuje wszystkie trzy perspektywy Teraz specyfikacja pozwala na lepsze zrozumienie klas abstrakcyjnych Rysunek 8.5 obrazuje związki zachodzące pomiędzy:    analizą wspólności i zmienności, perspektywami koncepcji, specyfikacji oraz implementacji, klasą abstrakcyjną, jej interfejsem i klasami pochodnymi. Jak pokazano na rysunku 8.5, analiza wspólności związana jest z war- stwą koncepcyjną dziedziny zastosowań, a analiza zmienności odnosi się do warstwy implementacji (czyli specyficznych przypadków pro- blemu). i Ibidem, strony 60 i 64. 5 126 Część III ♦ Wzorce projektowe Rysunek 8.5. Związki pomiędzy analizą wspólności i zmienności, perspektywami i klasą abstrakcyjną Warstwa specyfikacji znajduje się pośrodku. Zarówno analiza wspólności, jak i zmienno- ści jest z nią związana. Warstwa specyfikacji określa sposób komunikacji z obiektami, które są koncepcyjnie podobne. Natomiast poszczególne obiekty reprezentują zmien- ność problemu. W warstwie implementacji specyfikacja przyjmuje postać klasy abs- trakcyjnej bądź interfejsu. W nowej perspektywie projektowania obiektowego możemy wyróżnić związki przed- stawione w tabeli 8.2. Tabela 8.2. Zalety zastosowania klas abstrakcyjnych do specjalizacji Związek Omówienie Klasa abstrakcyjna a główne pojęcie łączące klasy Klasa abstrakcyjna stanowi kluczowe pojęcie łączące klasy pochodne i definiuje część wspólną problemu. Część wspólna a określenie używanych klas abstrakcyjnych Część zmienna a klasy pochodne Specyfikacja a interfejs klasy abstrakcyjnej Część wspólna problemu definiuje klasę abstrakcyjną. Zmienność, którą możemy zidentyfikować wewnątrz części wspólnej, określa klasy pochodne klasy abstrakcyjnej. Interfejs klasy abstrakcyjnej — a tym samym jej klas pochodnych — określony jest w warstwie specyfikacji. Proces projektowania klas upraszcza się w ten sposób do procedury złożonej z dwu etapów przedstawionych w tabeli 8.3. Tabela 8.3. Dwuetapowa procedura projektowania Definicja Pytanie Klasa abstrakcyjna (część wspólna) Klasy pochodne Jak powinien wyglądać interfejs, by mógł umożliwiać realizację wszystkich odpowiedzialności tej klasy? W jaki sposób powinna zostać zaimplementowana część zmienna problemu w ramach danej specyfikacji? Rozdział 8. ♦ Poszerzamy horyzonty 127 Związek pomiędzy perspektywą specyfikacji i perspektywą koncepcji jest więc nastę- pujący: specyfikacja określa interfejs potrzebny do obsługi wszystkich przypadków danego problemu (czyli część wspólną określoną przez perspektywę koncepcji). Związek pomiędzy perspektywą specyfikacji i perspektywą implementacji możemy natomiast określić: biorąc pod uwagę określoną specyfikację i ustalając, w jaki spo- sób należy zaimplementować poszczególne przypadki (czyli część zmienną). Cechy programowania inteligentnego Projektowanie metodą „od góry do dołu” a projektowanie „w trakcie pracy” Podejście do projektowania wykorzystujące wzorce projektowe często określa się jako „projektowanie od góry do dołu”. Zaleca ono rozpo- czynanie projektowania od najbardziej ogólnych pojęć i sukcesywne uwzględnianie coraz większej ilości szczegółów. Istnieje także podejście alternatywne, postulowane przez zasady pro- gramowania ekstremalnego, które wydaje się stać w całkowitej sprzecz- ności z metodą przedstawioną powyżej. Programowanie ekstremalne koncentruje się na realizacji niewielkich etapów oraz weryfikację ich poprawności. Całościowy obraz roz- wiązania wyłania się na podstawie tych etapów. Osobiście uważam, że zasady programowania ekstremalnego oraz metody projektowania z wykorzystaniem wzorców projektowych nie są względem siebie sprzeczne, lecz ra- czej się uzupełniają. Obu tych metod można użyć w celu osiągnięcia tego samego celu — utworzenia efektywnego, solidnego i elastycznego kodu. Ale jak to jest możliwe? Są- dzę, iż wynika to z faktu, że zasady, na których bazują obie te metody, są pokrewne. Wnioski ze stosowania programowania inteligentnego Ponieważ stosunkowo wcześnie zacząłem stosować praktyki pro- gramowania inteligentnego, dlatego też musiałe
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Projektowanie zorientowane obiektowo. Wzorce projektowe. Wydanie II
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: